Re: hg repo corruption: ".hgsubstate is corrupt in revision ..."

[Mike Miller]

On Thu, Mar 28, 2019 at 01:15:09 -0400, Andrew Janke wrote:
> Sorry I dropped this thread back when. I'm picking up this issue again
> because I'd like to be able to use the DVCS features of Hg with Octave,
> sharing my forked repo between multiple machines I work on, and sharing
> public branches with y'all.

Sure.

I don't know how well versed you are in Hg, but one big difference with
Git is that branches are permanent, like SVN. Use bookmarks instead, the
effect is roughly similar to Git topic branches.

> Here's the hg push failure. There are no useful diagnostics in it.
> 
> [octave] $ cat .hg/hgrc
> [paths]
> default = https://hg.savannah.gnu.org/hgweb/octave
> bitbucket = ssh://address@hidden/apjanke/octave-fresh-01
> [octave] $ hg push bitbucket
> pushing to ssh://address@hidden/apjanke/octave-fresh-01
> no changes made to subrepo gnulib since last push to
> http://hg.octave.org/gnulib
> searching for changes
> remote: adding changesets
> remote: adding manifests
> remote: adding file changes
> remote: transaction abort!
> remote: rollback completed
> remote: received spurious file revlog entry
> abort: push failed on remote

Ok, I tried the same thing with a fresh new repository on Bitbucket. I
get a slightly different error after it looks like it has pushed
manifests and files

    remote: Connection to bitbucket.org closed by remote host.
    abort: stream ended unexpectedly (got 0 bytes, expected 4)

So I tried bisecting, first once, then twice, and I finally got a
successful push by pushing the first ¼ of the revisions on the default
branch

    hg push -r d5d6a670f137 new

I kept pushing ¼ at a time and got the whole history pushed in 4 batches
of ~6500 changesets each, plus one more for stray side branches

    hg push --new-branch -r 2e4252228f73 new
    hg push --new-branch -r 6cfbf412a2c3 new
    hg push --new-branch -r @ new
    hg push --force -r "public()" new
    hg push -B @ new

If you try that, maybe you'll have better luck pushing the whole history
in batches. Maybe Bitbucket can't handle the size of our repository all
at once? Maybe it has a post-receive hook that is timing out on such a
huge number of changesets? I really don't know.

I have to say after a few years of using Hg on Bitbucket off and on,
it's really not pleasant. I've found quite a few rough edges. Enough to
make me not want to use it for collaboration again.

-- 
mike