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

[Raman Gupta]

(Blair, sorry for the duplicate, I didn't send to the list).

Blair Zajac wrote:
> Raman Gupta wrote:
> 
>> Raman Gupta wrote:
>>
>>> [snip]
>>>
>>> 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.

This resolves the problem of having a second commit because revprops are
unversioned, which is good. But, as was stated in a previous message,
anything that needs to happen after the merge commit requires the user
to take some manual action, so personally I still prefer the dot-files
approach. Plus finding the merge-points by checking the revprops for all
available revisions may be slow when there are a lot of revisions.

> 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.

Yeah, there is this limitation as well.

Cheers,
Raman