How to reduce the size of Mercurial hg store. Hg store size is above 5GB and server gets timeout before cloning

Question

Accidently I checked-in 5GB around of files to Mercurial. Our Build server started failing during cloning of repo. So we reverted the checked- in files by using Remove command. But .hg/store/data is still containing those files. And it's size is over 5GB. We have searched over internet and found few methods, like: hg convert. But hg convert is creating new repo which is not desired in our case. Also we cannot extend the Timeout period of our build server.

How could we remove the bad check-in completely without making it to store in .hg/store/data? Or How could we reduce the size of .hg/store/data?

Answer 1

Here's what you need to do: You need to strip those changesets.

Since your repository is hosted on Bitbucket, you do not have direct access to the files so you need to use what the website provides.

In your repository project, under settings, there is a section for stripping out changesets.

Note that this will also remove any changesets that were committed on top of the bad changeset. We will deal with this.

I will stress this:

1. Make
2. Sure
3. You
4. Have
5. Backups!

Here are the steps

Important: If any developer on your team has anything pending locally, like changesets not yet having been pushed to bitbucket, but they have cloned the bad changeset from bitbucket, then you need to do more grafting, be sure you understand everything that needs to be done before attempting this.

1. Make sure you have a good backup and a local clone of your repository, this is paramount I (or Stack Overflow) is not responsible if you end up losing changesets you want to keep in this process. Pay especially head to the warning above about not-pushed-changesets that other developers might have.

2. In the local clone, first graft any and all changesets that were committed on top of the bad changeset onto the changeset directly preceeding it.

   ie. if the history looks like this:

   1---2---3---BAD---5---6---7
   

   You want to graft 5-7 on top of 3 so that you afterwards have this history:

   1---2---3---BAD---5---6---7
            \
             +--5---6---7
   

3. Then strip the bad changeset (and everything that follows it) by using this command:

   hg strip BAD
   
   `BAD` here is the number or hash of the bad changeset
   

4. Verify that everything looks good locally, then head on to bitbucket.org
5. Find your repository, go into Settings and find the strip changesets section
6. Input the hash of the bad changeset and ask bitbucket to strip it out
7. Afterwards, push from your local clone to bring the changesets you grafted back into bitbucket
8. Important: Now you need to get everyone that has already cloned from bitbucket and gotten the bad changeset need to scrap their local clone and reclone. This will bring down a fresh copy of the repository, without the bad changeset.

Answer 2

The -r option of hg clone allows creating a repository without changesets after a particular revision.

So you can do the following (assuming LAST_GOOD_CHANGESET is the changeset just before your wrong commit):

hg clone -r LAST_GOOD_CHANGESET repo repo.1
mv repo repo.bak
mv repo.1 repo

Note however that this will drop all commits after your wrong commit, so you will have to replay the important ones (i.e. excluding those that were made in attempts to fix the mistake).

Besides, if you have branches, you must list them as additional -r arguments to hg clone, otherwise they will be dropped from the cleaned up repository too.