[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: Mark Mielke <mark_at_mark.mielke.cc>
Date: Sun, 14 Feb 2010 18:47:46 -0500

On 02/14/2010 06:19 PM, Glenn Maynard wrote:
> On Sun, Feb 14, 2010 at 5:30 PM, Stefan Sperling<stsp_at_elego.de> wrote:
>
>> 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.
>>
> How could a reference to "~/.subversion/shared/SHA" be stored in a way
> that a reference to it (presumably in a database somewhere) is
> removed, and the shared file deleted (if it's the final reference),
> when I rm -rf a WC?
>

Garbage collection?

But don't get ahead of things - the fact is that a shared ~/.subversion
would result is massive storage savings if the users has multiple
related workspaces. Figuring out how to manage ~/.subversion is a
technical issue to be solved down the road once this capability exists.

For my own uses, we have workspaces that are Gbytes in size, and users
that want to have multiple releases checked out. Having a per-user
shared content, or even something like GIT has with common multi-user
accessible shared content, would make things hugely more beneficial for us.

Even if it NEVER gets removed - it's still some part of history for the
project, and it may become useful again. For small repositories, who
cares? For large repositories, it is hugely beneficial although unsolved
how to keep the space manageable.

Heck, if one can ask the server for missing pristine copies - why not
treat it like a "least recently used" cache, where users can cap the
shared pristine copy to a certain size, and it will download the missing
pristine copies as required when it needs them, rather than always
keeping everything local?

Cheers,
mark

-- 
Mark Mielke<mark_at_mielke.cc>
Received on 2010-02-15 00:48:23 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.