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.), 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). (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.)
>> 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".
> The storage format for the pristine files will still be files but it
> is being changed to be based on the SHA-1 hash for the files. I'd
> imagine the structure will be sharded based on the first two
> characters of the hash. This will bring several benefits:
I don't see anything wrong with this, but the "space savings" and
"performance" benefits hinge on the shared store. I suspect the real
benefits are infrastructural, rather than user-visible.
--
Glenn Maynard
Received on 2010-02-14 23:07:40 CET