> > I expect the primary reason that Subversion working copies store a
> > meta-data folder within each versioned folder is that CVS did it that
> > way. The only real redeeming feature of this approach is that each
> > working copy folder is itself a self functioning working-copy.
>
> Apart from CVS doing it that way, back in the day when the librarie
> grew up, this was considered a prime feature!
My point was that providing the detachability in this manner was the
result of observing how CVS provided it - yet as many point out,
providing a detach command would provide the capability whilst
unencumbering the working copy from this distributed administration.
> I'm not eactly sure if I understand you correctly, but I think the
> current design of the lib is as straight foward as it's going to get.
> What's really problematic is all the edge cases you'll be dealing
> with: what should happen if an update changes a directory to a file,
> yet the directory contains local changes?
My response was pointing out that the effort is larger than merely
relabeling some paths in the working copy code - specifically for the
edge-cases you note (and others).
> > On the other hand, I believe it will prove to be critical to
> > Subversions continuing popularity to update it's working copy model -
> > for a number of reasons that I think are more important than the
> > convenience of not scattering meta-data folders throughout the working
> > copy.
>
> The committers see these problems too. However, the current state of
> the code does not really allow anything other than small additions of
> features. A rewrite of the code is required to achieve anything major.
Agreed. In fact I think the effort is probably wasted to try and
massage the existing code to make this small improvement. It's a more
complicated change than the benefits warrant.
> I am one of them and have talked to several others who would like to
> start working on exactly this change. The current focus is
> merge-tracking, though.
I'm surprised people are looking at this change (simply moving
existing administration into a parallel tree) as worth the effort by
itself.
> Given the number of unfotunate choices we made as the library
> developed...
Heh, hindsight and all...
>... I doubt anybody would rewrite it in such a way that it
> wuold solve the major issues. But, yes, help is always welcome.
I'm yet to get up to speed with the source-structure and it's been a
decade since I looked at C with any serious intent - we shall have to
see.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 28 00:49:33 2007