David James <djames@collab.net> wrote:
> svnmerge.py works great for simple merges from trunk to branch.
Before discussing on the improvements, I would like to state that this is an
important design point in svnmerge: it must works well for simple cases.
Specifically, I expect it not to slow down in simple cases. This is
important for adoption: many people have simple needs, and before they start
using advanced features, they must be comfortable with how the tool behaves
in simple situation. Notice that --bidirectional is not the default (yet)
exactly for this reason.
> 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.
I don't understand where and how you are proposing to record this fact.
> 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.
This has been previously discussed on the svnmerge mailing list, but we
could not come up with a good solution. Specifically, svnmerge should
maintain any change/conflict to other properties in the directory. I would
like to know from the SVN developers if there is a way to detect *which*
property conflicted after a merge operation.
> 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.
How do you plan to calculate the value that the properties should assume so
to avoid conflicts? By reading and setting the property value at the
beginning of the merge interval? This might work. Still I'd rather a totally
disconnected solution, was it a way to know which properties did conflict
and thus resolve the conflict locally.
> 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.
Makes sense. I guess it can be done wherenver --bidirectional is active.
Many thanks for working on this. I am not expert in SVN development
procedures but I'd like to have a change to review these patches before they
get committed. Thanks!
--
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 2 12:03:29 2006