[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: mergeinfo_changed

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-11-27 10:32:06 CET

On Nov 26, 2007 10:09 PM, Kamesh Jayachandran <kamesh@collab.net> wrote:
> David Glasser wrote:
> > From reading index_path_mergeinfo (the only function with any
> > INSERTs), it sure looks like mergeinfo_changed contains no information
> > not already in mergeinfo. It looks like (rev, path) is in
> > mergeinfo_changed if and only if there exists (from, start, end,
> > inheritable) such that (rev, from, path, start, end, inheritable) is
> > in mergeinfo. Am I missing something?
> >
> >
>
> I originally thought it served as a kind of peg revision. Now I see no
> use in this table. Probably it exist to check the elided mergeinfo
> faster with *relativey less number of records* than doing a query on
> 'mergeinfo table' which will have huge number of records due to full
> text mergeinfo.

I suspect that an index is an index is an index, and that this would
not serve as an optimization. But we'd have to profile it.

> But in my issue-2897 branch it serves a purpose of tracking what exactly
> merged in a commit, which 'mergeinfo'(fulltext mergeinfo) table cannot do.

Looking at the branch, it looks like mergeinfo_changed will always be
a subset of mergeinfo. Couldn't you just add a boolean "changed"
field to mergeinfo? Or perhaps I'm misunderstanding.

(We really should document the schema semantically somewhere, perhaps
in mergeinfo-sqlite-index.c in a big comment at the top.)

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 27 11:20:52 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.