You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@galois.collab.net> on 2000/08/08 15:47:32 UTC
Re: Clean copies of files in working directory
Greg Hudson <gh...@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.
Re: Clean copies of files in working directory
Posted by Zack Weinberg <za...@wolery.cumb.org>.
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 <gh...@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
Re: Clean copies of files in working directory
Posted by John P Cavanaugh <ca...@soco.agilent.com>.
On Tue, Aug 08, 2000 at 10:47:32AM -0500, Karl Fogel wrote:
> Greg Hudson <gh...@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.
> 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.
Good, Im glad the thinking is that this would be optional in the future.
> (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
> > 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.
Cool.
-----------------------------------------------------------------------
John Cavanaugh Agilent Technologies
R&D Program Manager 1400 Fountaingrove Pkwy
CAD Data Store Santa Rosa, CA 95403-1799
Email: cavanaug@soco.agilent.com Phone: 707-577-4780
707-577-3948 (Fax)
-----------------------------------------------------------------------
There are two major products to come out of Berkeley:
LSD and UNIX. We don't believe this to be a coincidence.
-- Unknown
-----------------------------------------------------------------------