Stefan Fuhrmann wrote: > Julian Foad wrote: [...] >> At this point, I think the issue boils down to: >> >> * Yes, the criss-cross situation can be produced in plausible real life >> usage. >> >> * The current handling is sub-optimal, though not worse than we've had >> before. >> >> * We might want to look at more sophisticated ways to handle it. >> >> * We might want to look at ways to help users avoid the situation. > > The last part has been my concern but I think the following > policy should work and be feasible in most environments that > care about qualified merges. Assume we want to update "branch" > from "trunk" and vice versa. > > * before merging, bring HEAD of branch into a working state > > * catch-up merge from latest known-good rev of "trunk" to "branch" > in revision R1 > > * consolidate "branch" and bring it to a known-good state > > * merge from latest known-good revision R2 "branch" to "trunk"
So, like this (for those able to read the mail in a fixed-width type face): trunk --o-.....-o-.........-o-... \ \ / \ \ / o-.....-o-...-o-...... branch R1 R2 > Ensuring R2 > R1 prevents the criss-cross. Strictly, R2 >= R1. > R2 does not need > to be HEAD, i.e. the user may run expensive validation on > "branch" to qualify it as known-good. Yes. > So, merging from "branch" to "trunk" will become harder and > there will be fewer such merges. Catching up with "trunk" is > not affected. 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) ... trunk R0 --o-........-o-........ \ \ ___... \ \/ \ /\ \ / \ o-...-o-..-o-... branch R2 R1 ... and also complain if the user starts a merge while a merge in the opposite direction has been started but not yet committed. trunk R0 --o-........-o-........ \ \ ___... \ \/ \ /\___... \ / o-...-o-........ branch R2 (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.) - Julian