Greg Hudson <ghudson@mit.edu> writes:
> The following Subversion design decision has been eating at me since I
> read about it:
>
> A @file{base} directory, containing the pristine repository
> versions of the files in the corresponding working directory,
> and their properties.
>
> I'm a bit concerned about quietly adding a 100% disk space penalty on
> working directories. I understand the benefit of sending patches from
> the client side, but at least for the project I care about here, I
> would gladly sacrifice the bandwidth required to fetch pristine copies
> of modified files from the repository in order to cut my working
> directory sizes in half.
Yes, you're not the only one. I think the plan is that an early
improvement to Subversion will be to make this optional and use
hashes/datestamps like CVS does. Whether that happens before or after
"1.0" is more a matter of when one chooses to apply the "1.0" label
than when the feature actually gets done.
(Note that the benefit is not just the client being able to send
patches to the server, but having "svn diff" and reversions be fast
local operations.)
> So, can we think about making this optional? From a protocol point of
> view, I don't think we need any special allowances for that, but the
> client-side design may need some thought in terms of the ability to
> generate skeltas without pristine copies (using checksums, perhaps, or
> perhaps just mod times) and being willing to fetch pristine copies
> when necessary.
Yeah, the client will not be written in such a way that it's hard to
optionalize the dependency on a pristine base tree.
Received on Sat Oct 21 14:36:06 2006