Hi all, In Berlin, Julian raised the question how relevant the criss-cross merge case actually. I think I found a reasonable merge policy where those cases become the norm rather than an exception.
Most people seem to do what one might call "unqualified" catch-up merges, i.e. "merge everything up to HEAD" regardless of HEAD's state with respect to stability, features, side-effects etc. >From a process perspective, it seems much more prudent to do "qualified" merges like "merge from /trunk up to the last fully tested nightly build revision" and "merge from branch up to the point that I think is safe". In both directions, there will be changes between the catch-up source from A to B and the merge commit form B to A (and vice versa). Even if it was the same person doing the merge in both directions, this situation could not be avoided. Am I missing something or is that analysis correct? If it is, criss-cross issues should be about as common as conflicts themselves (depending on the relative size of to-be-merged to not-yet-to-be-merged history). -- Stefan^2. -- Certified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
