[Svnmerge] Re: Patch for non-reflected bidirectional merging support

[Blair Zajac]

Raman Gupta wrote:
> 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 attached a fix for the previous svnmerge-bidirectional.patch
> called "svnmerge-bidi-fixpaths.patch". This patch depends on, and should
> be applied after, the original "svnmerge-bidirectional.patch" patch.
> 
> The fix is for branches that are in a subdirectory, such as a "branches"
> directory as recommended by the svn book. Because of the necessary evil
> of dot-files to track merge-points, paths need to be munged (slashes are
> replaced with underscores) when reading/writing.

Instead of using the evil dot-files, how about storing the information 
in a revision property after the commit has gone in.  You can easily get 
the revision that was committed by looking at the svn 'svn info' output 
from the current working directory and use that for the revision 
property.  This will be cleaner than the dot-file approach.

Because Subversion out of the box does not allow per revision properties 
to be set, maybe before beinning a merge, svnmerge should try to set a 
dummy revision property and bail if it can't.  If it can set it, then it 
should delete the dummy revision property.

Regards,
Blair