>>>>> "GH" == Greg Hudson <ghudson@MIT.EDU> writes:
GH> Your particular implementation suggestion has several problems,...
Thanks for explaining.
GH> * As currently designed, the text-base does not, in general, have the
GH> same contents as the working copy.
GH> * Hard links don't exist on Windows. Hard links between files in
GH> different directories don't work in OpenAFS.
Both very true. I realize the hard-link suggestion does not
make sense much (well, it was not so much as a suggestion to
begin with).
GH> * Requiring an "svn edit" before changing a file does not fit the
GH> default CVS model--and we want to preserve that aspect of the
GH> model. So read-only working copy files can't be the only choice.
Very true. I realize having to say "svn edit" is quite an
inconvenience for an experienced CVS user. "Read-only to save
disk space" should not be the norm.
On the other hand, having to see disk space twice as big as the
source files consumed is also something a user experienced with
CVS would not expect either, though :-).
GH> * Hard-linking the text base to the working copy file doesn't buy
GH> anything over simply omitting the text base, if the working copy
GH> hasn't been modified.
Again, very true. I guess that suggests another alternative, if
the user chooses to save wc disk usage by accepting an added
inconvenience "svn edit" imposes. Check-out stores a read-only
working copy then "svn edit" copies it to the text-base after
normalizing it back into the repository representation. Another
possibility, if the user chooses, would be to re-fetch text-base
lazily when it is needed and wc copy has already been changed
(probably by looking at the checksum in the entries file)---this
would fail "the airplane test", though, so it should require
conscious choice by the user.
But as you point out, the above kind of "possibilities" require
much more code in the wc layer to deal with different cases,
which would automatically make it "later" item.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 28 10:27:35 2003