Issue #3036 -- svn_client_merge3() and merge tracking

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.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand