3

TLDR: I have an HG bundle with parent X, but revision X does not exist in my repo. However, I am sure that the files of revision Y are identical to revision X. How do I apply the bundle?

Background:

I use hgsubversion to interact with an SVN repo.

There were some changes I did not want to commit. hgsubversion does not support partial pushes.

I used to workaround by manually creating temporary exports/patch files, or manually restoring .orig files (result of hg revert).

In this case I committed the changes I did not want to push, then used hg strip, then pushed, then tried to use hg unbundle .hg/strip-backup/file.

Problem: hgsubversion replaces the original changeset with a new one it imports from SVN after it's committed it. Result: the changeset ID changes. This is a problem because now hg unbundle no longer works, as it relies on the parent changeset being there (but it's been stripped).

Ironically, hgsubversion itself uses strip and thus has a backup file I can use to strip the new rev, add the stripped old revision, then apply the bundle with my revisions, export the patch, strip both, and restore the SVN revision. But this sounds... extremely painful and stupid. Is there nothing better I can do?

(hg transplant doesn't seem to like the bundle without having the parent in the repo, either)

Gijs
  • 5,201
  • 1
  • 27
  • 42
  • Do you still have the changesets in question, probably in .hg/strip-backup? If so, it’s easy using MQ. If not, things could become pretty nasty. – Ringding Sep 30 '11 at 19:32
  • Do you realise that if you update to a specific version, hgsubversion will only push to that revision? e.g. you can do partial commits. – Stephen Dec 29 '11 at 17:49

2 Answers2

3

It's effectively impossible to use a bundle without the bundle's precise parent changesets. Bundles consist of compact binary deltas that can only be applied to the precise binary source. There is no 'context' available that would allow Mercurial to guess how to apply them to other revisions the way patch does. In core Mercurial, this is never an issue because changesets are never removed, but extensions like hgsubversion and mq break the rules.

(If you can recover the stripped changesets from a backup bundle in .hg/strip-backup, you can then rebase your changes and strip again.)

mpm
  • 1,935
  • 11
  • 13
  • Yeah, this is what I did in the end. If I ever find some spare time (ha, ha), I guess I'll have to look into hacking hgsubversion so it can do partial pushes... Thanks! – Gijs Oct 13 '11 at 08:33
0

Background: After hitting an issue with hgsubversion pushing only 1 revision successfully, I got lazy in my commits (partial commits are possible if you update to the latest revision you want to push), and ended up starting to commit everything. So I killed the push and for the first time it failed to keep my later revisions.

I tried recover, but that was not able to find the parent commit. What worked for me was restoring the ...-backup.hg file (there was a ...-temp.hg file in strip-backup too).

The strange thing (which is why I'm answering this) is that it only gave me a warning about the parent not being there (I have no idea why)...

warning: ignoring unknown working parent d5663567bc4b!
adding changesets
adding manifests
adding file changes
added 21 changesets with 1255 changes to 941 files
(run 'hg update' to get a working copy)

BTW, I'm running Mercurial version 2.0

Stephen
  • 19,488
  • 10
  • 62
  • 83