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