RE: text-base penalty: A proposed solution

OK, cool

So, the benefit would be, on a humungeous project, where the client-user is
working on 10% of the total files:

Storage needed by client using current scheme = 2 * H
Storage needed by client using proposed scheme = 1.1 * H

This would be a saving of 0.9/2.0 or 45 %

-----
I just created a repo for an old project of mine, and then did a checkout
into a clean directory. Doing a 'du' on the client-side directory gives 871
blocks,

of which 153+25+104+25+110+25+67+91= 600 blocks are .svn directories

94+4+52+4+58+4+17+37= 270 blocks are text-base directories within the .svn

So, going along with the model above, we should be able to save 90% of the
text-base files or 243 blocks out of 871 or 243/871 = 28 %

This is not quite 45 %. I don't know what happens when H gets larger, or
more changes get checked in, but at least this is a datapoint.

----
Doing the 'du' on my repo directory gives 2024 blocks (!!)
BobG
Kean Johnston wrote on 17 Dec 2002 09:48:04 -0800
  Bob Gustafson wrote a bit earlier:
>> 1) There would be a change in the (remote) repository, so
>> that it would understand the new commands and also store the
>> checksums.
>The remote would need to understand the "edit" command if we
>wanted advisory locking (or even mandatory if the admin wanted
>it that way) but is otherwise unchanged. The checksums are
>stored client-side, as a replacement for the duplicate text-base
>copy of each file. If there is no desire for locking, then the
>remote doesn't change at all, and 'svn edit' becomes a purely
>client-side operation.
>
>> 2) The client side .svn files would NOT have a complete copy
>> of all of the root (pristine) files, but only the root files
>> that the client-side person is actually editing, as well as
>> checksums for all other files. This could be compressed too.
>Yup, that's the meat of my proposal - replace the duplicate
>text base with a single file of checksums until such time as
>the client decides to change something, and only THEN do we
>copy over a pristine version.
>
>> 3) The client side working directories would contain all of
>> the project files as currently - this is to support building
>> and testing at the client side.
>Yes. In terms of normally visible files, the WC doesn't change.
>All of this magic happens in the hidden .svn directory.
>
>Kean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org