Re: 'svn revert' vs. 'svn resolve'

On Tue, Jun 10, 2003 at 07:29:49PM +0100, Julian Foad wrote:
> Someone wrote:
> >
> >'settle' is terse, it is semantically very close to 'resolve' and, finally,
> >it isn't easily confused with other svn subcommands.

I don't like it much. 'settle' is very weird. It's too "cutesy" for the
operation. Yes, there was a conflict, but it isn't something you _settle_.
Settling has connotations associated with humans, not objects.

>...
> (b) you are not telling Subversion to settle the conflict, you are
> informing Subversion that you have settled the conflict.

Good point about the tense.

>...
> And isn't "resolve" a common term in the world of version control (users,
> not just implementors)?

Yes, it is, which is why it was great. But we also have to fix something.

Mike's veto not withstanding, 'revert' has been used for a long time in the
document space (e.g. MS Word) to mean "toss my changes, and give me what was
last saved." It works perfect, so I'd agree that the command name shouldn't
change. Personally, I would suggest leaving the .mine file if you revert a
conflicted file. It's safe, easy to explain, and it isn't hard to clean
those up.

The other alternative is magic flags to 'resolve', but as Ben points out,
you'd just become habituated to those (or enable some flag in your config),
and we're back to square one.

Thus, as only of the leading alternatives to leaving the .mine file, we have
renaming the 'resolve' command.

Some of Julian's ideas:

> Thus:
>
> $ svn conflicts-are-resolved-in foo.c
> $ svn mark-resolved foo.c
> $ svn have-resolved foo.c
> $ svn resolved foo.c
> $ svn settled foo.c

But 'resolved' has the same issue as 'resolve'.

Looking in a thesaurus, we also have:

 $ svn assayed foo.c
 $ svn completed foo.c
 $ svn concluded foo.c
 $ svn considered foo.c
 $ svn decided foo.c
 $ svn inspected foo.c
 $ svn integrated foo.c
 $ svn investigated foo.c
 $ svn prepared foo.c
 $ svn scrutinized foo.c

There are others, I'm sure, but those are some that kind of popped out that
might work for this context.

My favorites are inspected, completed, investigated, and concluded, in that
order. None of these have any destructive conflicts (no pun intended :-)
with other commands right now. The in* could conflict with 'info', but that
isn't a problem. The co* could conflict with checkout, but not a problem
either.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org