[Svnmerge] Patch for non-reflected bidirectional merging support

[Raman Gupta]

Jim Fulton 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:
>>
>> [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
>>
>> [snip]
>>
> 
> Raman,
> 
> Did you see the alternate solution that I proposed?  I think it is
> simpler and cleaner than using dot files.
> 
> Jim


Hi Jim, yes I saw your email. However, I would take some convincing
regarding your assertion that using properties on the source branch is
simpler and cleaner.

I'm not sure I like having a merge operation modify a different branch
than the one being merged to, the main reason being that it will require
a second commit. This breaks the atomicity of the operation, as well as
possibly introduces some other complexities in terms of having yet
another revision that should essentially be ignored in terms of merging.
I'm also not sure how one would implement this in a clean way -- would
you ask the user to execute a script, after the merge has been
committed, that sets the property on the source branch? Yuck.

In addition, the dot-files give you a "free" way to track the revision
of the commit via the $Revision$ keyword.

That being said, I'm not totally pleased with the dot-file solution
either. But until someone can convince me of a better way, or Archie
integrates a different solution into svnmerge, that's what I'll be using.

Cheers,
Raman