RE: Re: merge tracking use cases

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

>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.
Received on Sat Dec 1 19:04:03 2007