Julian Foad <julian.f...@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
