[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue #3036 -- svn_client_merge3() and merge tracking

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-11-30 19:20:38 CET

On Nov 30, 2007 1:09 PM, C. Michael Pilato <cmpilato@collab.net> wrote:
> Currently, svn_client_merge3() has some ... issues.
>
> Our merge tracking logic requires that the two "sides" of the merge source
> (the left- and right-side, if you will) have a direct ancestry relationship
> -- that one is a descendant of the other. (Sibling and cousin relationships
> don't count here.)
>
> svn_client_merge3() presumes to determine whether or not this is true like so:
>
> if (strcmp(URL1, URL2) == 0)
>
> Clearly, in the face of renames, this check is ... underpowered.
>
> There are two routes we can take here.
>
> 1. Teach svn_client_merge3() to do real relatedness checks, and upon
> finding that the sources provided are in fact related, setup the merge in
> the same way that svn_client_merge_peg3() does. This guarantees that merge
> tracking will work in those scenarios. But it has some annoying UI
> consequences (see comments in issue #3036), and makes for a confusing API
> (sometimes you get merge tracking, sometimes you don't, and explaining when
> you do and don't could be a challenge to the uneducated).
>
> 2. We could simply say that svn_client_merge3() does not support merge
> tracking at all, and to get merge tracking, you must use
> svn_client_merge_peg3(). The entire world is simplified this way.
>
> I mostly completed Option #1 yesterday (see patch attached to issue #3036),
> but the more I think about it, the less I like the UI and -- worse -- the
> API weirdnesses.
>
> I wanna solicit some opinions from others though before going the route of
> option #2. Mind you -- we could roll 1.5 with option #2 and do option #1
> later as an enhancement, if needed. We cannot, however, compatibly do the
> reverse.

I looked through JavaHL and then how we use it from Subclipse. I'd be
in favor of your option #2. As you said, we could come back to this
later and treat it as a bug if some use case surfaces.

The way we would tend to use this function in Subclipse we would
typically not expect any merge tracking features.

-- 
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
Received on Fri Nov 30 19:20:49 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.