On Thu, May 27, 2010 at 7:06 AM, Steve Armstrong <steve.armstr...@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.
