Zack Weinberg <zack@codesourcery.com> writes:
> 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.
Frankly, I've always thought the <<<<< >>>>>> thing is preferable.
Our decision to use .rej files was not because we thought them better
than conflict markers, but because it was all we [thought we] were
able to do, given time constraints and the decision to use GNU diff
(we didn't realize diff3 could do in-place markers).
There may be some people who, post facto, prefer the new way, but does
anyone prefer it strongly? I personally hate resolving conflicts now,
it's so much less convenient than the CVS way...
> 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.
IMHO, we don't want to keep the .rej files. Let's use conflict
markers instead, and use a timestamp to tell if the conflict should be
considered resolved. I.e., if the file has been modified since it
received the conflict, we assume the conflict is resolved. We don't
check if conflict markers are present or absent -- that's too likely
to prevent "valid" commits, and if we have the timestamp solution
anyway, that's enough.
Comments? Suggestions? Rotten fruit? :-)
-Karl
---------------------------------------------------------------------
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