Home / server / Questions / 91681
Accepted
bobinabottle
Asked: 2009-12-08 06:12:06 +0800 CST

Mercurial repository corruption

  • 772

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.

mercurial

4 Answers

  1. Best Answer

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

    [server]
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!

    • 4

  2. 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.

    • 2

  3. 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?

    • 0

  4. 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.

    • 0