Mark Phippard wrote:
> 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.
The new subcommand should take --accept optionally, just as 'svn update'
does, but crawls the working copy to the specified depth and runs the exact
same interactive conflict resolution logic that 'svn update' runs, noting
the --non-interactive flag, noting and optionally (l)aunching the
runtime-configured merge-tool, and so on, just as 'svn update' does. And
yes, if you chose to (p)ostpone resolution interactively, or failed in some
way to indicate that you (r)esolved the conflict, you would need to re-run
'svn resolve' (or hand-edit and run 'svn resolved') -- exactly the way 'svn
update' works. (Are you seeing a pattern here yet?)
'svn resolved' would, of course, go back to *not* taking the --accept option
and not performing conflict resolution.
> 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.
I like the new feature, too. But the ability to integrate it into Subclipse
and TortoiseSVN is entirely unrelated to the experience of the command-line
user. The UI in those graphical tools almost certainly makes it clear that
the user is actively resolving a conflict; a subcommand originally designed
*not* to resolve conflicts, and so named with the past-tense "resolved" to
indicate that the cleanup operation it performs is not actually a resolution
act, but now suddenly growing the ability to do this resolution, is not so
clear.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-03-25 20:02:04 CET