You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2008/03/24 20:17:24 UTC
'svn resolved' (past tense) actually performs resolution now?
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?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 'svn resolved' (past tense) actually performs resolution now?
Posted by Mark Phippard <ma...@gmail.com>.
On Tue, Mar 25, 2008 at 3:01 PM, C. Michael Pilato <cm...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn resolved' (past tense) actually performs resolution now?
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 'svn resolved' (past tense) actually performs resolution now?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"C. Michael Pilato" <cm...@collab.net> writes:
> +1. (But don't think ill of me if I bang out and push for 1.5 inclusion of
> "the full functionality".)
You're kidding, right? That would be great :)
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn resolved' (past tense) actually performs resolution now?
Posted by "C. Michael Pilato" <cm...@collab.net>.
Eric Gillespie wrote:
> That confusion worries me. Hm, how about:
>
> - move the --accept option to a new 'resolve' command (which in
> some post-1.5 release will also offer the full functionality)
> - drop --accept from 'resolved'
> - document 'resolved' as a deprecated alias for 'resolve --accept=merged'
+1. (But don't think ill of me if I bang out and push for 1.5 inclusion of
"the full functionality".)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: 'svn resolved' (past tense) actually performs resolution now?
Posted by Eric Gillespie <ep...@pretzelnet.org>.
"Mark Phippard" <ma...@gmail.com> writes:
> On Mon, Mar 24, 2008 at 4:17 PM, C. Michael Pilato <cm...@collab.net> wrot
> e:
> > 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 willingnes
> s
> > 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
Well, I think Mark and David raised an important point:
> 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?
That confusion worries me. Hm, how about:
- move the --accept option to a new 'resolve' command (which in
some post-1.5 release will also offer the full functionality)
- drop --accept from 'resolved'
- document 'resolved' as a deprecated alias for 'resolve --accept=merged'
> 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.
It sounds like you're looking for --accept=merged?
> 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.
How we implement the command-line UI does not impact how you or
Tortoise implement your own UI. The functionality is available
to you no matter which subcommand we use.
--
Eric Gillespie <*> epg@pretzelnet.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: 'svn resolved' (past tense) actually performs resolution now?
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, Mar 24, 2008 at 4:17 PM, C. Michael Pilato <cm...@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org