[Svnmerge] Patch for non-reflected bidirectional merging support

[Jim Fulton]

Raman Gupta wrote:
> Hi all,
> 
> I have attached two patches. The first is incidental and fixes a couple
> of bugs svnmerge that I found while testing. These bugs are:
> 
> 1) The get_all_integrated_revs method was not being passed the
> BRANCH_DIR, causing the integrated revisions for some merge target
> branches to be lost when tracking integrated revisions for multiple targets.
> 
> 2) The merge algorithm did not revert changes to the svn-integrated
> property for each range being merged, which caused a conflict if more
> than one range being merged contained a change to the svn-integrated
> property.
> 
> The second, and far more interesting, patch adds merge-point tracking.
> This improves the bi-directional merging support of svnmerge by
> preventing reflected changes from being merged. See here for initial
> discussion fo the problem, and a description of the solution implemented
> in the patch:
> 
> http://www.orcaware.com/pipermail/svnmerge/2005-August/000000.html
> 
> I have not done extensive testing on this patch, nor have I yet used it
> in a real-life production situation. So please review it carefully and
> use caution if you decide to use this on production data.
> 
> One caveat is that when bi-directional merging is happening between
> multiple branches e.g. trunk to/from branch1, and trunk to/from
> branch2,the merge-point dot-files can be propagated between branches,
> even if merge tracking has not been initialized between them i.e. you
> might end up with a branch1 merge-point tracking file on branch2. This
> doesn't bother me enough to fix, but if it does bother somebody, fixing
> it should be relatively simple.
> 
> Archie, I hope that you can review the patches and consider them for
> inclusion in svnmerge. You may want to optimize the shell scripting, and
> add some niceties, such as for example turning off (or on) the
> merge-point tracking via argument, and so forth.


Raman,

Did you see the alternate solution that I proposed?  I think it is
simpler and cleaner than using dot files.

Jim


-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org