Kamesh Jayachandran wrote:
>
>
> Folker Schamel wrote:
>>> No, what I suggest is simply that svn:mergeinfo contains all path@rev
>>> which have been merged into that path directly (but not indirectly).
>>>
>>> For example, if you have
>>> trunk@30 has svn:mergeinfo = branch1@1-20
>>> branch1@25 has svn:mergeinfo = branch2@1-7
>>> branch1@30 has svn:mergeinfo = branch2@1-10
>>> and then you merge branch1@26-30 into trunk as r31,
>>> then, according to my proposal, you get simply
>>> trunk@31 has svn:mergeinfo = branch1@1-20,26-30
>>> but NOT (as currently, if I understand it correctly)
>>> trunk@31 has svn:mergeinfo = branch1@1-20,26-30;branch2@8-10
>>> and also NOT (as your interpretation)
>>> trunk@31 has svn:mergeinfo = branch1@26-30
>>
>> (A) trunk@31 has svn:mergeinfo = branch1@1-20,26-30
>> (B) trunk@31 has svn:mergeinfo = branch1@1-20,26-30;branch2@8-10
>> (C) trunk@31 has svn:mergeinfo = branch1@26-30
>>
>> Scheme (A) and (C) are just different representations of the same
>> information, so both would work.
>> I personally just would prefer (A) to (C) for simplicity
>> and being "more natural".
>> While (B) lacks information as discussed.
>
> (A) will expose the following problem.
In the current implementation, but of course that has to be updated to
cope with any change in the mergeinfo property!
> * Do a change /branches/X - r50
> * Merge r50 from /branches/X to /branches/Y, it sets a mergeinfo on
> /branches/Y as '/branches/X:50'.
> * Merge -r20:51 /branches/Y to /trunk
> As of current implementation it would set the mergeinfo on /trunk to
> be like (B) i.e
> /branches/X:50
> /branches/Y:20-51
>
> If we change it to (A) as suggested by you, It would set it as
> /branches/Y:20-51
>
> Now if someone tries to merge r50 from /branches/X to /trunk it would be
> a repeat merge and can give raise to a conflict.
Not if the implementation has access to indirect merge info.
> What I think is we should enhance 'repeat_merge_filtering' logic to
> check *all* the merge sources from 'svn:mergeinfo' and correspondingly
> filter the revisions from the requested merge.
A crucial thing for some of the merge tracking algorithms to work is
that the implementation must be able to distinguish between:
a) direct merge info
b) indirect merge info
Since b) is reconstructible from a), it makes sense for the mergeinfo
property only to contain a) (proposals A and C). Proposal B, the current
state of affairs as I understand it, is a 'dead end' since it doesn't
distinguish between A and C. An alternative, that might make you both
happy since it might avoid the need for SQLite for 1.5, is proposal D,
something like:
(D) trunk@31 has svn:mergeinfo = branch1@1-20D,26-30D;branch2@8-10I
Where D and I are for direct and indirect, respectively.
It's likely that I information in the mergeinfo property will be ignored
in some future version of SVN, once the advanced use cases for for
merging are implemented, since they may need a database to optimize
various lookups, beyond what is in the mergeinfo property.
Tom (a lurker who will be using feature branches and wants them to work!)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 11 16:03:59 2007