MenTaLguY spiegò:
Just curious, why do you think that git is more robust than mercurial?
Git stores everything as read-only files, named with the cryptographic hash of their contents.
As you mentioned it, storing files as read-only is one of the most annoying features of SVN and GIT. :)
It only makes people use "rm -Rf" blindly to delete a tree... :(
However, I'm not sure that what you said is also true when considering packs, as it is a form of repo rewrite, but my understanding of GIT's internals is limited.
Files are never modified once created, and all operations are atomic at the filesystem level, mostly obviating the need for locking.
Oh, you're right, Mercurial does need a bit of locking while doing a commit.
The main benefit of the Mercurial repo format is the total lack of maintenance, while in GIT you have to repack and prune once in a while or the performances will degrade over time.
Mercurial stores each file's history separately, with multiple revisions combined in the same file, sort of like CVS. These files are append-only, but do require locking for updates.
Also, with the transactions-based approach it is still quite robust, as if something fails before the end of the commit/push the files are simply truncated in a trivial manner and the repo consistency is restored.
In reality, I think Mercurial is only "non-robust" by comparison to git, since Mercurial is pretty careful about detecting when something has gone wrong. I just prefer systems where it isn't possible for something to go wrong in the first place (down to the guarantees given by the operating system, at least).
Fortunately as both are based on cryptographic hashes it is very easy to detect errors. :)
I always appreciated the simpler design of the initial GIT repo format, but with the addition of packs the elegance is gone.
As far as I'm concerned the Mercurial solution is the right tradeoff between elegance and performance.