This is somewhat related to this question but is a different question.

We have a central Hg repository, served to users via SSH and mercurial-server. We have a number of Mac, Linux and Windows clients connecting to it.

It has happened twice now that one of the Windows users has corrupted their repository, then pushed back to the central one corrupting it. I want to write an incoming hook script on the central repository to prevent a transaction from being accepted if it will corrupt the central repo.

Although unfortunately I don't know enough about Mercurial to write such a script. Any possibility that someone else has come across this? Personally I'm not quite sure why hg doesn't do this by default.

  • I've found a solution here: davidherron.com/blog/topics/… that would need to be done on all the clients. But if anyone has a better solution that can do done for the central repo itself that would be better. Commented Dec 7, 2009 at 15:36
  • Please give us more details: what version of Mercurial are you using on the server and on each of the clients? Commented Dec 21, 2009 at 23:34
  • 2
    Also, it would be extremely useful for us (the Mercurial developers) if you could reproduce this. Please also report such issues to us directly via our mailinglist: mercurial.selenic.com/wiki/MailingLists or bug tracker: selenic.com/mercurial/bts That is much more productive than posting here :-) Commented Dec 21, 2009 at 23:38

4 Answers 4


Recent versions of Mercurial (since 1.5) support validation of incoming data. Add

validate = True

to your server's hg config (either .hg/hgrc or the hgwebdir config should work fine) to have the server verify incoming data and refuse invalid pushes. The client will then see an error akin to:

remote: abort: missing file data for beta:dddc47b3ba30e54484720ce0f4f768a0f4b6efb9 - run hg verify

Hope that helps!


Maybe you should avoid pushing to repository altogether. With Mercurial and its distributed nature, everybody can have their branch, and when they feel they are ready, they tell you and you pull from them. No commit-access problems, no push that will break stuff...

This is at least an advice a friend of mine has given me, when I was migrating from SVN to Mercurial.

I don't know, if this is an option to you, but setting up a personal repository for everybody and then pull from the people you need might require less work, than trying to catch dangerous pushes.

  • Not pushing to HG defeats its whole purpose - multiple users working together
    – Anonymouse
    Commented Nov 23, 2016 at 16:27

Could you not do the same thing as David Herron's Blog, but instead of doing it on prerouting, do it on the precommit hook on the central repo?

  • Nope :-( I've tried that but it ends up in a deadlock. When a client attempts to push it reserves a lock on the repository. Running a 'hg verify' also requires a lock, so it ends up just waiting forever in an endless loop. Commented Dec 14, 2009 at 11:45
  • Also, even if this did work on precommit, it would verify the repository, see that it is ok, then commit the changes that would corrupt it. Really I would need a hook to assess whether the incoming changes would corrupt the repos, if so roll back the transaction. So It would make more sense to be on the changegroup hook. Commented Dec 14, 2009 at 11:55
  • (Using the changegroup hook still results in deadlocks) Commented Dec 14, 2009 at 11:56
  • Interesting - the hooks seem to be python based. Do you know what is corrupting the repository? Is the same thing each time? Commented Dec 14, 2009 at 14:37

One possible alternative is to:

  1. Clone the repository AFTER the push.
  2. Verify it.
  3. If the respository is good, archive it as the latest good one
  4. If the respository is corrupted, raise an alarm
  5. On alarm, restore the lastest known good respository.

This solution is not what you required, but at least, you get a way to rollback your repository in case of corruption.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .