Patchwork [1,of,2,STABLE] annotate: reuse already calculated annotation

login
register
mail settings
Submitter Katsunori FUJIWARA
Date March 28, 2013, 10:36 a.m.
Message ID <53691948fe037f64fe97.1364467017@feefifofum>
Download mbox | patch
Permalink /patch/1204/
State Superseded
Headers show

Comments

Katsunori FUJIWARA - March 28, 2013, 10:36 a.m.
# HG changeset patch
# User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
# Date 1364464124 -32400
# Branch stable
# Node ID 53691948fe037f64fe97d4eb7fad76ebda4edf6a
# Parent  43dfb6fce6a76168766f3b73f4c991ab811590ec
annotate: reuse already calculated annotation

Before this patch, annotation is re-calculated even if it is already
calculated. This may cause unexpected annotation, because already
cleared "pcache" ("pcache[f] = []") prevents from scanning ancestors.

This patch reuses already calculated annotation if it is available.

In fact, "reusable" situation should be seen only on legacy
repositories which include the merging between the revision and its
ancestor, because:

  - tree is scanned in depth-first

    without such merging, annotation result should be released soon

  - recent Mercurial doesn't allow such merging
Katsunori FUJIWARA - March 29, 2013, 1:44 p.m.
At Thu, 28 Mar 2013 10:35:46 -0500,
Kevin Bullock wrote:
> 
> On 28 Mar 2013, at 5:36 AM, FUJIWARA Katsunori wrote:
> 
> > # HG changeset patch
> > # User FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
> > # Date 1364464124 -32400
> > # Branch stable
> > # Node ID 53691948fe037f64fe97d4eb7fad76ebda4edf6a
> > # Parent  43dfb6fce6a76168766f3b73f4c991ab811590ec
> > annotate: reuse already calculated annotation
> > 
> > Before this patch, annotation is re-calculated even if it is already
> > calculated. This may cause unexpected annotation, because already
> > cleared "pcache" ("pcache[f] = []") prevents from scanning ancestors.
> > 
> > This patch reuses already calculated annotation if it is available.
> > 
> > In fact, "reusable" situation should be seen only on legacy
> > repositories which include the merging between the revision and its
> > ancestor, because:
> > 
> >  - tree is scanned in depth-first
> > 
> >    without such merging, annotation result should be released soon
> > 
> >  - recent Mercurial doesn't allow such merging
> 
> ...except that we _do_ allow it if the ancestor is on a different
> named branch.

Thank you for your suggestino, Kevin.

As you described, we can merge the revision and its ancestor, if the
ancestor is on a different named branch.

But to reproduce issue3841:

  - the ancestor should be the second parent of merging revision

    such merging is aborted as "merging with a working directory
    ancestor no effect" in mercurial/merge.py

  - filelog should include such merging

    merging across named branch causes creation of such merging in
    changelog and manifest, but never in filelogs.

    in "localrepository._filecommit()", second parent is ignored just
    before creating new entry into filelog, if one of parents is an
    ancestor of the other:


I'll re-post patch series which also describes above detail.

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy@lares.dti.ne.jp

Patch

diff -r 43dfb6fce6a7 -r 53691948fe03 mercurial/context.py
--- a/mercurial/context.py	Fri Mar 01 11:54:36 2013 -0300
+++ b/mercurial/context.py	Thu Mar 28 18:48:44 2013 +0900
@@ -710,9 +710,14 @@ 
                     needed[p] = needed.get(p, 0) + 1
             if ready:
                 visit.pop()
-                curr = decorate(f.data(), f)
+                reusable = f in hist
+                if reusable:
+                    curr = hist[f]
+                else:
+                    curr = decorate(f.data(), f)
                 for p in pl:
-                    curr = pair(hist[p], curr)
+                    if not reusable:
+                        curr = pair(hist[p], curr)
                     if needed[p] == 1:
                         del hist[p]
                     else: