Recovery from interrupted hg pull.

[ISHIKAWA,chiaki]

The subject says all.

I had to somehow interrupt an "hg pull -u" command that seemed to get
stuck for a very long time.  :-(

But then I cannot recover from it. (I had to interrupt  hg a few times
before over the last few years, and each time hg recovered gracefully.
This time it did not.

The log below.
I suspect I have to create the local repo from scratch?

Any tips will be appreciated.

TIA

Chiaki


The log below.
The first | hg pull -u | command got stuck at "===>" without reaching
the right bounary |
for quite a while and there was no indication of completion.

---

ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ hg pull -u
pulling from https://hg.mozilla.org/mozilla-central/
searching for changes
adding changesets
adding manifests
adding file changes
files
[========================================================================>
] 2419/3508 11s
transaction abort!
rollback failed - please run hg recover
(failure reason: attempted to truncate
data/intl/icu/source/data/brkitr/dictionaries/laodict.txt.i to 46273
bytes, but it was already 192 bytes
)
interrupted!
ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$
ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ hg pull -u
pulling from https://hg.mozilla.org/mozilla-central/
searching for changes
abort: abandoned transaction found
(run 'hg recover' to clean up transaction)
ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ hg recover
rolling back interrupted transaction
abort: attempted to truncate
data/intl/icu/source/data/brkitr/dictionaries/laodict.txt.i to 46273
bytes, but it was already 192 bytes

ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ hg pull -u
pulling from https://hg.mozilla.org/mozilla-central/
searching for changes
abort: abandoned transaction found
(run 'hg recover' to clean up transaction)
ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ hg recover
rolling back interrupted transaction
abort: attempted to truncate
data/intl/icu/source/data/brkitr/dictionaries/laodict.txt.i to 46273
bytes, but it was already 192 bytes

ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ hg recover --help
hg recover

roll back an interrupted transaction

    Recover from an interrupted commit or pull.

    This command tries to fix the repository status after an interrupted
    operation. It should only be necessary when Mercurial suggests it.

    Returns 0 if successful, 1 if nothing to recover or verify fails.

options:

  --verify run `hg verify` after successful recover
  --mq     operate on patch repository

(some details hidden, use --verbose to show complete help)
ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$ hg recover --verify
rolling back interrupted transaction
abort: attempted to truncate
data/intl/icu/source/data/brkitr/dictionaries/laodict.txt.i to 46273
bytes, but it was already 192 bytes

ishikawa@ip030:/NREF-COMM-CENTRAL/mozilla$
---

[ISHIKAWA,chiaki]

Hi, I am reporting my successful recovery process.
Actually, I had to recreate the local mozilla repository in the end.
The local changes were in MQ data, and they were luckily not corrupted
and thus could be applied to new repository rather easily.

I had to run |mach bootstrap| for successful build again and so as a
caution to someone who is in a similar difficulty in the future, I am
posting this.

I am using mozilla-central and thus I　replaced mozilla-unified in the
following webpages with mozilla-central.

Steps to recreate local mozilla repository.
I followed the steps in the following web pages. I used hg bundle.

https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html#firefox-contributors-quick-reference

https://firefox-source-docs.mozilla.org/contributing/vcs/mercurial_bundles.html#mercurial-bundles

I only corrupted local ./mozilla hg repository, and ./comm subdirectory
was intact (yes, we have two independent HG repositories.
It is a curse sometimes, but it helps quite a bit this time around since
I place local MOZCONFIG file under ./comm directory. I do have backup of
configuration files on a different disk in gzipped tar format.)
So, I moved the content of healthy old trashed-mozilla/comm (C-C) to the
new mozilla directory.
I also updated .hg/hgrc from local copy before running |hg update| and
|hg pull -u|.

CAUTION: |mach bootstrap| is required again (!)

Somehow, the compilation after this re-creation failed in a mysterious
manner.
It seems there are some configuration files that are affected by |mach
boostrap|. (?)
It took me a while to figure this out.

So, I had to run this again before I can build successfully.

There is another strange thing that I could not figure out exactly.
I could not run |mach xpcshell-test| initially via a local script under
"~/bin".
mochitest could be executed successfully.

I still could not figure out the reason, but the old local script
somehow missed setting environmental variable(?) and
still |mach| invocation worked. This is actually very strange.
Now I put the proper environmental variable setting in the local script
and now all is well.
It is possible that I created a local patch that affects the search path
or something
(I inserted lines in mach-related python scripts to track down the issue of
running TB under valgrind successfully) , and although most such changes
were
recorded in local MERCURIAL QUEUE (MQ)) patches, I may have missed few
during the repository shuffle (?)

So I am now building and testing M-C/C-C locally again.

Hope this may help someone in a similar predicament.
The need for running

    |mach bootstrap|

after recreation was not quite clear to me.

Chiaki

PS: I used to create local MQ patch queues by manually applying the
patches when I needed to create a new HG repository on a new PC, etc.
That is, I apply each MQ patch by hand to a newly created directory. But
it was such a chore.
Now I figured out if the newly created local repository is without MQ
patch queues (it usually is), we can simply
copy the old .hg/patches-*  (content of patches themselves), and
.hg/patches.queue{,s} to the new repository's .hg/ subdirectory,
and MQ extension works all right. patches.queue seems to contain the
last used mq queue. (I have no idea where the level, i.e., the
sequential number of the mqueue applied is stored. But since the newly
created directory does not have any MQ queue applied, it doen't matter.)

PPS: I did not know that the new mailing list does not deliver the
original e-mail submitted by myself to me. (It seems I did not receive it.)
It is a bit non-intuitive behavior. I thought it was not posted, but
when I googled for a similar issue, I found the following copy of my own
post.
https://groups.google.com/a/mozilla.org/g/dev-platform/c/pKhI-Uk_FNE