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