You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Steve Armstrong <st...@gmail.com> on 2010/05/26 21:06:55 UTC
Strange status if .svn folder removed
Hello all,
I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9
command-line binaries.
I have a working copy checked out (C:\wc). Inside it, there's an empty
folder that's source-controlled (C:\wc\logs). If I delete the .svn folder
from within logs, then doing an "svn st" in the base folder (C:\wc) gives
me:
C:\wc>svn st
~ log
Trying to update to "bring back" the folder shows a delete:
C:\wc>svn up
D log
Updated to revision 200374.
The folder is still there, without a .svn folder inside it, and svn doesn't
know what to do with it.
C:\wc>svn st
? log
At this point, the repository still shows the folder (the delete didn't
happen on the server). After deleting the log folder, svn thinks
everything's fine (even though the folder is now totally missing from the
working copy)
C:\wc>svn st
Reverting the folder to bring it back does nothing:
C:\wc>svn revert log
Skipped 'log'
Doing a general update doesn't work:
C:\wc>svn up
At revision 200376.
Only by doing an update directly to log can I get the folder back:
C:\wc>svn up log
A log
Updated to revision 200376.
There are reasons that I probably shouldn't have this skeleton under source
control in the first place, but this seems like broken behavior regardless.
Should I file it as a bug? Or is it already known?
Thanks
Steve Armstrong
Re: Strange status if .svn folder removed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Fri, 28 May 2010 at 01:22 +0200:
> I think Daniel means
No, that's not what I meant.
Re: Strange status if .svn folder removed
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Thu, May 27, 2010 at 6:22 PM, Stefan Sperling <st...@elego.de> wrote:
> On Thu, May 27, 2010 at 04:34:07PM -0500, Hyrum K. Wright wrote:
> > On Thu, May 27, 2010 at 4:30 PM, Daniel Shahaf <d.s@daniel.shahaf.name
> >wrote:
> >
> > > How would recursing interact with symlinks into working copy dirs?
> > > (I know we it have been discussed before; a pointer would be
> appreciated)
> > >
> > > eg:
> > >
> > > svn co $SVN_TRUNK trunk
> > > ln -s trunk/notes notes
> > > cd notes
> > > svn st
> > >
> >
> > Isn't this just a subset of the "severable working copy" use case?
>
> I think Daniel means we should check if we're traversing a symbolic
> link going upwards, do a readlink() on it and continue searching
> for .svn upwards from where the link points to.
> And maybe stop after N iterations to protect the innocent who set up
> symlink loops accidentally :)
>
That's quite possible.
But at this point, we're starting to wander a bit off topic for this list
(and out of my league, too). I'll defer this discussion to Greg Stein, who
probably has some thoughts on the matter.
-Hyrum
Re: Strange status if .svn folder removed
Posted by Stefan Sperling <st...@elego.de>.
On Thu, May 27, 2010 at 04:34:07PM -0500, Hyrum K. Wright wrote:
> On Thu, May 27, 2010 at 4:30 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
>
> > How would recursing interact with symlinks into working copy dirs?
> > (I know we it have been discussed before; a pointer would be appreciated)
> >
> > eg:
> >
> > svn co $SVN_TRUNK trunk
> > ln -s trunk/notes notes
> > cd notes
> > svn st
> >
>
> Isn't this just a subset of the "severable working copy" use case?
I think Daniel means we should check if we're traversing a symbolic
link going upwards, do a readlink() on it and continue searching
for .svn upwards from where the link points to.
And maybe stop after N iterations to protect the innocent who set up
symlink loops accidentally :)
Stefan
Re: Strange status if .svn folder removed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
> > > "deeply nested" usually means only 10-15 folders. Recursing up to find
> > the
> > > root of the working copy is a one-time operation during the course of an
> > > invocation of 'svn' on that working copy. As such, it's essentially a
> > free
> > > operation.
> > >
> >
> > How would recursing interact with symlinks into working copy dirs?
> > (I know we it have been discussed before; a pointer would be appreciated)
> >
> > eg:
> >
> > svn co $SVN_TRUNK trunk
> > ln -s trunk/notes notes
> > cd notes
> > svn st
> >
>
> Isn't this just a subset of the "severable working copy" use case?
>
i.e., if I don't run 'svn sever trunk/notes', the above will just fail
with "svn: 'notes' is not a working copy"?
> -Hyrum
>
Re: Strange status if .svn folder removed
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Thu, May 27, 2010 at 4:30 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
> [ fixed leading "> " signs ]
>
> Hyrum K. Wright wrote on Thu, 27 May 2010 at 16:17 -0500:
> > On Thu, May 27, 2010 at 3:40 PM, Bob Archer <Bo...@amsi.com> wrote:
> >
> > > > > Will per-directory .svn's remain as an option in 1.7+? (I thought
> > > > > yes...)
> > > >
> > > > Not to my knowledge. I wasn't aware of the use case (aside from
> > > > severable working copies) that engendered this need.
> > > >
> > >
> > > How are the 1.7 WC libraries going to determine if a folder is part of
> a
> > > WC? Are they going to have to walk the file system backwards all the
> way to
> > > the root? That seems like a bit of a perf hit for large projects with a
> deep
> > > level of nested folders?
> > >
> >
> > "deeply nested" usually means only 10-15 folders. Recursing up to find
> the
> > root of the working copy is a one-time operation during the course of an
> > invocation of 'svn' on that working copy. As such, it's essentially a
> free
> > operation.
> >
>
> How would recursing interact with symlinks into working copy dirs?
> (I know we it have been discussed before; a pointer would be appreciated)
>
> eg:
>
> svn co $SVN_TRUNK trunk
> ln -s trunk/notes notes
> cd notes
> svn st
>
Isn't this just a subset of the "severable working copy" use case?
-Hyrum
Re: Strange status if .svn folder removed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
[ fixed leading "> " signs ]
Hyrum K. Wright wrote on Thu, 27 May 2010 at 16:17 -0500:
> On Thu, May 27, 2010 at 3:40 PM, Bob Archer <Bo...@amsi.com> wrote:
>
> > > > Will per-directory .svn's remain as an option in 1.7+? (I thought
> > > > yes...)
> > >
> > > Not to my knowledge. I wasn't aware of the use case (aside from
> > > severable working copies) that engendered this need.
> > >
> >
> > How are the 1.7 WC libraries going to determine if a folder is part of a
> > WC? Are they going to have to walk the file system backwards all the way to
> > the root? That seems like a bit of a perf hit for large projects with a deep
> > level of nested folders?
> >
>
> "deeply nested" usually means only 10-15 folders. Recursing up to find the
> root of the working copy is a one-time operation during the course of an
> invocation of 'svn' on that working copy. As such, it's essentially a free
> operation.
>
How would recursing interact with symlinks into working copy dirs?
(I know we it have been discussed before; a pointer would be appreciated)
eg:
svn co $SVN_TRUNK trunk
ln -s trunk/notes notes
cd notes
svn st
Daniel
> Also, compared to all the other traversal of the working copy that happens
> in 1.6, but which will be eliminated in 1.7, it's a tradeoff we're willing
> to make.
Re: Strange status if .svn folder removed
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Thu, May 27, 2010 at 3:40 PM, Bob Archer <Bo...@amsi.com> wrote:
> > Hyrum K. Wright wrote on Wed, 26 May 2010 at 16:16 -0500:
> > > On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong
> > > <st...@gmail.com>wrote:
> > >
> > > > Hello all,
> > > >
> > > > I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9
> > > > command-line binaries.
> > > >
> > > > I have a working copy checked out (C:\wc). Inside it, there's an
> empty
> > > > folder that's source-controlled (C:\wc\logs). If I delete the .svn
> > folder
> > > > from within logs, then doing an "svn st" in the base folder (C:\wc)
> > gives
> > > > me:
> > > >
> > > > C:\wc>svn st
> > > > ~ log
> > > >
> > > > Trying to update to "bring back" the folder shows a delete:
> > > > C:\wc>svn up
> > > > D log
> > > > Updated to revision 200374.
> > > >
> > > > The folder is still there, without a .svn folder inside it, and svn
> > doesn't
> > > > know what to do with it.
> > > > C:\wc>svn st
> > > > ? log
> > > >
> > > > At this point, the repository still shows the folder (the delete
> > didn't
> > > > happen on the server). After deleting the log folder, svn thinks
> > > > everything's fine (even though the folder is now totally missing from
> > the
> > > > working copy)
> > > >
> > > > C:\wc>svn st
> > > >
> > > > Reverting the folder to bring it back does nothing:
> > > > C:\wc>svn revert log
> > > > Skipped 'log'
> > > >
> > > > Doing a general update doesn't work:
> > > > C:\wc>svn up
> > > > At revision 200376.
> > > >
> > > > Only by doing an update directly to log can I get the folder back:
> > > > C:\wc>svn up log
> > > > A log
> > > > Updated to revision 200376.
> > > >
> > > > There are reasons that I probably shouldn't have this skeleton under
> > source
> > > > control in the first place, but this seems like broken behavior
> > regardless.
> > > > Should I file it as a bug? Or is it already known?
> > > >
> > >
> > > I wouldn't file a bug. Per-directory .svn directories are disappearing
> > in
> > > 1.7,
> > Will per-directory .svn's remain as an option in 1.7+? (I thought
> yes...)
> >
> > Not to my knowledge. I wasn't aware of the use case (aside from
> > severable working copies) that engendered this need.
> >
>
> How are the 1.7 WC libraries going to determine if a folder is part of a
> WC? Are they going to have to walk the file system backwards all the way to
> the root? That seems like a bit of a perf hit for large projects with a deep
> level of nested folders?
>
"deeply nested" usually means only 10-15 folders. Recursing up to find the
root of the working copy is a one-time operation during the course of an
invocation of 'svn' on that working copy. As such, it's essentially a free
operation.
Also, compared to all the other traversal of the working copy that happens
in 1.6, but which will be eliminated in 1.7, it's a tradeoff we're willing
to make.
> How will it work with Nested checkouts?
>
> For example if I do:
>
> svn co ^/MyProjectFolder ProjectName
> cd ProjectName
> svn co ^/MyDocumentationProject doc
>
> You can do this now... as a matter of fact we do. Well there be a .svn
> folder in ProjectName and one in doc? Or will the .svn folder in ProjectName
> contain the metadata for the doc folder as well?
Lots of these issues have been discussed ad nauseum among the devs. While
I'm not discounting the importance of answering them here, too, I'd
encourage you to read the documentation, located here:
http://svn.apache.org/repos/asf/subversion/trunk/notes/wc-ng/
The upshot is that anything below a given working copy root will store its
metadata in the .svn directory located in that root.
-Hyrum
RE: Strange status if .svn folder removed
Posted by Bob Archer <Bo...@amsi.com>.
> On May 27, 2010, at 15:40, Bob Archer wrote:
>
> > How will it work with Nested checkouts?
> >
> > For example if I do:
> >
> > svn co ^/MyProjectFolder ProjectName
> > cd ProjectName
> > svn co ^/MyDocumentationProject doc
> >
> > You can do this now... as a matter of fact we do.
>
> Wouldn't externals be a better way to handle this?
>
No because they aren't really externals. The way we use this is that documentation has their own project. They generate the doc deliverables into a folder which is a co of a folder from the development tree doc folder. (It sounds like externals should work, but they don't. I don't recall what the problem was, because that is what I tried first.)
Granted this can be down without the nested checkouts with either a batch file that copies the generated output to the dev tree or just moving it manually... but this setup has made it very simple with no extra steps for the doc people... they gen the help in robohelp then they commit.
BOb
Re: Strange status if .svn folder removed
Posted by Ryan Schmidt <su...@ryandesign.com>.
On May 27, 2010, at 15:40, Bob Archer wrote:
> How will it work with Nested checkouts?
>
> For example if I do:
>
> svn co ^/MyProjectFolder ProjectName
> cd ProjectName
> svn co ^/MyDocumentationProject doc
>
> You can do this now... as a matter of fact we do.
Wouldn't externals be a better way to handle this?
RE: Strange status if .svn folder removed
Posted by Bob Archer <Bo...@amsi.com>.
> Hyrum K. Wright wrote on Wed, 26 May 2010 at 16:16 -0500:
> > On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong
> > <st...@gmail.com>wrote:
> >
> > > Hello all,
> > >
> > > I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9
> > > command-line binaries.
> > >
> > > I have a working copy checked out (C:\wc). Inside it, there's an empty
> > > folder that's source-controlled (C:\wc\logs). If I delete the .svn
> folder
> > > from within logs, then doing an "svn st" in the base folder (C:\wc)
> gives
> > > me:
> > >
> > > C:\wc>svn st
> > > ~ log
> > >
> > > Trying to update to "bring back" the folder shows a delete:
> > > C:\wc>svn up
> > > D log
> > > Updated to revision 200374.
> > >
> > > The folder is still there, without a .svn folder inside it, and svn
> doesn't
> > > know what to do with it.
> > > C:\wc>svn st
> > > ? log
> > >
> > > At this point, the repository still shows the folder (the delete
> didn't
> > > happen on the server). After deleting the log folder, svn thinks
> > > everything's fine (even though the folder is now totally missing from
> the
> > > working copy)
> > >
> > > C:\wc>svn st
> > >
> > > Reverting the folder to bring it back does nothing:
> > > C:\wc>svn revert log
> > > Skipped 'log'
> > >
> > > Doing a general update doesn't work:
> > > C:\wc>svn up
> > > At revision 200376.
> > >
> > > Only by doing an update directly to log can I get the folder back:
> > > C:\wc>svn up log
> > > A log
> > > Updated to revision 200376.
> > >
> > > There are reasons that I probably shouldn't have this skeleton under
> source
> > > control in the first place, but this seems like broken behavior
> regardless.
> > > Should I file it as a bug? Or is it already known?
> > >
> >
> > I wouldn't file a bug. Per-directory .svn directories are disappearing
> in
> > 1.7,
> Will per-directory .svn's remain as an option in 1.7+? (I thought yes...)
>
> Not to my knowledge. I wasn't aware of the use case (aside from
> severable working copies) that engendered this need.
>
How are the 1.7 WC libraries going to determine if a folder is part of a WC? Are they going to have to walk the file system backwards all the way to the root? That seems like a bit of a perf hit for large projects with a deep level of nested folders?
How will it work with Nested checkouts?
For example if I do:
svn co ^/MyProjectFolder ProjectName
cd ProjectName
svn co ^/MyDocumentationProject doc
You can do this now... as a matter of fact we do. Well there be a .svn folder in ProjectName and one in doc? Or will the .svn folder in ProjectName contain the metadata for the doc folder as well?
BOb
Re: Strange status if .svn folder removed
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Thu, May 27, 2010 at 3:02 PM, Daniel Shahaf <d....@daniel.shahaf.name>wrote:
> Hyrum K. Wright wrote on Wed, 26 May 2010 at 16:16 -0500:
> > On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong
> > <st...@gmail.com>wrote:
> >
> > > Hello all,
> > >
> > > I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9
> > > command-line binaries.
> > >
> > > I have a working copy checked out (C:\wc). Inside it, there's an empty
> > > folder that's source-controlled (C:\wc\logs). If I delete the .svn
> folder
> > > from within logs, then doing an "svn st" in the base folder (C:\wc)
> gives
> > > me:
> > >
> > > C:\wc>svn st
> > > ~ log
> > >
> > > Trying to update to "bring back" the folder shows a delete:
> > > C:\wc>svn up
> > > D log
> > > Updated to revision 200374.
> > >
> > > The folder is still there, without a .svn folder inside it, and svn
> doesn't
> > > know what to do with it.
> > > C:\wc>svn st
> > > ? log
> > >
> > > At this point, the repository still shows the folder (the delete didn't
> > > happen on the server). After deleting the log folder, svn thinks
> > > everything's fine (even though the folder is now totally missing from
> the
> > > working copy)
> > >
> > > C:\wc>svn st
> > >
> > > Reverting the folder to bring it back does nothing:
> > > C:\wc>svn revert log
> > > Skipped 'log'
> > >
> > > Doing a general update doesn't work:
> > > C:\wc>svn up
> > > At revision 200376.
> > >
> > > Only by doing an update directly to log can I get the folder back:
> > > C:\wc>svn up log
> > > A log
> > > Updated to revision 200376.
> > >
> > > There are reasons that I probably shouldn't have this skeleton under
> source
> > > control in the first place, but this seems like broken behavior
> regardless.
> > > Should I file it as a bug? Or is it already known?
> > >
> >
> > I wouldn't file a bug. Per-directory .svn directories are disappearing
> in
> > 1.7,
>
> Will per-directory .svn's remain as an option in 1.7+? (I thought yes...)
Not to my knowledge. I wasn't aware of the use case (aside from severable
working copies) that engendered this need.
-Hyrum
Re: Strange status if .svn folder removed
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Hyrum K. Wright wrote on Wed, 26 May 2010 at 16:16 -0500:
> On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong
> <st...@gmail.com>wrote:
>
> > Hello all,
> >
> > I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9
> > command-line binaries.
> >
> > I have a working copy checked out (C:\wc). Inside it, there's an empty
> > folder that's source-controlled (C:\wc\logs). If I delete the .svn folder
> > from within logs, then doing an "svn st" in the base folder (C:\wc) gives
> > me:
> >
> > C:\wc>svn st
> > ~ log
> >
> > Trying to update to "bring back" the folder shows a delete:
> > C:\wc>svn up
> > D log
> > Updated to revision 200374.
> >
> > The folder is still there, without a .svn folder inside it, and svn doesn't
> > know what to do with it.
> > C:\wc>svn st
> > ? log
> >
> > At this point, the repository still shows the folder (the delete didn't
> > happen on the server). After deleting the log folder, svn thinks
> > everything's fine (even though the folder is now totally missing from the
> > working copy)
> >
> > C:\wc>svn st
> >
> > Reverting the folder to bring it back does nothing:
> > C:\wc>svn revert log
> > Skipped 'log'
> >
> > Doing a general update doesn't work:
> > C:\wc>svn up
> > At revision 200376.
> >
> > Only by doing an update directly to log can I get the folder back:
> > C:\wc>svn up log
> > A log
> > Updated to revision 200376.
> >
> > There are reasons that I probably shouldn't have this skeleton under source
> > control in the first place, but this seems like broken behavior regardless.
> > Should I file it as a bug? Or is it already known?
> >
>
> I wouldn't file a bug. Per-directory .svn directories are disappearing in
> 1.7,
Will per-directory .svn's remain as an option in 1.7+? (I thought yes...)
> and it's unlikely that the bug (if that's what it is) would be address
> specifically for the 1.6.x line.
>
> -Hyrum
>
Re: Strange status if .svn folder removed
Posted by Steve Armstrong <st...@gmail.com>.
Wow, that was a fast reply.
Ok, I'll just work around it for now then. Thanks for getting back to me.
On Wed, May 26, 2010 at 5:16 PM, Hyrum K. Wright <
hyrum_wright@mail.utexas.edu> wrote:
>
>
> On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong <
> steve.armstrong@gmail.com> wrote:
>
>> Hello all,
>>
>> I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9
>> command-line binaries.
>>
>> I have a working copy checked out (C:\wc). Inside it, there's an empty
>> folder that's source-controlled (C:\wc\logs). If I delete the .svn folder
>> from within logs, then doing an "svn st" in the base folder (C:\wc) gives
>> me:
>>
>> C:\wc>svn st
>> ~ log
>>
>> Trying to update to "bring back" the folder shows a delete:
>> C:\wc>svn up
>> D log
>> Updated to revision 200374.
>>
>> The folder is still there, without a .svn folder inside it, and svn
>> doesn't know what to do with it.
>> C:\wc>svn st
>> ? log
>>
>> At this point, the repository still shows the folder (the delete didn't
>> happen on the server). After deleting the log folder, svn thinks
>> everything's fine (even though the folder is now totally missing from the
>> working copy)
>>
>> C:\wc>svn st
>>
>> Reverting the folder to bring it back does nothing:
>> C:\wc>svn revert log
>> Skipped 'log'
>>
>> Doing a general update doesn't work:
>> C:\wc>svn up
>> At revision 200376.
>>
>> Only by doing an update directly to log can I get the folder back:
>> C:\wc>svn up log
>> A log
>> Updated to revision 200376.
>>
>> There are reasons that I probably shouldn't have this skeleton under
>> source control in the first place, but this seems like
>> broken behavior regardless. Should I file it as a bug? Or is it already
>> known?
>>
>
> I wouldn't file a bug. Per-directory .svn directories are disappearing in
> 1.7, and it's unlikely that the bug (if that's what it is) would be address
> specifically for the 1.6.x line.
>
> -Hyrum
>
Re: Strange status if .svn folder removed
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong
<st...@gmail.com>wrote:
> Hello all,
>
> I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9
> command-line binaries.
>
> I have a working copy checked out (C:\wc). Inside it, there's an empty
> folder that's source-controlled (C:\wc\logs). If I delete the .svn folder
> from within logs, then doing an "svn st" in the base folder (C:\wc) gives
> me:
>
> C:\wc>svn st
> ~ log
>
> Trying to update to "bring back" the folder shows a delete:
> C:\wc>svn up
> D log
> Updated to revision 200374.
>
> The folder is still there, without a .svn folder inside it, and svn doesn't
> know what to do with it.
> C:\wc>svn st
> ? log
>
> At this point, the repository still shows the folder (the delete didn't
> happen on the server). After deleting the log folder, svn thinks
> everything's fine (even though the folder is now totally missing from the
> working copy)
>
> C:\wc>svn st
>
> Reverting the folder to bring it back does nothing:
> C:\wc>svn revert log
> Skipped 'log'
>
> Doing a general update doesn't work:
> C:\wc>svn up
> At revision 200376.
>
> Only by doing an update directly to log can I get the folder back:
> C:\wc>svn up log
> A log
> Updated to revision 200376.
>
> There are reasons that I probably shouldn't have this skeleton under source
> control in the first place, but this seems like broken behavior regardless.
> Should I file it as a bug? Or is it already known?
>
I wouldn't file a bug. Per-directory .svn directories are disappearing in
1.7, and it's unlikely that the bug (if that's what it is) would be address
specifically for the 1.6.x line.
-Hyrum
Re: Strange status if .svn folder removed
Posted by Stein Somers <ss...@opnet.com>.
On 27-May-10 21:03, Erik Huelsmann wrote:
> On Thu, May 27, 2010 at 8:55 PM, Stein Somers<ss...@opnet.com> wrote:
>> On 26-May-10 23:37, Daniel Becroft wrote:
>>>
>>> Now SVN knows the folder is unversioned ...
>>
>> But only according to the false assumption it made that the folder was
>> deleted from the repository.
>
> Surely not: you removed any way for it to know what you have locally
> is what is in the repository.
Surely not what? The local folder is still obstructing, so svn st should
continue to report it as such.
The fact that it switched its mind from obstructing to unversioned
confirms that svn thinks the folder is deleted in the repository.
I can reproduce this bug (1.6.11 client and server). Indeed not
important enough for 1.6.x, but that workaround may be very handy.
--
Stein
Re: Strange status if .svn folder removed
Posted by Erik Huelsmann <eh...@gmail.com>.
On Thu, May 27, 2010 at 8:55 PM, Stein Somers <ss...@opnet.com> wrote:
> On 26-May-10 23:37, Daniel Becroft wrote:
>>
>> The folder is still there, without a .svn folder inside it, and svn
>> doesn't know what to do with it.
>> C:\wc>svn st
>> ? log
>>
>>
>> Now SVN knows the folder is unversioned ...
>
> But only according to the false assumption it made that the folder was
> deleted from the repository.
Surely not: you removed any way for it to know what you have locally
is what is in the repository. The 'log' directory you have locally
can't be overwritten with what's in the repository because they *may*
not be the same thing. If they are not, Subversion would be destroying
data if it would overwrite it.
How do you get to the conclusion the assumption is that the folder was
deleted from the repository?
Bye,
Erik.
Re: Strange status if .svn folder removed
Posted by Stein Somers <ss...@opnet.com>.
On 26-May-10 23:37, Daniel Becroft wrote:
> The folder is still there, without a .svn folder inside it, and svn
> doesn't know what to do with it.
> C:\wc>svn st
> ? log
>
>
> Now SVN knows the folder is unversioned ...
But only according to the false assumption it made that the folder was
deleted from the repository.
I get in a similar state when updating and there is a tree conflict
between an incoming add and a local add (both of a file). Resolving or
reverting ends up making the working copy believe that the file doesn't
exist anywhere. The only way to restore order seems to be to completely
delete the parent folder (and its .svn of course) and update the working
copy again.
--
Stein
Re: Strange status if .svn folder removed
Posted by Daniel Becroft <dj...@gmail.com>.
On Thu, May 27, 2010 at 7:06 AM, Steve Armstrong
<st...@gmail.com>wrote:
> Hello all,
>
> I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9
> command-line binaries.
>
> I have a working copy checked out (C:\wc). Inside it, there's an empty
> folder that's source-controlled (C:\wc\logs). If I delete the .svn folder
> from within logs, then doing an "svn st" in the base folder (C:\wc) gives
> me:
>
> C:\wc>svn st
> ~ log
>
According to the help, '~' means: versioned item obstructed by some item of
a different kind. In other words, the normally versioned 'log', is blocked
by the (now) unversioned 'log'. Removing the .svn folders mean that SVN
cannot determine anything else about this folder.
> Trying to update to "bring back" the folder shows a delete:
> C:\wc>svn up
> D log
> Updated to revision 200374.
>
This is probably the only unexpected result from the commands so far.
> The folder is still there, without a .svn folder inside it, and svn doesn't
> know what to do with it.
> C:\wc>svn st
> ? log
>
Now SVN knows the folder is unversioned ...
> At this point, the repository still shows the folder (the delete didn't
> happen on the server). After deleting the log folder, svn thinks
> everything's fine (even though the folder is now totally missing from the
> working copy)
>
> C:\wc>svn st
>
> Reverting the folder to bring it back does nothing:
> C:\wc>svn revert log
> Skipped 'log'
>
... and because it's unversioned, revert does nothing.
> Doing a general update doesn't work:
> C:\wc>svn up
> At revision 200376.
>
> Only by doing an update directly to log can I get the folder back:
> C:\wc>svn up log
> A log
> Updated to revision 200376.
>
> There are reasons that I probably shouldn't have this skeleton under source
> control in the first place, but this seems like broken behavior regardless.
> Should I file it as a bug? Or is it already known?
>
The moral of the story, is to not mess with the .svn folders.
Cheers,
Daniel B.