[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Recurring problem with the SVN structure for WC

From: Talden <talden_at_gmail.com>
Date: 2007-08-28 00:52:04 CEST

> > 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

> 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

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.