Re: Incidence of criss-cross merges
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 17 Jul 2012 15:32:58 +0100 (BST)
Stefan Fuhrmann wrote:
So, like this (for those able to read the mail in a fixed-width type face):
> Ensuring R2 > R1 prevents the criss-cross.
Strictly, R2 >= R1.
> R2 does not need
> So, merging from "branch" to "trunk" will become harder and
No, the problem is symmetrical: catching up with "trunk" is affected in just the same way as merging back the other way.
There are two ways to enforce such a policy.
* Using only Subversion mechanisms, a pre-commit hook can reject a commit that would create a criss-crossing merge if committed, as defined above.
* If we have a working environment that knows when any merge is being performed between these two branches, the tooling could complain if a user starts a merge where the source revision R2 is less than R1 (where R1 is the committed revision of the last merge in the opposite direction) ...
... and also complain if the user starts a merge while a merge in the opposite direction has been
(I label the source revision of the first merge as "R0" and show it at the same time-position as R2, but in fact it doesn't matter whether R0 is before, at the same revision as or after R2.)
This is an archived mail posted to the Subversion Dev mailing list.