Bug 2137 - API: after adding changesets, repo.lookup() does not recognized added changeset IDs
Summary: API: after adding changesets, repo.lookup() does not recognized added changes...
Status: RESOLVED FIXED
Alias: None
Product: Mercurial
Classification: Unclassified
Component: Mercurial (show other bugs)
Version: unspecified
Hardware: All All
: normal bug
Assignee: Greg Ward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-04-13 13:19 UTC by Greg Ward
Modified: 2018-03-11 00:00 UTC (History)
4 users (show)

See Also:
Python Version: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Greg Ward 2010-04-13 13:19 UTC
I'm working on a script that does the equivalent of

  hg -R target incoming --bundle incoming.bundle master
  hg clone target tmptarget
  hg -R tmptarget unbundle incoming.bundle

  cd tmptarget
  for each branch in tmptarget with >1 head:
      hg update earlier head on branch
      HGMERGE=internal:fail hg merge && hg commit -m"merge" || exit 1

  hg push target

in one process.  (The reason for tmptarget is that I need a place to do
merges after applying the bundle.  I can't do it in target because that's
one of the central repos on my server, and merging might fail.  So I must
not add any changesets to target until I know it all went well.)

In certain circumstances, the push to target finds no outgoing changesets
even though unbundle really did add changesets to tmptarget.  At a high
level, I can illustrate the problem like this:

  tip1 = hgnode.short(tmptarget.changelog.tip())
  tip2 = hgnode.short(tmptarget.lookup(tip1))
  assert tip1 == tip2

This actually never gets to the assert -- it raises RepoLookupError in the
call to tmptarget.lookup(tmp1), which seems like a violation of some pretty
basic contracts.

I'm still digging.  Will post more when I have more info and (hopefully) a
reproduction script.
Comment 1 Brendan Cully 2010-04-14 02:00 UTC
See http://hg.intevation.org/mercurial/crew/rev/cf016c9831d1
(revlog: factor out _maxinline global.)
Comment 2 Greg Ward 2010-04-14 07:32 UTC
This is not unique to unbundle; the same thing happens after pull or commit too.

What's going on is this:

  * repo.lookup() uses revlog._partialmatch()
  * which depends on lazymap.__iter__() to yield a sequence of revnums
  * but lazy.__iter__() uses xrange(self.p.l), i.e. it assumes that 
    self.p.l is an accurate count of revisions in the revlog
  * but it isn't, since self.p.l is only set once, when the revlog
    is first read -- it's not updated by adding revisions
Comment 3 Greg Ward 2010-04-14 08:29 UTC
I've got a fix, and I'm just working on making the test compact.  Patches
coming soon...
Comment 4 Greg Ward 2010-04-14 13:19 UTC
Patches posted to mercurial-devel.
Comment 5 Brendan Cully 2010-04-15 07:00 UTC
See http://hg.intevation.org/mercurial/crew/rev/b7ca37b90762
(revlog: fix lazyparser.__iter__() to return all revisions (issue2137))
Comment 6 Brendan Cully 2010-04-15 08:00 UTC
See http://hg.intevation.org/mercurial/crew/rev/bce47e253b61
(simplify test-issue2137, make it more portable)
Comment 7 Greg Ward 2010-04-15 08:28 UTC
Fixed in crew-stable.
Comment 8 HG Bot 2010-05-01 16:00 UTC
Fixed by http://hg.intevation.org/mercurial/crew/rev/6bbe4886740e
(test-issue2137: don't use $PWD; use `pwd` instead)
Comment 9 HG Bot 2010-09-10 13:00 UTC
Fixed by http://hg.intevation.org/mercurial/crew/rev/c55d69c5fb77
Adrian Buehlmann <adrian@cadifra.com>
tests: unify test-issue1438 and test-issue2137
Comment 10 Bugzilla 2012-05-12 09:08 UTC

--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:08 EDT  ---

This bug was previously known as _bug_ 2137 at http://mercurial.selenic.com/bts/issue2137
Comment 11 HG Bot 2018-03-03 14:40 UTC
Fixed by https://mercurial-scm.org/repo/hg/rev/c4ccc73f9d49
Augie Fackler <augie@google.com>
tests: add missing b prefix in test python in test-issue2137.t

# skip-blame just a b prefix

Differential Revision: https://phab.mercurial-scm.org/D2539

(please test the fix)
Comment 12 Bugzilla 2018-03-11 00:00 UTC
Bug was set to TESTING for 7 days, resolving