> 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?
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
Received on 2010-05-27 22:40:48 CEST