Benjamin Pflugmann wrote:
> Ben, what are your thoughts on a changed plan? Has something like this
> a better (well, realistic) chance to be accepted:
>
> A. (Might exist already) Store in the .svn admin area checksums of the
> base copies.
>
> B. Assure that all places using the prestine base copy do something
> sensible when it is missing (probably give a reasonable error) and
> make a list of them for later.
>
> C1. Add a "--no-base-copy" option to "svn checkout".
> C2. Add a "prepare-edit" command to "svn" that will copy the
> working copy into the base copy (if the checksums match).
> C3. Add some fetch-base command/option (could be combined with C2).
> C4. Add a cleanup-base-copies command/option.
Hmm, C4 would be nice but not a strict requirement.
> All that is needed to have a basic version running wouldn't require
> big changes to existing code, as far as I can see. Mainly some
> if-condition to "svn checkout" and some updates to the error messages
> (to be sure they make sense in the new context).
>
> I hope others agree that this should be possible for 1.0. If the
> fetch-bases command becomes "intelligent", it would be quite usable,
> too. At least better than nothing. :-)
How "intelligent" would fetch-bases need to be? Would it be enough to
simply fetch the bases of the files that fail the checksum-check?
> After that works one could determine when to change the other points:
>
> D. Tweak libsvn_wc/diff.c:file_diff to fetch a pristine copy from the
> server if a cached base version is not available. The downloaded
> pristine copy should be cached.
> E. Change the commit/merge to send the whole working copy instead
> of fetching a base copy from the server and send back the diff,
> if the .svn does not contain the base copy.
> F. Whatever else needs tweaking for automagically working.
If "fetch-bases" is intelligent (as you suggested above), then
there is no more reason to tweak the diff or the commit/merge
procedures. AFAICS the diff on the text-base will be done only
when svn_wc_text_modified_p() says to do so. Just let diff, commit,
merge and all the other commands which could potentially need the
text-bases call fetch-bases before calling file_diff. It would not
even do a harm if every command (except fetch-bases, of course)
would implicitly call fetch-bases. Umm, this way the user-visible
fetch-bases command could die. And very little existing code would
be modified. Therefore the main reason for not putting such a
change into 1.0 would disappear.
Hmm... If _every_ command would implicitly call fetch-bases then
your step "B." would not be necessary anymore since the required
base would already exist at the time the actual command would be
run.
So the six-step-plan might look like this:
A. Store checksums (might exist already) (_does_ this already exist?
I don't think so)
B. modify svn_wc_text_modified_p() to use checksums if the text_base
is missing.
C. Add an "intelligent" fetch_bases() library call that fetches all
the bases of the files that fail the checksum test. Fetch_bases()
could ask svn_wc_text_modified_p() to determinde which files to
fetch.
C. Let every command that potentially could need a text-base call
fetch_bases() before doing the real work.
D. Add --no-base-copy
F. (optionally) add prepare-edit and/or cleanup-base-copy
Doing the change this way, very little modifications to existing code
would be necessary.
Hmmm, might it be that the fruit hangs not _that_ high as anybody
was thinking? But I am sure I have missed sime important details.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 25 12:35:39 2003