by sinbad » Mon Oct 26, 2009 4:23 pm
Unfortunately Git is now in danger of ruling itself out since it hasn't been able to convert our Subversion repository without either a) losing a ton of data or b) keeping the data but constantly thinking you've modified files when you haven't. And in addition, when it fails, it's very difficult to figure out why.
Compare this to Mercurial which has not only converted successfully every single time, except when I threw a spanner in the works like such as rsync changing the repo in the middle, but when there is a problem it's really very helpful in identifying why, thanks to the full Python stack trace and useful errors. I even managed to hack on the converter and add an enhancement to the process (convert merge tracking) with relatively little experience. It's a very approachable system internally as well as in its API.
My impression through this process has been that Git is great when it works, which is the vast, vast majority of the time - it vindicated itself to a large extent in my eyes through everyday usage on my fairly small and uncomplicated test repositories (< 500 revisions, 1-2 branches). When it breaks though, God help you. It'll either not give you any useful message at all, or it will give you a 1-line esoteric response, which you'll spend ages trawling through mailing lists full of internal Git information, and the upshot will usually be something non-useful like "don't try to do that then" (convert large repositories with branches intact), or "yeah, should really use Linux and not Windows" (msysGit is 9x slower on bulk operations).
So despite the fact that I have become far more comfortable with Git's occasionally esoteric design choices than I was when I started, the lack of a robust Subversion conversion path for large repositories is a killer. I'm confident that I could be happy in either Git or Mercurial; Mercurial is friendlier on the command line, TortoiseGit is slicker in the GUI, Git's repositories are smaller, Mercurial is easier to extend - they have pros and cons that mostly balance each other out. But crucially Mercurial's Subversion conversion is more robust by a wide margin, and having dug about in its internals a bit I feel more confident in the overall architecture too - all Python, the API is intuitive, it has consistent error reporting and diagnostic behaviour - compared to Git which is very clever, but is more esoteric in structure and built on an association of command-line utils leveraging perl and shell scripting and goodness knows what else (hence why it's not Windows-friendly and needs msys). The behaviour of the two under 'problem' conditions, combined with what they look like under the hood when I go to try to extend them, makes me have considerably more trust in Mercurial than Git, particularly when Windows support is important to me. So right now, Mercurial is my tool of choice.
I still have some more test scenarios to work through, but that's the way things are right now.
. It seemed to keep rolling back to the beginning and starts all over again. I spent a whole day trying to get mozilla code that way (this was before they created the bundles), only managed it later when my connection somehow stayed on just long enough to do an entire clone.
.
I assume that the majority of the size is coming from trunk media file changes. 