On Tue, Mar 25, 2008 at 3:01 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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.
Would the existing API stay the same and just not expose these options
to the CLI?
> > 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.
This is provided that there is an API we can use to perform the
resolution. If the existing API will stay the same, and the new UI
you are proposing would just add a workspace crawl and the interactive
prompts, then I can live with it. I just do not want to see the API
get lost or tied to something else I do not want.
--
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-25 20:06:23 CET