On Sun, Feb 14, 2010 at 05:07:05PM -0500, Glenn Maynard wrote:
> On Sun, Feb 14, 2010 at 9:45 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> > copy. Beyond 1.7 there are plans to make this configurable so that
> > you could have it in ~/.subversion and shared across all your working
> > copies. Of course the default will be the same as it will be in 1.7.
>
> That sound brittle. Users would need to inform Subversion about
> deleted working copies (to drop references to text-bases, etc.),
The WC holds the references to the pristine store.
So if the WC is deleted, so are references it has to the pristine store,
without doing anything special.
> which
> would inevitably not always happen, leading to accumulating cruft.
> It'd also break when the shared path can't be found (eg. shared NFS
> mounts, moving/renaming home directories).
If people enable this feature, they need to make the shared store is
always accessible. We haven't quite yet found out how to do magic, sorry ;)
> (I assume the actual
> working copies would be matched to its metadata on a UUID basis, so at
> least moving and renaming the working copies themselves would be
> unaffected.)
Note that there's a difference between the WC meta-data and the
pristine store. The meta-data (stored in sqlite) is always at the
root of the WC, whether or not the pristine store is shared.
> >> Hopefully there'll still be a way to slice out a piece of a repository
> >> ("mv wc1/trunk .; rm -rf wc1"), which wouldn't work if it's dependent
> >> on a global db at the top.
> >
> > There has been talk of adding a svn detach command to do this. Not
> > sure if it will be done as part of 1.7. AFAIK, the plan is to add it
> > later.
>
> Hmm. It's very unusual for Subversion upgrades to take away
> functionality and say "we'll fix this later".
It's unusual, but not avoidable if we want to release 1.7 any time this
year. There's a load of work and limited developer resources, so compromise
needs to be made for certain things.
The functionality you speak of happens to work because of the way the
1.6 working copy format has been modeled on CVS. I'm not sure if
detaching subtrees from a working copy was a high priority design goal
to begin with, or if it was a side effect. I'd suspect the latter.
It is a bit contradictory to the "working copies are cheap and
disposable" mantra.
> I don't see anything wrong with this, but the "space savings" and
> "performance" benefits hinge on the shared store.
Not quite.
Performance will increase already once there's a single .svn directory.
A lot of i/o overhead is caused by reading files from the .svn dirs
scattered all over the place.
See http://mail-archives.apache.org/mod_mbox/subversion-dev/201002.mbox/%3C4B72AACA.6080909@artvps.com%3E
> I suspect the real
> benefits are infrastructural, rather than user-visible.
The infrastructural benefits within the code are already massive indeed.
Stefan
Received on 2010-02-14 23:30:46 CET