[issue1320] Failures in 'hg in --bundle': 'abort: 00changelog.i at ...: unknown parent!'

Jesse Glick mercurial-bugs at selenic.com
Wed Oct 1 14:36:25 CDT 2008


New submission from Jesse Glick <jesse.glick at sun.com>:

We have a number of Hg repositories (all served over HTTP(S)) and various Hudson
continuous builders routinely polling them for changes. Hudson's Hg plugin uses
the following idiom:

hg incoming --quiet --bundle hg.bundle --template "...."
hg pull -u hg.bundle

(The build's changelog is computed from the template output, while the use of
hg.bundle ensures that the changes are pulled over the network just once.)

This works fine most of the time. Once in a while, for no apparent reason, the
incoming call dies with e.g.

abort: 00changelog.i at 61eac836a4a7: unknown parent!

If you look up #61eac836a4a7 on the repository being served, it exists and is a
normal-looking changeset (in this case a merge done by 'hg fetch').

The error is sporadic - generally the next build of the same job proceeds normally.

The error message appears to come from bundlerepo.bundlerevlog's constructor:

            for p in (p1, p2):
                if not p in self.nodemap:
                    raise revlog.LookupError(p1, self.indexfile,
                                             _("unknown parent"))

First of all, the error message looks wrong to me; I would assume that p, not
p1, is the node which should be passed to the message (compare similar code in
revlog.py).

The loop seems to assume that parent revisions precede children in the iterator.
Is this a safe assumption?

----------
messages: 7265
nosy: jglick
priority: bug
status: unread
title: Failures in 'hg in --bundle': 'abort: 00changelog.i at ...: unknown parent!'

____________________________________________________
Mercurial issue tracker <mercurial-bugs at selenic.com>
<http://www.selenic.com/mercurial/bts/issue1320>
____________________________________________________



More information about the Mercurial-devel mailing list