[Svnmerge] [PATCH] Transitive merge fix

[Raman Gupta]

Giovanni Bajo wrote:
> On 8/10/2007 11:43 AM, Michael Willmott wrote:
> 
>>> This is going to cause two additional "svn propget" for each merge.
>>> Can't you use the VersionedProperty cache that was thought
>>> specifically for that? You already have merge_metadata() available,
>>> and I believe that block_metadata() is already computed at least for
>>> the reflected case.
>>>
>>> Which makes me think that maybe this feature should be gated on
>>> --bidirectional :)
>>>
>>> Notice that all the above might be wrong: I would appreciate if you
>>> watched at the output of svnmerge with -vv to prove me wrong (or
>>> right ;).
>>
>> I had a similar thought, and yes -vv does show additional (and in some
>> cases, duplicated) progets.  The only concern I have is that this fix
>> should be functional regardless of the state of --bidirectional, since
>> it prevents merge property conflicts.
> 
> I didn't follow the thread, but do these merge property conflicts can
> happen in a non-bidirectional scenario?

Yes, if one does uni-directional merges from A -> B -> C, the patch
prevents property conflicts in that case. So gating on bidirectional
does not make sense.

The attached patch uses the VersionedProperty cache.

Cheers,
Raman Gupta

-------------- next part --------------
A non-text attachment was scrubbed...
Name: svnmerge_transitive_fix_2.patch
Type: text/x-patch
Size: 1102 bytes
Desc: not available
URL: </pipermail/svnmerge/attachments/20070810/d427bfd5/attachment-0002.bin>