.. in manifests not found / only partial clone

[Matt Mackall]

On Fri, 2014-12-19 at 23:57 +0100, Benito van der Zander wrote:
> Hi,
> despite having set the extended +a attribute on all .i files, I again 
> lost some history data :(

Was there a proximal cause to this data loss? Power outage? Abort caused
by setting +a (even though I told you it was a bad idea)?

What filesystem are you using? Ext4?

> I tried to restore it like the RepositoryCorruption wiki says with
> 
> $ hg clone -r 3672 ~/hg fixed
...

> 11 revisions are missing.
> 
> How can this happen?
>
> Does clone not clone all branches?

$ hg help clone
...
    To pull only a subset of changesets, specify one or more revisions
    identifiers with -r/--rev or branches with -b/--branch. The resulting
    clone will contain only the specified changesets and their ancestors.

You can ask Mercurial which revisions you need to clone thusly:

$ hg log -r "heads(not 3673::)"

> In fact, when I try to clone the branches directly it fails:
> 
> $ hg branches
> default                     3676:0fb3610282a4
> videlibri-sk                3217:51428989e7dc
> $ hg clone -b videlibri-sk . /tmp/wtf
> abort: unknown branch 'videlibri-sk'!

That's very odd. May be a bug. Or it may be that you've got the branch
cache marked append-only and it's now corrupt because Mercurial tried to
update it and silently failed.

> $ hg clone -r 3217:51428989e7dc . /tmp/wtf
> abort: unknown revision '3217:51428989e7dc'!

The string "3217:51428989e7dc" is not a revision.
It's two different forms of the name for one revision.
Much of Mercurial will now accept this as a revset: the one-element
range of all revisions from 3217 to 51428989e7dc. But not clone, because
it can't hand a revset to a remote server.

-- 
Mathematics is the supreme nostalgia of our time.