Julian Foad <julian.foad_at_wandisco.com> writes:
> 2 3 4 5
> BranchA--o-----------------------------------------
> \
> \ "A:2"
> BranchB-----o---o----------------------------------
> \
> \ "A:2 B:3-4"
> BranchC------------o-------------------------------
>
> Philip and I were prompted by a customer to consider why Subversion copies
> mergeinfo from branch to branch, in transitive merges (branch A -> branch B
> -> branch C). Why do we need mergeinfo on branch C that refers directly to
> A? If, as I believe to be the case, Subversion only supports merge
> tracking if the branching graph is tree-shaped, then the only merges
> allowed to or from branch C are those to or from branch B (and those to or
> any further branches to the "right" of it: D1, D2). And thus the mergeinfo
> on C that refers to A is not useful. It's redundant anyway, in the sense
> that if we hadn't stored it explicitly then we could crawl the branching
> graph to find it, but that's not my concern; rather, I wonder if it is ever
> actually providing any benefit.
Further, operations such as "log -g" and "blame -g" that do require the
transitive mergeinfo generally cope if the redundant information is not
stored, because the server follows the merges back and retreives the
information from the other branches. Not storing the redundant
information may even reduce the server load and make these operation
more efficient. I suppose it would fall down if a record-only merge is
made to correct the mergeinfo on B before the merge from B to C. In
that case we rely on the corrected transitive mergeinfo being present on
C, and if we simply follow the mergeinfo to B we won't always discover
the mergeinfo change on a different revision.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2011-11-10 18:38:22 CET