> Hyrum K. Wright wrote on Wed, 26 May 2010 at 16:16 -0500: > > On Wed, May 26, 2010 at 4:06 PM, 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 > > > > > > 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
