RE: Input needed in solving issue 2897.
From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2007-10-27 20:30:07 CEST
>> Actual behaviour of last merge:
>In other words, because rP, rQ, and rR fall in between rX and rY, they
>> What to fix: We should fix this negation logic to negate the 'commit
>I didn't understand that sentence, sorry.
I meant in reflective merge scenario like this we should 'negate' the commit rev resulting from the follow-up commit to merge i.e rZ.
>My understanding is that in rZ, the svn:mergeinfo on /fb would be
>So my question is, immediately after rZ, does the svn:mergeinfo on /fb
Good question!. Mergeinfo on '/fb' is accurate only with respect to '/fb'. When someone wants to know what has been merged from '/trunk' to '/fb', he would get the correct answer say rX:Y. One should use this mergerange(rX:Y) to avoid repeated merge only if the merge is from '/trunk' not '/fb'. To avoid repeat merge from '/fb' one should use rZ.
Mergeinfo === 'merge source' + 'merge range' doing a math only on 'merge range'(ignoring the merge source) is like comparing apples and oranges.
>> In this particular case r12 merge would appear 3 times, which record
>Why does r12 appear 3 times? It was only merged once.
That is the way mergeinfo is stored in sqlite database. Whenever any node in a commit has mergeinfo it is stored as multiple merge range+path records. That is full text of 'svn:mergeinfo' is divided in to multiple merges and stored as individual record.
Let us say you have '/trunk:12' on '/fb', It puts one record ('/trunk', '/fb', 11, 12, 1)
Now next commit has '/trunk:12-13,18' on '/fb', It puts two records ('/trunk', '/fb', 11, 13, 1) ('/trunk', '/fb', 17, 18, 1) one for each merge range+path record.
>> Take the least revision(commit revision)?, No What if we reverted r12 from
>I don't understand what the phrase "reverted r12 from '/trunk' to
Sorry for being unclear, I meant 'reverse merge r12 on '/fb' from '/trunk' and commit in r51, So this would remove 'r12' from /fb's mergeinfo. So sqlite record won't have 'r12' anymore. Now again you merge r12 to '/fb' from '/trunk', Now sqlite will have r12.
>Could you show the precise structure of the proposed new table?
Current schema of 'mergeinfo_changed'
revision = subsequent commit to merge.
My proposed schema
*exactly same* as that of the only other table in our sqlite db 'mergeinfo'.
I think coulumn names are more obvious here.
The difference is in the way we are going to store the records in 'mergeinfo_changed'.
'mergeinfo_changed' table will only record the merge revision ranges pertaining to a given commit, that way we can precisely identify the 'commit_revs'(a.k.a reflective merge revision rZ in my origial mail) for a merge.
Thanks for your review.
This is an archived mail posted to the Subversion Dev mailing list.