> Thanks.
>
> I'm looking at the table definitions in mergeinfo-sqlite-index.c and
> trying map the above to what I see there. Let's take your first commit:
>
> > Let us say you have '/trunk:12' on '/fb', It puts one record
> > ('/trunk', '/fb', 11, 12, 1)
>
> That produces a row like this in mergeinfo_changed:
>
> revision == 50 /* revision in which r12 was merged from trunk to fb */
> path == '/fb'
>
> And a row like this in 'mergeinfo':
>
> revision == 50
> mergedfrom == '/trunk'
> mergedto == '/fb'
> mergedrevstart == 11
> mergedrevend == 12
> inheritable == 1
>
> Is that right so far?
>
Yes.
> Now when we go to the next commit...
>
> > 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.
>
> That produces a row like this in mergeinfo_changed:
>
> revision == 56 /* revision in which r18 was merged from trunk to fb */
> path == '/fb'
>
> And a row like this in 'mergeinfo':
>
> revision == 56
> mergedfrom == '/trunk'
> mergedto == '/fb'
> mergedrevstart == 17
> mergedrevend == 18
> inheritable == 1
>
> Now, my question is, do we also put in a new row for the r12
> mergeinfo? That is, do we add a new row saying
>
> (56, '/trunk', '/fb', 11, 12, 1)
>
> even though we already have a row from before that says
>
> (50, '/trunk', '/fb', 11, 12, 1)
>
> ?
>
>
Yes. we put again (56, '/trunk', '/fb', 11, 12, 1). Without this
redundancy it would be difficult to combine records in this table, as
records may be for totally different nodes in the history just having
the same name.
> Okay, moving on to the third commit:
>
> > 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.
>
> (Let's say that happens in r60.) A similar questions applies: when we
> add the record...
>
> (60, '/trunk', '/fb', 11, 13, 1)
>
> ...do we also *remove* any records like this:
>
> (..., '/trunk', '/fb', 11, 12, 1)
>
> since they are sort of subsets of the new record? Or do we let the
> old records remain? I realize that doing such removals might be
> computationally intensive, so I'm really asking two questions: do we
> remove such subset records, and if not, do we at least *wish* we could
> remove them?
>
No we won't remove any old records. Each set of records for a revision
uniquely identify a node's mergeinfo.
Logic is simple,
Upon every commit 'fs_(fs|base) identifies the 'paths_changed' with
'svn:mergeinfo' modified and tokenizes this fulltext mergeinfo and puts
them as records in mergeinfo.
What I am proposing is let us use 'mergeinfo' for full-text
mergeinfo(which we already do), 'mergeinfo_changed' as 'delta mergeinfo'
may be we can rename those tables to reflect this intent.
>
>
> Thanks, that helps clarify things for me.
>
> Let me test my understanding. The way to find out (using the current
> code) what exactly got merged in, say, r60 is to look in
> mergeinfo_changed and select on rev==60. Suppose we get these
> results:
>
> (60, '/some/path')
> (60, '/some/other/path')
> (60, '/yet/another/path')
>
> Okay, let's start with '/some/path'. We search backwards in that
> table for the previous change to '/some/path'. Say we find this:
>
> (56, '/some/path')
>
> Great. Now go to the mergeinfo table, and select every row where
>
> (rev == 60) && (mergedto == '/some/path')
>
> Then get all the mergeinfo for
>
> (rev == 56) && (mergedto == '/some/path')
>
> Compute the "difference" between the two mergeinfo sets, and that is
> what was merged to '/some/path' in r60. Repeat for '/some/other/path'
> and '/yet/another/path', of course.
>
> Is my understanding even close? This is all guessing, based on the
> table schemas and on thinking about the problem. I might be
> completely wrong, please don't hesitate to correct me :-). If I am
> wrong, then I don't understand the way those two tables are used
> together in today's code.
>
>
Your understanding is exactly correct. For the usecase of 2897 we just
need the opposite 'which commit_rev has this merge'.
Thanks for your meticulous review.
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 Fri Nov 2 17:01:49 2007