On Mon, Mar 24, 2008 at 4:17 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> I was surprised today to find that 'svn resolved' (so named with a
> past-tense verb explicitly because we wanted users to understand that it
> doesn't actually itself perform resolution steps) accepts the --accept
> option and now *does* perform resolution steps. This despite still claiming
> in its usage message:
>
> $ svn help resolved
> resolved: Remove 'conflicted' state on working copy files or directories.
> usage: resolved PATH...
>
> Note: this subcommand does not semantically resolve conflicts or
> remove conflict markers; it merely removes the conflict-related
> artifact files and allows PATH to be committed again.
>
> ...
>
> I suggested in IRC that this is somewhat confusing for users, who might be
> led to think that they now need to tell 'svn resolved' *how* they resolved
> conflicts, with the result being that 'svn resolved' will then try to
> perform said resolution again, possibly resulting in errors or -- worse --
> in wasted conflict resolution efforts. I'd rather see a new subcommand 'svn
> resolve' for this active behavior, and retain 'svn resolved' for the passive
> work it has always performed.
>
> Eric Gillespie seemed to agree, noting that he envisions an 'svn resolve'
> subcommand that can do the full range of interactive conflict resolution
> magic someday (which gets a hearty +1 from me), but his initial willingness
> to bifurcate today's 'resolved' subcommand was doused by Mark Phippard's
> insistence that all is well (or at least well enough) with the UI as it is
> today.
>
> What do others think?
I think the existing UI is pretty clear (help text obviously needs
some fixup). I am sure there are some users that could become
confused. Why not just add a new option like --accept=current or
in-place or something like that. This at least gives the user that
thinks they need to specify an option, an option that does not change
the contents of the file.
Adding a new subcommand, especially one that varies by a single
character, does not seem like a solution. Why would users not be
confused by the new subcommand? Do I have to run svn resolved after I
run svn resolve? etc. What are you proposing for the syntax of the
new subcommand? I am assuming same as resolved is today, except that
--accept becomes mandatory? If we make a new sub-command should it be
svn accept ? Probably not.
I am commenting because I really like the new feature, and like the
way we were able to integrate it into Subclipse. I am sure
TortoiseSVN did the same. I do not find it confusing and just do not
see that the value here is justified. To me, it made sense to use the
same command. I felt like I was marking the conflicts as resolved, by
choosing a specific version of the file. It never felt weird to me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-03-24 21:29:08 CET