On Thu, May 27, 2010 at 3:40 PM, Bob Archer <Bob.Archer_at_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
> > > <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
> > > >
> > > > 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
Received on 2010-05-27 23:17:52 CEST