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

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

From: Karl Fogel <kfogel_at_red-bean.com>
Date: Sat, 09 Feb 2008 14:03:43 -0500

"Justin Erenkrantz" <justin_at_erenkrantz.com> writes:
> On Feb 9, 2008 7:27 PM, Karl Fogel <kfogel_at_red-bean.com> wrote:
>> I'd prefer 'm+'/'t+' or even 'mf'/'tf', rather than 'm!'/'t!', because
>> in some editors (ahem, Emacs), '!' can be a command (e.g., in
>> query-replace) that means "answer yes to all the remaining instances,
>> without prompting". That's not the association we want here. I think
> But, isn't that *exactly* the connotation that we want? -- justin

Ah, no. I think you might have the issue backwards?

The current behavior for 'M'/'T' is to take the entirety of the
current 'mine'/'their' file (as opposed to taking the 'mine'/'their'
side for just the conflicting hunks, while merging everything else,
which is the ideal behavior, but one we've not implemented yet).

The 'M'/'T' choice is offered one file at a time. You might choose
differently for the next conflicting file, as your merge (or update,
whatever) proceeds. (Later, when we offer the ideal choices,
mine-for-just-conflicting-hunks and theirs-for-just-conflicting-hunks,
it *still* will apply only to the file under consideration, and not
automatically apply to subsequent files.)

This was the whole problem with the "all" phrasing, in fact: it
wrongly implied that the same choice would apply to subsequent files.
That's why we changed it to "full".

Now, we might want to offer a "apply the current choice to subsequent
files too" option, and "!" might be a good character for that. But
that's a different conversation.

Hope this helps,

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-09 20:03:55 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.