Please stop patching M2 directly and patch M2.1 then merge onto M2. Here is why.
svnmerge cannot do graph merging. Therefore, we must do unidirectional merging only, or we can do bidirectional, but we need to be very careful about it. The reason is because the merge tracking properties are held as svn properties against the root directory of the merge point. So a merge from one branch A to B, cannot then be merged from B to C, as the merge tracking properties on B will conflict with those on C. You can do bi-directional merging between A and B, as the following example illustrates. Turn on tracking from A -> B and from B -> A. Rev 1 on A. Merge 1 on A to 2 on B. Block 2 on B to A (it originated on A, so does not need to be back merged). Make change 3 on B. Merge B back to A, only 3 gets merged. We can no longer merge from M2 to trunk, because patches from M2.1 are being merged to M2. So these cannot be graph merged onto trunk. We need a single source for patches, and this has to be M2.1. We need to merge everything up to the point before patches from M2.1 -> M2 are happening. Then stop merging from M2 to trunk. Turn on merge tracking from M2.1 -> trunk instead. I think, in general that merging from M2/2.1 -> trunk is important, because there are a lot of bug-fixes going on there. This is the gold-dust of programming, and we should be careful not to throw them away. I want to get my test code merged down from M2.1 onto trunk, as well as all of the current bug fixes going on. However, this is becoming increasingly unmanageable (it may already be beyond the point where it is manageable). So I have a longer term questions about the feasibility of our current approach. Why are we still on a branch? What is the life cycle for M2.1? will the M3 release eventually be cut from it? Can we realistically continue in this way? Would it not make sense to call this branch a dead end ASAP and move everyone back onto trunk? Alternatively, I could just give up trying to merge. But if there is no M2/2.1 -> trunk merging, then we really have two separate projects. Rupert
