On Fri, May 2, 2008 at 7:57 AM, Karl Fogel <kfogel_at_red-bean.com> wrote:
> glasser_at_tigris.org writes:
> > Log:
> > Retool conflict resolver menu into three sections:
> >
> > Edit the merged file:
> > (e) edit - change merged file in an editor
> > (df) diff-full - show all changes made to merged file
> > (r) resolved - accept merged version of file
> > Just deal with the conflicts (ignoring merged file):
> > (dc) display-conflict - shows all conflicts
> > (mc) mine-conflict - accept my version for all conflicts
> > (tc) theirs-conflict - accept their version for all conflicts
> > General:
> > (p) postpone - mark the conflict to be resolved later
> > (l) launch - launch external tool to resolve conflict
> > (s) show all - show this list
>
> Before criticizing this one minor decision, I want to state how totally
> and completely I love that you are completing the interactive conflict
> resolution feature. Yay!
>
> But, is it really wise to add these section headers? I found the
> categorizations confusing -- like, why are "(e)" and "(l)" in different
> sections? They feel so similar. Same with "(df)" and "(dc)"...
>
> My point is not that the sections need retooling; any categorization is
> going to create similar conundrums. Meanwhile, what does it gain us? A
> user encountering the menu for the first time just has to read all the
> options to make an intelligent choice; as they learn the options through
> repeated exposure (and learn which ones they usually use), the category
> headers are just that much wasted vertical space.
>
> To my eye, they just get in the way of the real information. And I
> think users don't expect real documentation at an interactive prompt.
> Instead, they expect high information density. The prompts don't add
> information, though -- instead, they attempt to organize information
> that's already there. The user will carefully read the prompts only to
> be confused (if they're like me) or at least disappointed, because the
> effort of reading will not pay off with more knowledge. All they'll get
> is someone else's idea of how the various choices could, in theory, be
> categorized. This is not useful to the user, in this context. It would
> be appropriate in a user manual, where organizing information is part of
> the task, just not at an interactive screen prompt.
I definitely appreciate the feedback. My major concern is to make
clear that *only* e/df/r has anything to do with the merged file; if
the user spends time on "e" but then uses either the conflict commands
(dc/mc/tc) or the full-file commands (mf/tf), their work in the editor
will be completely ignored.
Thus, my goal is to organize commands that are intended to be used
together together, not commands that are superficially similar.
If I recall correctly, SVK's similar menu was organized by type of
command (all the accept commands, then all the dif commands, etc); I
always found this confusing and didn't know which commands went well
together.
(I had (l)aunch with (e)dit at first, but actually the (l)aunched
script can do anything it wants with all four files.)
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-05-02 17:30:45 CEST