On Tue, Aug 08, 2000 at 04:15:13PM -0700, John P Cavanaugh wrote:
> On Tue, Aug 08, 2000 at 10:47:32AM -0500, Karl Fogel wrote:
> > 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.
>
> This point was beginning to alarm me as well.
Personally, I want to have a local copy of the entire repository!
(obviously not in 1.0). For why, see the archives. But I do agree
that the 100% or more disk space penalty is unacceptable in some
environments, and would be glad to see a configuration option for this.
Another possibility which hasn't come up is to store the contents of
the base directory compressed. Both gzip and bzip2 have library
interfaces.
This isn't exactly related, but I'd like - at least as an option - to
have the SVN subdir renamed ".SVN" so it didn't get caught by casual
globbing in the work area. (e.g. "grep <string> *" bitches about
"CVS: is a directory" if you try it in a CVS checkout).
And I wonder if it might make sense to keep the metadata entirely
outside the checked-out tree. Instead of
foo.c
bar.c
SVN/base/foo.c
SVN/base/bar.c
SVN/properties
SVN/versions
SVN/...
baz/quux.c
baz/SVN/...
you'd have
base/foo.c
base/bar.c
base/baz/quux.c
cur/foo.c
cur/bar.c
cur/baz/quux.c
meta/properties
meta/versions
meta/...
Advantages: metadata never gets included in a tree walk; recursive
diffs can be done with vanilla diff; no namespace conflicts.
Disadvatages: slower, possibly confusing.
> > (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.)
>
> Well this depends on what a svn diff does.
>
> Does it:
> a) Show differences in the local copy from its original parent
> b) Show differences in the local copy from the latest version on
> a branch
Whichever one you want it to, I hope. (And a 3-way diff between
local, tip, and GCA should be possible, too - I hate not being able to
get that from CVS.)
zw
Received on Sat Oct 21 14:36:06 2006