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

Re: Changing the "native" newline mode

From: Glenn Maynard <glenn_at_zewt.org>
Date: Sun, 14 Feb 2010 17:07:05 -0500

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

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

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