recent changes

[Martin Pool]

On 20 Jun 2005, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Martin Pool wrote:
> > Hi, just an update on what I've been up to:
> > 
> > Revisions now allow for tracking multiple parent revisions; those
> > after the first are the revisions that have been merged-in.  This is a
> > slight adjustment from what was previously planned, where the first
> > revision would be stored specially.
> > 
> > Cherrypicked changes or removed changes need to be recorded
> > separately.
> 
> A couple of points I came up with after our IRC discussion:
> 
> Since all ancestor revisions should be stored, making merges into
> ancestors means that we need to store all merged revisions.

Right, or at least feel confident (per policy) that we can fetch them
from some kind of pool.

> Annotate looks harder, but is actually pretty much the same.  If history
> A says the change was introduced by the merge revision, and history B
> says the change was introduced earlier, you follow history B.
> Representing this to the user may be a challenge, though.  

We won't have simple integers to identify them, so it might be hard to
fit it on the screen; in a GUI it'd be less of a problem.

> I haven't figured out how deltas fit in, though.

Do you mean, how do you account for cherrypicked deltas when
annotating?  In principle we can apply the delta to the previous
revision to work out which lines it probably created; this might be
hard in practice.

> Sometimes, ancestors need to become ancestors after-the-fact.  For
> example, if you merge 5-8, commit, merge 0-5, revision 8 is now an ancestor.

Right, so the revision that commits the second merge can add the
ancestor too.

-- 
Martin