Conflict Resolution UI

[Augie Fackler <du...@gmail.com>]

Hey all,

The below is from a discussion with a fellow Adium developer (Peter  
Hosey, cc'ed on this message) who is using svn 1.5's interactive  
merging. He thinks (somewhat rightly, I suppose, given that svn's  
choices were intuitive to me from my p4 experience) that we should  
consider renaming the options in the merge resolution menu.

His proposed solution is below. I'm not entirely sure it's perfect,  
but I think it might be less unclear than what we have now.

Peace,
Augie

On Aug 30, 2007, at 4:08 PM, Peter Hosey wrote:

> On Aug 30, 2007, at 12:57:28, Augie Fackler wrote:
>> 'm' is "my" version of the file - whatever is in the working copy.
>> 't' is "their" version of the file - whatever is coming in from  
>> the server.
>> Does that make sense?
>
> Only after a lot of thought. As I said, they're both in the WC and  
> they're both in the repo.
> ---
> The command is:
>
> 	svn merge -r17251:20830 trunk branches/summer_of_code_2006/ 
> chirag_shah
>
> Being that I'm seemingly merging from one WC directory (./trunk) to  
> another (./branches/...), I can't immediately find what server  
> you're talking about.
> ---
> svn merge brings in the before and after versions from the server,  
> so that must be it.
> ---
> Presumably you're talking about the after version of the file, not  
> the before. I know an easy way to verify this—I'll look at the  
> diff! (I did this earlier, too.)
>
> Select: (p)ostpone, (d)iff, (e)dit, (h)elp : d
> --- /tmp/tmp    Thu Aug 30 13:02:31 2007
> +++ bar/.svn/tmp/tempfile.4.tmp Thu Aug 30 13:02:31 2007
>
> Uh... right.
> ---
>
> So let me see if I have this straight:
>
> “my” version is whatever is in the *destination*. In this case,  
> it's branches/..., a WC directory, but svn merge does allow it to  
> be an object in the repo (URL to URL atomic merge).
>
> “their” version is whatever is in the *source*. In this case, it's  
> trunk, a WC directory.
>
> If this is correct, then this is how I recommend naming them and  
> stating their purposes:
>
> (f)rom     - clobber the destination object with the source object
> (t)o       - ignore the source object; use the destination object  
> unmodified
>
> f is what used to be t, and t is what used to be m.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Conflict Resolution UI

[Malcolm Rowe <ma...@farside.org.uk>]

On Thu, Aug 30, 2007 at 05:20:39PM -0400, Mark Phippard wrote:
> 2)  You cannot do a URL <-> URL merge directly in the repository.
> 
> I guess our terminology is similar to Perforce, but I also think that
> same terminology is used by most tools that do similar functions.
> 

Perforce, I believe, also uses the mine (Perforce: "yours")/theirs
terminology for URL->URL merges, which is more than slightly confusing.
We should probably do something better, if (when?) we support such
merges.

I wonder whether we could make the help more explicit?  The 'merge'
command takes arguments SOURCE1, SOURCE2, and DESTINATION (WCPATH).
Could (should?) ww refererence those arguments somehow in the
interactive conflict help?

Regards,
Malcolm

Re: Conflict Resolution UI

[Peter Hosey <bo...@gmail.com>]

On Aug 30, 2007, at 14:20:39, Mark Phippard wrote:
> All Subversion does in this case, is use that path to figure out  
> the repository URL. … In other words, a merge is always coming  
> from the repository.

Right; I mentioned that in my email. (Where else would previous
revisions come from? Obviously, they must come from the server.) Part of
that is that I know the *destination* is the local WC, so with two WC
paths in the command line, it comes off as a plain WC-to-WC merge to me.
I just didn't think about that aspect deeply enough at the time.

That part is not your fault, though. I don't think there's anything you
can do about a user (me) failing to think deeper than the convenience
feature of specifying relative paths in the WC, and that's *part* of
what caused a problem for me. Consider it a UI victory that you hid the
implementation detail so well. ☺

The main ambiguity for me was that it just says “the repository”,
without any indication of *where* in the repository. It wasn't obvious
whether it was talking about the source directory in the repository,
or the destination directory in the repository. I only figured it out
while writing my previous email (the one that Augie forwarded to you).

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Conflict Resolution UI

[Mark Phippard <ma...@gmail.com>]

On 8/30/07, Augie Fackler <du...@gmail.com> wrote:

> The below is from a discussion with a fellow Adium developer (Peter
> Hosey, cc'ed on this message) who is using svn 1.5's interactive
> merging. He thinks (somewhat rightly, I suppose, given that svn's
> choices were intuitive to me from my p4 experience) that we should
> consider renaming the options in the merge resolution menu.
>
> His proposed solution is below. I'm not entirely sure it's perfect,
> but I think it might be less unclear than what we have now.

FWIW, I do not think that is any clearer.

In the transcript below there are at least two misconceptions:

1)  He is using a WC path as his merge source.  All Subversion does in
this case, is use that path to figure out the repository URL.
Disconnect from the network and try for yourself.  In other words, a
merge is always coming from the repository.

2)  You cannot do a URL <-> URL merge directly in the repository.

I guess our terminology is similar to Perforce, but I also think that
same terminology is used by most tools that do similar functions.

-- 
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