Auke Jilderda wrote: > Raman, > > have you pursued the implementation of supporting merge tracking across more > than two branches (optionally with even providing transitive merge tracking > information)?
Not yet, I've been busy getting my life in order after having moved back to Canada (my home and native land!) from the USA. What do you mean exactly by "across more than two branches"? Svnmerge.py already supports merge tracking with more than one source via the -S (source) switch -- just not transitively all that well. > To support merge tracking across more than two branches, I (as layman w.r.t. > the implementation) see four possible solutions: (a) prepend the path to the > key of the versioned property, (b) not propagate the versioned property, (c) > enable the init sub command to manually specify the name of the property > used, or (d) automatically merge the versioned property's value. Unless I am misunderstanding you, a) is already implemented (sort of, the path is prepended to the revision value, not the versioned property key) -- I think this was even part of Archie's original non-python version. > Option (d) seems the most elegant (and is what Daniel is doing on > Subversion's > merge-tracking branch) but would require that the Subversion command-line > client (as driven by svnmerge.py) to allow not merging a > directory's "svnmerge-integrated" property while merging other properties and > the contents of that directory. The command-line client doesn't currently > allow this; it might be doable at the Subversion C API level but Daniel tells > me that that would probably require quite a bit of work. Option (a) isn't > backwards compatible but would be the easiest to hack in. Option (c) would > require the user to name the property for every subsequent invocation of > svnmerge.py which would be a nuisance to put it mildly. Option (b) isn't > feasible; it has the same problem as described for option (d). Option d) should really be implemented in addition to the existing option a) and this could maybe somewhat support transitive merging (at least better than currently). I don't even think it would be that complicated to merge the property manually with a little bit of python-fu i.e. svnmerge.py would use the information on both branches to explicitly set the property after the merge, whilst ignoring any merges/conflicts produced by svn's merge algorithm by reverting the property merge. Though I'd still like to see a good use case for transitive merging -- I looked through the PDF you sent and I don't think the scenario it describes is a transitive merging use case -- in fact I think its pretty vanilla uni-directional merging from older branches to newer branches. Your summary was this: > Summarising, this is a strictly linear merging model of forward > propagating fixes. The transitive merge information is needed to be > able to verify that fixes have been propagated to all subsequent > releases. I would set up a script that executes svnmerge.py avail on each branch going forward in time with the prior older branch as the -S (source) argument, and aggregates the result into some sort of consolidated report of available revisions to be forward propagated. This would give you your verification in one command, without any transitive support in svnmerge.py. Since svnmerge.py also supports bidirectional merging, you could even support both forward and backwards propagating fixes simultaneously. However, transitive support might be useful in your scenario if you wanted to support the occasional "skipping" of a branch with later application of that skipped revision. In this case, it would be needed so that when the skipped revision was applied later, svnmerge.py would understand that it had already been merged into the next branch forward in time. > Would it be feasible and interesting to have a modified svnmerge.py that > implements option (a) for those who don't mind not being backwards compatible > but need to be able to merge across multiple branches? It seems the quickest > solution to bridge the time until 1.5 arrives even though it may not be > useful to some of the current users of svnmerge.py that need to maintain > their merge tracking information already built up. If you just want to merge across multiple branches without the transitive information, svnmerge.py does this already. If my patch is applied (the one that kicked off this round of discussion about transitive merging), then it will even do so without conflicts in the svnmerge-integrated property. Cheers, Raman _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
