| 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
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:
# 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