[Svnmerge] [PATCH] Bidirectional merging patch for svnmerge.py

[Alan Barrett]

On Sun, 19 Feb 2006, Raman Gupta wrote:
> Attached is a bidirectional merging patch for the latest version of
> svnmerge.py (rev 238).  It removes reflected revisions (i.e. changes on
> the branch that were originally merged from the target, and therefore
> should generally not be merged back into the target) from the
> available/merge list. Reflected revisions can cause spurious conflicts
> if any changes were made to the merged code on the branch.

I suggest storing metadata to help this process in a new property.  The
existing svnmerge-integrated property is stored in the target branch,
and contains a list of revisions that have been merged (or that do not
need to be merged) from the source branch to the target branch.  The
proposed new property (say svnmerge-merges) would also be stored in the
target branch, and would contain a list of revisions in which merges
were previously performed from the source branch to the target branch.

When we do a merge, we can't know the revision number that will be
associated with the merge in progress, but we can calculate the revision
numbers associated with all previous merges, and we can store that in a
property.  The previous value of the property can be used to reduce the
range of revisions that have to be checked while calculating the new
value of the property.

For example, if the repository is currently at revision 123, and
previous merges were performed at revisions 45, 87, and 102,
then the merge that was performed at revision 102 might have set
svnmerge-merges="/sourcebranch:45,87".  (It would not have known
its own revision number, so it would not have been able to set
svnmerge-merges="/sourcebranch:45,87,102".)  We now need to search
from revision 88 to 123 looking for merges.  This is much better than
searching the entire repository.  We find revision 102, and add it to
the value of svnmerge-merges.  We also modify the svnmerge-integrated
property as before.

--apb (Alan Barrett)