Issues #3048 and #3049 are very similar. They both concern the new
interactive conflict resolution interface, and are about getting our
UI right so users can habituate to it. I'll summarize both issues
here, and then make an interim proposal that allows us to ship 1.5
with a safely "habituable" UI.
* #3048: conflict resolver needs more useful "diff" option
The conflict resolver's (d)iff option diffs the pre-update "base"
file against the merged-with-conflict markers file. But this is
often too much diff: if the update merged lots of stuff cleanly
and conflicted on a few small parts, this will show an enormous
diff with only a few parts even in conflict. While that might be
useful in some cases, we at least should consider the option of
showing (say) the diff between the file you'd get if you chose
all the left-side choices and the file you'd get if you chose all
the right-side choices.
* #3049: conflict resolver API should provide a way to say "resolve
all conflicting blocks in direction x"
There should be an accept value for the conflict resolver that
means "run diff3 but resolve all conflict blocks as in 'mine'"
and another that goes the other way. This is different from the
curent '(m)ine' and '(t)heirs', because those options wipe out
the non-conflicting chunks too.
In the issue, Mike Pilato proposes this solution: we let (m)ine
and (t)heirs only make determinations on conflicting hunks, and
reserve (M)ine and (T)heirs for mine-in-full and theirs-in-full.
While it would be nice to implement everything proposed above, there
may not be time before 1.5. However, there is something we can do:
reserve the appropriate single-letter commands now, so that users'
reflexes develop in a future-compatible way. Thus, I propose:
1) Change "(d)iff" to "(D)iff" now, and have it continue behaving
the same as it does currently (that is, shows the big diff).
2) Reserve lower-case "(d)iff" now, but don't display it in the
list of command choices. If the user types it, display a simple
message indicating that it's not-yet-implemented, and point
to the appropriate issue URL for more information.
3) Likewise change "(m)ine" and "(t)heirs" to "(M)ine" and "(T)heirs",
preserving the current in-full behavior.
4) Likewise reserve lower-case "(m)ine" and "(t)heirs" for the
future behaviors, as per (2).
I think the above should be done as one change, and ported to 1.5.
Then if we are actually able to implement the lower-case stuff for
1.5, great, let's do it, or as much of it as we can! But if we don't,
at least we'll have reserved the command space for 1.6. Mainly, I
don't want #3048 and #3049 blocking 1.5's shipping; this proposal is a
solution for that.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-04 21:28:52 CET