You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rupert Smith <ru...@googlemail.com> on 2007/09/25 11:57:02 UTC

SVN Merge Issues

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