CODEWITHSUNDEEP
version-controlmercurialdvcsrestorecorruption
user1213546
user1213546

Reputation: 88

How to deal with Mercurial when disk corruption/restore has returned the master-repo to an old state

I wonder if anyone can give me advice on how to cope with the aftermath of one of our disks being corrupted, and the restored to an old state. Here's the story:

I have some code I manage with Mercurial. There is a "master" repository on disk A, and a branch/clone on disk B. The timeline looks like this

  1. Start with master repository. There are various extant branches/clones for prototyping new features.
  2. clone master repo on disk A--> another new branch on disk B
  3. commit changes to master repo, and push to new branch
  4. disk A is corrupted
  5. disk A is restored to state at timepoint 1.
  6. Disk B is unaffected

What should I do?

Option1: - Very little has happened on the branch since the actual branching. So just blow away the master repo, and start using the new branch as my new master. If I do this, won't I have problems merging my old clones (mentioned at timepoint 0) back in?

Option2: - Just manually make the changes in my master that have been lost my diffing with the new branch. Even if I do this, how am I going to carry on pushing to the new branch?

Option3: - Just manually make the changes in my master that have been lost my diffing with the new branch. Then delete the new branch, and clone a new one.

Any advice welcome cheers Zam

Upvotes: 3

Views: 105

Answers (1)

Martin Geisler
Martin Geisler

Reputation: 73798

I know you say the question is answered, but let me offer some advice anyway. You ask:

Option1: Very little has happened on the branch since the actual branching. So just blow away the master repo, and start using the new branch as my new master. If I do this, won't I have problems merging my old clones (mentioned at timepoint 0) back in?

You wont have any problems with merging old clones of the master repository. Imagine you have the master repo M and clones X and Y. Let's say they contain changes like this (time flows to the right):

M: [m1] --- [m2] --- [m3]

X: [m1] --- [x1] --- [x2]

Y: [m1] --- [m2] --- [y1] --- [y2]

So X was a clone of M when only [m1] existed, Y is a clone of M after [m2] was made. Neither X nor Y has [m3] — this changeset was apparently commited directly into the M repository by working on the server.

You now discover that the disk with M is faulty and you restore it from backup. The backup only has [m1]. The world situation now looks like this:

M: [m1]

X: [m1] --- [x1] --- [x2]

Y: [m1] --- [m2] --- [y1] --- [y2]

When you compare the overall situations you'll see that only changeset [m3] is missing: it's the one that was not in any of the clones (X and Y).

After the restore you can push [m2] from Y to M to salvage as much data as possible. This is done with a simple

$ hg push -r m2

where m2 is the revision number or changeset hash in question.

So my advice is to look at the overall picture: find your clones and figure out what changesets you still have distributed among them and what is missing. Push what you need back to the master repository and setup a backup scheme with more frequent backups :-)

Note also that you only lost [m2] because it only existed in a single clone. Normally, you will make new changesets in local clones and then push them to a master repository. That way, you automatically have a duplicate of all changesets in the master! That makes it harder to lose changesets since people can just push their work back after a restore.

Upvotes: 3

Related Questions