[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Interim proposal for #3048, #3049 (interactive diff / resolution)

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Mon, 04 Feb 2008 15:27:00 -0500

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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.