RE: Input needed in solving issue 2897.

Hi Karl,

>> Actual behaviour of last merge:
>> Currently this behaviour is broken (issue 2897 just deals with it.),
>> it merges only rS and rT alone (that is it negates 'rX:Y' from rX:HEAD
>> and gives rS and rT, remember rX<rP, rQ, rR <rY)

>In other words, because rP, rQ, and rR fall in between rX and rY, they
>are omitted as undesirable purely on numeric grounds, even though they
>were on /fb while the other stuff in rX:Y was on trunk?

Yes.

>> What to fix: We should fix this negation logic to negate the 'commit
>> rev rZ' rather than what got merged(rX:Y).

>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
>changed to note all the /trunk revisions in the range rX:Y. Call that
>set {R}. When we merge /fb back to /trunk, nothing from {R} should be
>included. But rP, rQ, and rR are not in {R}, since they were
>committed directly on /fb, and trunk has never seen them.

>So my question is, immediately after rZ, does the svn:mergeinfo on /fb
>accurately reflect exactly what has been merged in from elsewhere? If
>not, is there a good reason why not?

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
>> to consider to decide when the merge has occured?

>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,18' on '/fb', It puts two records ('/trunk', '/fb', 11, 12, 1) ('/trunk', '/fb', 17, 18, 1) one for each merge range+path record.

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
>> '/trunk' to '/fb' on r51, Remember we don't record reverse merges and
>> merge back the same on r52.

>I don't understand what the phrase "reverted r12 from '/trunk' to
>'/fb' on r51" means. Do you mean remove r12 from /trunk and put it
>into /fb, all in one commit? (But it is already in /fb...)

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'
-------------------------------------
CREATE TABLE mergeinfo_changed (revision INTEGER NOT NULL, path TEXT NOT NULL);

revision = subsequent commit to merge.
path = merge target.

My proposed schema
------------------------------
CREATE TABLE mergeinfo_changed (revision INTEGER NOT NULL, mergedfrom TEXT NOT NULL, mergedto TEXT NOT NULL, mergedrevstart INTEGER NOT NULL, mergedrevend INTEGER NOT NULL, inheritable INTEGER NOT NULL);

*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' table as ususal will have the records for all the merges on a node on every single merge+commit irrespective of what exactly been merged in this commit.(Remember 3 records for r12 in my original mail).

'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.

With regards
Kamesh Jayachandran
Received on Sat Oct 27 20:32:13 2007