On Thu, May 27, 2010 at 7:06 AM, Steve Armstrong
<steve.armstrong_at_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.
Received on 2010-05-26 23:38:24 CEST