subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Subversion Wiki] Update of "RepetitiveResolvingOfTheSameRename" by PhilipMartin
Date Thu, 17 Nov 2011 16:52:23 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "RepetitiveResolvingOfTheSameRename" page has been changed by PhilipMartin:
http://wiki.apache.org/subversion/RepetitiveResolvingOfTheSameRename

New page:
= The Problem =

The scenario is: a long-lived release branch getting bug fixes, and trunk undergoing development.
Bug fixes are merged between the trunk and branch; there are two (at least) ways this can
be handled. One is the approach used by the Subversion project: fix bugs on trunk and cherry-pick
merge those changes to the release branch.  Other organisations do it differently: they fix
bugs directly on the branch and do catch-up merges to ensure that the changes get onto trunk.

Both approaches suffer when the trunk development renames files and directories as the rename
often indicates major new development that is not suitable for the branch.  This means that
the merges raise tree conflicts that require user intervention to solve. The big problem is
that having solved and committed a solution, the next merge is likely to produce essentially
the same conflict requiring the user to go through the same steps to resolve it.

= The Aim =

We want the merge to automatically apply incoming changes to the moved items. These are not
uncommitted local moves, they are moves that have been committed to the repository. So the
solution is to identify moves in the repository history and then use those moves to adjust
the incoming merge differences so that they apply to the moved item.

The first stage, identifying moves in the repository, is the subject of ongoing work (Record
moves in the database, extracting them from the log history, etc.).  Some work has also been
done on getting update to understand local, uncommitted moves, and this can probably be extended.

It is not clear how well automatic move identification will work in practice. Even if it works
well there will always be some moves that cannot be identified automatically, if only because
the user simply made the move using add/rm without any sort of copy. Another scenario is splitting
a file in two and later discarding one half.

The idea here is to allow the user to resolve conflicts by telling Subversion "A moved to
B" and storing that information. This could happen before the merge, or during conflict resolution,
or at some other time.  The information gets stored in a property and committed so that it
is available for subsequent merges.  In this way the user only has to resolve the conflict
once and repeat merges don't conflict.

This doesn't preclude automatic move identification. Initially we simply ask the user to resolve
all moves, but as automatic move identification starts to work it can bypass asking (or perhaps
suggest the answer).

= The Design =

== What information needs to be stored? ==

"A moved to B" obviously. "at rN"?

Do we need to store a revision range?

== Where is it stored? ==

In an svn:property of some sort. It may need special handling to merge changes to the property
along the lines of svn:mergeinfo.

Do we store the property at the working copy root?  In the parent of of the moved item?

Given A/B/C/D on one branch and suppose there have been three renames on the other branch
at various times:

D->Z

C->Y

B->X

giving A/X/Y/Z. We could store all three moves in the root or we could store the B->X in
A, C->Y in B and D->Z in C.  Storing it in parent would mean that it automatically adjusted
as the parent was moved.  If this good or bad?

What would root storage look like?  There are obviously ordering issues.

A/B/C/D->A/B/C/Z

A/B/C->A/B/Y

A/B->A/X

== How is the information obtained? ==

During interactive merge resolution?

"svn resolve --moved-to B A"

== When is it stored? ==

Like any property change it can be explicily committed, but generally it would be stored as
part of the commit of the merge.

== Multiple branches? ==

Suppose two branches are merging to trunk, with one branch older than the other.  The trunk
may have made renames between the two branches.  So A->B may apply to branch one while
X->B may apply to branch two.

Does the conflict resolution stored on the source branch affect how it gets merged to the
destination?

Is there transitive behaviour?

Mime
View raw message