Kamesh Jayachandran wrote:
>
>
> 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.
This would assume changing the meaning the svn:mergeinfo without
changing the merge algorithm using that information.
Yes, obviously this makes no sense.
There are two separate aspects:
a) How svn:mergeinfo (which is visible to the user) is defined.
b) Which information is stored internally (e.g. in SQLite indices),
and how the merge algorithm is implemented on base on that internal information.
For example, you can change the meaning of svn:mergeinfo
so that it does not include indirect mergeinfo anymore,
while internally the SQLite indices still include indirect mergeinfo,
so that any implementation using that SQLite indices
(instead of the svn:mergeinfo property) will work in the same way
as before.
> 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.
This works only in some special cases.
As you know, it does not work for example for
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=133164
Lets call such cases "ball-of-wool" cases.
But solving such ball-of-wool cases anyway *requires* a different approach,
which cannot just filter out revisions and/or use indirect merge info
as in (B). But if you have solved such ball-of-wool cases,
this indirectly will also solve your above case as special case.
In other words, as soon as you really want to handle ball-of-wool cases,
you will have to go away from just filtering out revisions
and from just using indirect merge info as (B) anyway,
which is a dead end.
You might decide to go into that "dead end" for the moment
for the 1.5 release as preliminary approach.
While this is not optimal from the technical perspective,
this might be a correct decisions from the perspective of
project management, just to ship something.
However, my point is that even in that case you should prepare
the meaning of your svn:mergeinfo property for the future
when you implement a better merge tracking handling ball-of-wool cases.
You can do this for example by using scheme (A) for svn:mergeinfo,
but - at the moment - still store the information of (B)
in some SQLite database.
Then, when implementing better merge info handling ball-of-wool cases,
that SQLite index won't be useful anymore, and you (likely) will need
different SQLite tables instead. But then this change
is an implementation detail without changing the meaning
of svn:mergeinfo.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 11 13:59:12 2007