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

Re: Inconsistent 'show help' commands in `svn resolve` (property conflicts vs text conflicts)

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 13 Jun 2016 17:29:57 +0200

On Mon, Jun 13, 2016 at 06:15:39PM +0300, Pavel Lyalyakin wrote:
> Hello,
> I've been checking the conflict resolution tool to make necessary
> adjustments to SVNBook 1.8 and noticed that text conflict resolution offers
> to press (s) key to show the full list of available commands (e.g. like on
> this screen output[*]):
> [[[
> show all options (s):
> ]]]
> [[[
> (s) - show this list (also 'h', '?')
> ]]]
> As you see, it accepts (s), (?) and (h) keys to show the list of all
> available commands.
> However, the property conflict resolution tool has a different text and it
> does not accept (s) and (?) keys:
> [[[
> $ svn resolve Makefile
> Conflict for property 'abc' discovered on 'Makefile'.
> local add, incoming add upon update
> Select: (p) postpone, (mf) my version, (tf) their version,
> (dc) display conflict, (e) edit property, (q) quit resolution,
> (h) help: s
> Unrecognized option.
> ]]]
> [[[
> (h) - show this help (also '?')
> ]]]
> Was there any special reason to switch (h)elp option to (s)how all options?
> IMO, both tools and the new tree conflict resolution tool have to be
> consistent when it comes to the commands they accept. But I'm not sure
> whether (h)elp is better than (s)how all options as the default key for
> 'help'.
> [*]: http://svnbook.red-bean.com/en/1.8/svn.tour.cycle.html#idp8043776
> --
> With best regards,
> Pavel Lyalyakin
> VisualSVN Team

Hi Pavel,

This was all decided ad-hoc by developers who were working on the code at
a particular point in time. I believe I do remember Ben Collins-Sussman
and Karl Fogel discussing the 's' option on IRC, a long time ago.
We didn't keep public IRC archives back then as far as I know.

Since we're rewriting the conflict resolver anyway, we can change the
interface in pretty much withever way we want, and leave those parts
which we think are good enough in place.

If you're interested in consistency, then I suggest you dive into the code
to make things consistent, and send patches. If you cannot contribute code,
then you could instead compile a list of concrete suggestions about how to
make things consistent, and post it here.

Received on 2016-06-13 17:30:09 CEST

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