Re: merge tracking use cases

On Sat, 01 Dec 2007, Kamesh Jayachandran wrote:

> >FWIW, I like what David has done and it all makes a lot of sense in
> >solving the problems. I see a lot of messages where everyone is
> >assuming that 2897 requires SQLite. We all assumed the same for MT
> >and David has proven we do not. I think we need to get a clear answer
> >from Kamesh about what the exact info is that he needs so that we can
> >explore whether the repository can provide that information.
>
> >It seems like the only time we would need SQLite is if we needed to do
> >a complicated query of a tree. I did not get the impression that
> >Kamesh's change needed that. I thought what it needed was to store
> >some extra info that stated specifically what revisions were merged.
>
> >It seems like we could accomplish that (possibly) using just the
> >repository.
>
> I think retrieving the commit revs for set of merge ranges directly from the repository would be too complex, I am not aware David's recent work.
>
> I need some simple to retrieve 'commit revs for merge ranges' accounting for 'elision' as long as I have it that is fine.
 
I was wondering about this too. Minimizing/removing the use of SQLite is
Goodness, but we still need to be able to answer questions posed by Kamesh's
issue-2897 branch. Glasser and I talked this over a bit last night on IRC.

IIUC, #2897 needs to know, "for a given revision range, tell me what mergeinfo
was added/removed between revisions in the range", allowing us create a
"merge plan" used to deal correctly with reflected revisions. Whatever means
we use to answer this question (e.g. separate index or straight FS) needs to
take mergeinfo inheritance into consideration. To me, this seems more
complicated to answer using only the FS, since you need to walk the FS in two
dimensions: depth up the tree (towards the repository root), and time
(revision history of the repository). You may also need to take mergeinfo
elision into consideration, further complicating matters.

If we do retain an SQLite-based mergeinfo index, we need to perform mergeinfo
indexing during copy and delete operations (as pointed out by glasser), for
both FSFS and BDB.
 
> >Assuming Kamesh has some kind of decent solution in progress, and we
> >can replace the part that needs to access SQLite, we could
> >realistically have these problems dealt with in a decent timeframe.
>
> Yes.

Either solution is palatable to me. That said, at this point in the release
cycle, I'm most interested in a) reducing stability risk from code churn and
b) minimizing implementation time.

During last night's discussion on IRC, I asked glasser how difficult it
would be to add indexing to the FS code during copy and delete. After some
consideration and discussion, it seemed like it was perhaps not as difficult
as he first thought. If we can get a comprehensive gauge on its cost, and on
the cost of answering the type of question that the issue-2897 branch needs
answered using an FS-based solution, we'll understand the trade-offs well
enough to proceed in the right direction.

Until then, I'd really appreciate it if folks would hold off on the gloom
and doom. As always, contributions of code, code review, and design
suggestions are most appreciated. (Review of issue #2992 seems like some
lower-hanging fruit; looked like it needs more work to me.)

Thanks, Dan