CODEWITHSUNDEEP
mercurialbundle
Kris Morness
Kris Morness

Reputation: 584

hg bundle not working

I'm trying to create a bundle for a remote team. They have a copy of the depot from revision 892 and we are currently on revision 1119.

First I tried patches, but that created a ton of files that botched up when trying to apply them (usually on the merge submits)... and our repository is 17GB in size, so I'm trying to create a delta patch, thus figured hg bundle was perfect for this.

I generated a bundle via:

>hg bundle --rev 1119 --base 892 depot-892-to-1119.bundle

This created a bundle file that is 350MB, which is acceptable and feels right.

But when we apply it to the the destination depot that only goes to revision 892 it barfs on: 

E:\dest-depot>hg unbundle -u depot-892-to-1119.bundle
adding changesets
transaction abort!
rollback completed
abort: 00changelog.i@e5cc33458251: unknown parent!

And so far this is similar to several other questions I have seen while searching, but I'll take it one step further.

I looked up e5cc33458251 in the source (bigger depot) and it shows up as revision 930 which is clearly after rev 892, but specifies this is the reason for the failure. Of course the destination depot doesn't have the revision. That is why I created the bundle in the first place.... so I'm not really sure why this one is causing me problems.

Now we do have a number of branches in the depot and rev 892 was tipped on a "Patch 2.7" branch and not default. I do not know if this should cause a problem. Eventually that patch branch was merged back into default in rev 999.

930 was actually a very small and trivial change to code and was also in "Patch 2.7" branch. There were actually 2 Patch 2.7 lines in the revision graph and they were merged together in 932. But again, nothing strange.

I am not seeing the problem here. Any ideas on what kind of a bundle I should be generating? Or if I should be going a different path?

Upvotes: 1

Views: 881

Answers (1)

Ry4an Brase
Ry4an Brase

Reputation: 78350

It sounds like you're doing this essentially right, so let's check a few possible gotchas:

Are you aware that revision numbers aren't portable across clones? It's entirely possible that "their" 892 is different from yours. So you should find out what their latest revision is by nodeid and use that as the parameters to base.

I get that with their being remote using hg's internal protocol to actually transfer the data might not be feasible, but if you can get them to stand up a hg serve for a short while you can just do:

hg bundle ../depot-to-them.bundle http://THEIR_IP:8000

Then you'll have exactly the right bundle to get them everything they need without having to have them send you their nodeids.

Those aside the only other bit of info that might be worth mentioning is that by using --rev X --base Y you're saying "I want to send all the ancestors of X that they don't have if they only have Y and its ancestors", so if there's a branch that's not yet merged into X you're not going to be sending it, even if locally the revision numbers are between X and Y. That won't, however prevent the bundle from being applied, so it's more of a good-to-understand rather than a possible cause of your troubles.

Upvotes: 3

Related Questions