'svn mergeinfo' and renamed branches.

So, I'm trying to work out the correct APIs and UI for 'svn mergeinfo' in
light of renamed branches. Consider the following scenario, if you will.

Imagine that in our own repository, all the work done on the 1.4.x branch
(and its forks) has never been merged to the trunk. Now, let's ask the
trunk what merges are available from /tags/1.4.5.

Already, we have two different interpretations of that request to deal with.
 Do we mean, "Which revisions committed solely to /tags/1.4.5 are eligible
for merge?" or "Which revisions along the entire history of /tags/1.4.5 are
eligible for merge?" The answers are quite different, of course.
/tags/1.4.5 has a relatively short history *at that location*:

   r26351-r28137: tags/1.4.5

But if you consider the whole lineage of that tag, well now you've got
history that extends back through trunk to revision 1.

   r26351-r28137: tags/1.4.5
   r26346-r26350: branches/1.4.5
   r25343-r26345: tags/1.4.4
   r25189-r25342: (null -- gap in history)
   r19524-r25188: branches/1.4.x
       r1-r19523: trunk

If we interpret the question in the first way (strict paths), 'svn
mergeinfo's job is pretty straightforward. And this is what the subcommand
does today. You'll be told that you can merge r26351-r28137. But is the
most useful thing? I mean, if you actually tried that merge, it would
conflict miserably because you're lacking all the changes between this range
and the branchpoint from trunk way back in r19254.

I kinda think 'svn mergeinfo' should interpret the question in the second
way. Here again, the calculations are easy enough:

   eligible = history(TGT) + mergeinfo(TGT) - history(SRC)

But now comes the UI question. If a user asks the question like so:

   "What revisions along the history of /tags/1.4.5 can I merge into trunk?"

Does he want this list (ignore the particular layout ... that's not my point):

   r26351-r28137: tags/1.4.5
   r26346-r26350: branches/1.4.5
   r25343-r26345: tags/1.4.4
   r19524-r25188: branches/1.4.x

or this:

   r19524-r28137: tags/1.4.5

The former is kinda nasty-looking, but reflects real locations. If he
wanted to, the user could do four merges of exactly those ranges, in
oldest-to-youngest order, and get what he expected.

The latter is concise, but doesn't indicate that /tags/1.4.5 has been
through any renames. That said, if the user wanted to, he could do a single
merge of this range and it would work. And as long as his peg revision was
young enough, he could even cherry-pick revisions from this range where the
history lived somewhere besides /tags/1.4.5.

So ... what to do? I don't have a strong opinion about this because I'm not
a big fan of the subcommand in the first place. (I just don't anticipate it
being used very much.) But there's an API behind this subcommand that needs
to do the right thing, and that's really where my concern is.

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