How much is Hg/Git repository corruption an issue?
Environment: 14 or so engineers/physicists/mathematicians (read: none really interested in spending their time on things like repo maintance and similar things)
They will be using it, in terms of software engineering nowadays, for rather small projects, but one can expect that a lot of non-code stuff will also wind up in there (data files, some images, some PDF and word documents … nothing large in size but it will wind up in there along with the source files).
How much is repository corruption in such environment an issue when using either Hg or Git?
Platform: Windows and Mac’s (mostly Windows)
3 Solutions collect form web for “How much is Hg/Git repository corruption an issue?”
Personally (using Mercurial) I never experienced a technically corrupted repository. Actually I’d say the chance to corrupt a repository is very very low when using the regular commands only (add/remove files, commit, push, pull, merge).
Things might get more complicated when you start playing around with history, e.g. permanently delete changesets, rebase branches, collapse changesets — these action inherently are destructive. However, while you can act destructively in Mercurial, you’ll have to enable the corresponding commands explicitly and often get meaningful warnings prior execution of potentially problematic commands.
AFAIK Git has less barriers in corrupting a repository because it supports more destructive action by default (Git users, correct me if I’m wrong).
Finally you shouldn’t care that much: One big advantage of DVCS is that each clone is an independent complete repository. If a repo is corrupted, only one or a few developers are affected by this problem. If the problem cannot be fixed, reclone from the central or a colleague’s repo and continue working on that state.
If by corruption you mean erroneous manipulation that will lead to a strange state of the repository, there sure will be some at the beginning when your coworkers will learn to use the new tool.
But Git and Mercurial both offer some tools to mend broken repositories. As long as your team is disciplined, I think it’s safe to say that there will be no corruption problem that can’t be corrected.
I advice you to choose at least one person as administrator and then take your time to think about the structure you want to give to your repositories.
I wouldn’t worry about on-disk corruption. Sure, having everything tightly packed makes a bit flip more dangerous, but since everything is cloned everywhere else you’re unlikely to lose data.