On Thu, Feb 07, 2002 at 08:22:44PM -0600, Karl Fogel wrote:
> Frankly, it sounds like a good idea, and anyone who has GNU diff
> installed just as easily has GNU diff3.
They come in the same tarball, so yes.
> Zack, would you have time to work up the patch?
I looked into it, and ran into trouble. diff3 doesn't play nice with
the clever model we have where conflicts generate .rej files that have
to be deleted before the file can be checked in again. I get a choice
between three modes. In one, it generates CVS-ish <<<<< >>>>>
brackets around any merge conflicts, and the exit status tells you
whether there were conflicts. In the second, it applies only the
unconflicted diffs and exits code 0 whether or not there were
conflicts. The third mode is the same as the second except it only
applies the conflicted diffs.
Assuming we want to keep the .rej files, I believe this sequence
mimics the current behavior upon true conflicts:
Given a file
diff3 -3m A A.gca A.rep > A.cand
diff3 -xm A A.gca A.rep > A.conf
if diff -c A A.conf > A.rej
then rm A.rej
else inform the user of a conflict in A
fi
rm A.conf
mv A.cand A
[where A contains local changes, A.rep contains the latest version
from the repository, and A.gca contains their greatest common
ancestor.]
but I don't know how to implement that using libsvn_wc's log playback
interface. The most important problem is it appears to abandon
processing if a child spawned by log_run_cmd returns a nonzero exit
status. But patch does return a nonzero exit status if a patch got
rejects, and we keep going, so I don't understand what's going on
here.
(I suppose I could run the first three commands directly from
get_editor.c::close_file(), and decide which commands to put into the
log based on that; would that be the right thing to do?)
Then, a larger question, I don't know whether we do want to keep the
.rej files. Conflict markers can be easier to work with than a
separate file, and that model would make it really easy to plug in a
spiffy graphical conflict-resolution tool like Bitkeeper or ClearCase
have. (To do it in the current model we'd have to keep the GCA and
REP files around.) However, I do like the rule that the presence of a
.rej file causes a subsequent commit to bomb out; I can't think of an
obvious equivalent using conflict markers.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006