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

Re: Compressed text-base patch

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-04-28 04:37:42 CEST

On Sun, 2003-04-27 at 21:35, junkio@cox.net wrote:
> If that assumption holds, however, I wonder if it would be
> simpler just to make checked-out files read-only by default, and
> make text-base hardlinks to them. This would further save the
> client side diskspace. Perhaps you can add a new command "svn
> edit" that breaks the hardlink and make the working copy file
> writable.

Compressed text-bases are a compromise: a relatively simple change that
can be made now, without massive restructuring of libsvn_wc, which might
alleviate some of the space penalty of text bases. Whether it's a good
idea will depend on performance numbers; some of the CPU cost will be
made up for in decreased I/O overhead, but we don't know how much yet,
or how much space compressed text bases will save on average.

A long-term solution might involve the option of starting checked-out
files read only (which can have other benefits, such as advisory locking
and fast scanning for modified files) or it might simply involve
teaching libsvn_wc to fetch a text-base from the repository when one is
missing. But it's unlikely that either of those things will be
implemented before 1.0, because they would be destabilizing and
complicated changes.

Your particular implementation suggestion has several problems, both in
the realm of the practical short term and the theoretical long term:

  * Requiring an "svn edit" before changing a file does not fit the
    default CVS model--and we want to preserve that aspect of the
    model. So read-only working copy files can't be the only choice.
    Having multiple different kinds of working copies greatly increases
    the complexity of libsvn_wc, which is definitely unacceptable in the
    short term (because libsvn_wc is considered a bit of a disaster at
    the moment) and problematic in the long term.

  * As currently designed, the text-base does not, in general, have the
    same contents as the working copy. The text-base always matches the
    repository contents precisely, while the working copy is
    newline-translated and keyword-expanded if appropriate.

  * Hard-linking the text base to the working copy file doesn't buy
    anything over simply omitting the text base, if the working copy
    hasn't been modified. (People have suggested hard-linking the two
    together and hoping that editors will break the hard link rather
    than overwriting both copies of the file on a save operation, thus
    removing the need for an "svn edit" operation, but that's not how
    editors generally work by default, and version-controlled files are
    often written by tools other than editors.)

  * Hard links don't exist on Windows. Hard links between files in
    different directories don't work in OpenAFS.

This idea comes up and gets knocked down over and over again on this
list. I guess there isn't much to be done about that.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 28 04:38:28 2003

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.