[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Clean copies of files in working directory

From: John P Cavanaugh <cavanaug_at_soco.agilent.com>
Date: 2000-08-09 01:15:13 CEST

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.

> 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.


    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
Received on Sat Oct 21 14:36:06 2006

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.