Branko Čibej wrote:
> Here's a more complete proposal:
> 
> Introduce two new revision keywords:
> 
>     * ROOT (alternatively: CREATED)
>       [...]
> 
>     * MERGED
>       Only relevant in the context of a branch. Represents the latest
>       revision in which a merge was made to the branch. This revision
>       may depend on a discriminator parameter, which is a branch URL,
>       such that the result is the revision of the latest merge from
>       that branch.

This doesn't address the use case at hand. In order to see the net code changes 
on a branch, the left-hand side of the diff needs to be the *base* of the last 
merge, otherwise known as the "youngest common ancestor in the merge graph".

Let's review why that is so.

    1  2  3  4  5  6  7
  T ---------o--------o-
     \        \
      \        \
  B    o--o-----o--o----

The net code changes on this branch consist of the logical "combination" of the 
changes B3 and B6. (Assume no additional changes were made during branching or 
merging). However, an attempt to compute the net change by simply combining the 
individual changes (B3 "plus" B6) is likely to fail due to conflicts, because 
one was made in an older context and the other in a newer context (after the 
catch-up from trunk).

But we observe that the user has already combined changes B3 and B6 on the 
branch, including any conflict resolution that may have been necessary in 
relation to the catch-up from trunk, in two stages: first the catch-up merge 
resulting in state B@5 containing the logical combination of (B3 "plus" T4), 
and then the commit resulting in a state B@6 containing ((B3 "plus" T4) "plus" 
B6).

To see the net code changes on the branch, then, we can take the branch tip 
(state B@6) and subtract the last caught-up-to state of trunk (state T@4). 
Thus, diff(T@4,B@6). It is not diff(B@5,B@6) nor diff(B@anything,B@6).

The base of the last merge, T@4, is typically NOT on the same branch as the 
right-hand side of the diff (B@6). (But it would be if the last merge between 
branch and trunk had been in the other direction, aka a "reintegrate".)

The diff scenario we're looking at is also exactly the same as saying "show me 
one side of the 3-way diff that would be performed if I requested an automatic 
merge to trunk". So another valid way to approach the problem is to see about 
making a "show me the diff" variant of the merge command, rather than a "show 
me what would be merged" variant of the diff command.

- Julian

Reply via email to