svnmerge.py works great for simple merges from trunk to branch.
However, if you need to do complex bidirectional merges, you'll run
into issues. I've outlined three issues with svnmerge.py below, along
with some proposed solutions.
Problem #1: Transitive merges
-----------------------------
Currently, svnmerge.py does not handle transitive merges correctly. For
example, if a change is merged from trunk to branch A, and then to
branch B, the indirect relationship between branch B and trunk is not
recorded. As a result, if you then attempt to merge from branch B to
trunk, the original change from trunk will be merged a second time.
Proposed Solution:
When a change is merged, always copy its tracking information
along with it. So, when we merge from branch A to branch B, we
should record the fact that this merge contains changes from
trunk.
Problem #2: Spurious property conflicts
---------------------------------------
Currently, svnmerge.py reports spurious property conflicts on when you
merge between trunk and branch. These spurious conflicts occur when the
merged revision modifies the 'svnmerge-integrated' or the 'svnmerge-
blocked' property.
An example, from testBidirectionalMerges in our test suite:
# There will be directory property conflict on 'test-branch'
# due to the attempted merge from trunk of the addition of the
# svnmerge-integrated property, which already exists in the
# branch since 'svnmerge.py init' was run in it. So just
# resolve it, as it currently has the correct value.
Proposed Solution:
1. Before running each 'svn merge' command, setup the
svnmerge-integrated and svnmerge-blocked properties so that
the revision can merge cleanly.
2. After our merges complete, set svnmerge-integrated and
svnmerge-blocked appropriately.
Problem #3: Partially reflected merges
--------------------------------------
Example:
1) Make change on trunk
2) Merge from trunk to branch A
3) Make another change on trunk
4) Merge from trunk to branch B
5) Merge from branch B to branch A
Problem:
A merge of (4) from branch B to branch A causes conflicts, because
branch A already contains (1).
Solution:
In (6), instead of merging (4) from branch B to branch A, merge
(3) from trunk to branch A. We can calculate this by counting which
trunk changes exist in branch A but do not yet exist in branch B.
This trick need only be used when a merge is partially reflected.
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 2 09:56:10 2006