Folker Schamel wrote:
> Folker Schamel wrote:
>> Hi David!
>>
>>> On Dec 9, 2007 4:50 AM, Folker Schamel <schamel23@spinor.com> wrote:
>>>
>>>> To verify that I understand you correctly,
>>>> I try to rephrase it in my own words.
>>>> Can please you acknowledge that I am correct? Thanks!
>>>>
>>>> Subversion stores two kind of merge-information:
>>>>
>>>> a) "exact revisions/path that was merged for a given transaction".
>>>> b) "The [current] mergeinfo itself might contain additional
>>>> information that came from the merge itself.".
>>>>
>>>> Information a) is currently stored only in SDLite indices, right?
>>>> And a) is what I propose to store in the mergeinfo property, right?
>>>> Information b) is currently stored both in SQLite indices
>>>> *and* in the mergeinfo *property*, right?
>>>> And information b) can be reconstructed from a), right?
>>>> (Ignoring performance implications at the moment.)
>>>>
>>>> Then, my proposal is the following:
>>>> Why not just changing the meaning of the mergeinfo property
>>>> so that the mergeinfo property represents a) instead of b)?
>>>
>>> Hmm, so you are proposing that the svn:mergeinfo property for path P
>>> at revision R contains information specifically about what happens at
>>> revision R?
>>>
>>> If this really is a normal svn property, does that not imply that when
>>> revision R+1 is committed, no matter where on the tree that is, we
>>> also have to clear out all the svn:mergeinfo properties committed in
>>> revision R?
>>
>> 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.
* 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.
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.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 11 12:56:08 2007