Hi there,
I saw that the discussion about merge tracking has been opened again,
which is a very good thing. In my opinion this is THE major reason why a
company would choose to use ClearCase instead of Subversion.
Most documentation I read so far lacked one important issue though. When
using parallel development in a company, a lot of branches are created,
resulting in a lot of merge actions in the end.
I usually work with the following sheme: there is a main branch for every
major release, and subbranches for every feature. All features are
developed separately and when fully tested and production ready, they are
integrated in the main branch. Now, before integration, the changes in
the main branch (e.g. integration of other features) need to be merged
into the feature branch, to test the integration locally. If all unit
tests work, the complete feature branch can be integrated and closed. I
like to call these actions rebase and integrate. A rebase is a merge from
the parent branch to the child branch, an integrate is the other way
around.
There are a few things to keep in mind when using Subversion with this
branching scheme.
1. Off course, it is wise to rebase regularly, to test the integration in
small steps, every time a feature is integrated in the main branch. It is
important that what has been merged in a previous rebase is not merged
again. But everybody is aware of this problem and it has been documented
a few times already.
2. When integrating, the changes on the child branch that result from the
rebase action (and thus are coming from the parent branch) do not need to
be integrated in the parent branch. Otherwise these changes will be
duplicated. Solving this means that somehow the merge tool needs to know
that changeset X is already in the parent branch. Solving this also means
solving 'transitive merges'. Given branches A, B and C, these are a few
examples of what I call 'transitive merges':
- if A:3 is merged into B:5 and A:3 is merged into C:7, then a merge from
B:6 into C:8 needs to ignore the changeset from the merge from A:3 into
B:5
- if A:3 is merged into B:5 and B:5 is merged into C:7, then a merge from
A:6 into C:8 needs to ignore the changeset from the merge from A:3 into
B:5
3. What if the rebase action results in on or more conflicts? The
conflicts will be solved in the child branch and committed. This
changeset will be registered as the merge. But when integrating, this
changeset is ignored because of the situation explained in 2. So there
will be a conflict again. This is off course inacceptable. When doing
the merge manually, you would copy the conflicting files from the child
branch to the parent branch, but this is of course only possible when you
are sure nothing changed on the parent branch since the last rebase. How
could we solve this? In my opinion, this is the most difficult part of
the merge tracking problem...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Apr 7 12:12:40 2005