4 ms·
Company moving off of SVN: Hg or Git?
Anonymous account here as I don't want to single out where I work.
I recently joined a 1,000+ employee company and, to my surprise, I discovered they still used Subversion. When I brought this up with my manager I was surprised yet again by the reply: "yeah, we're supposed to move to Mercurial soon".
I don't yet know why or how the decision was made to pick Hg over Git. It reflects a trend I've seen: I believe conventional wisdom has caught up with the benefits of DVCS's. When it comes to choosing one, Mercurial often wins out over Git. Why? The 2 most common reasons I hear are: windows support and simplicity. I believe the Windows issue is now a red herring - Git works fine on windows. So it must come down to the UI: Git is simply more complicated for most folks to use/master. As a result I believe corporate management often pick Hg more often than the open source community does.
What does the HN community think? It seems like the web has anointed a clear winner (Git). Meanwhile I'm bummed because I prefer Git and I feel it reflects poorly on our engineering team. Tools and tech stacks reveals a lot of a engineering team.
If it were up to me I'd advocate moving to Git and buying a license for Github:fi. Somewhat pricey, but very awesome.
Part of me is now hoping they stay on subversion so I can at least use git-svn and manage my code with git.
What are your experiences and thoughts?
- ibejoeb 16y agoWhy were you surprised? 1,000+ person organization on subversion is non-trivial. Is there a compelling reason to move? Do you really need the D in DVCS if you're not really distributed? But to address your question: my experience moving from Subversion to a DVCS for an organization that's sizable enough to be similar is that Mercurial provides a much shorter path to being basically operational, but that's not saying much. I don't think the web has decided that Git is the clear winner. You're probably onto something about your engineering team, though. In an org of that size, it's quite likely that the complexity of DVCS will be out o grasp of quite a number of them, so you should definitely be sure that the switch won't totally undermine your operation. Also consider the training. Even if hg syntax is similar svn, it's a fundamentally different thing. If you're really using DVCS for all it's worth, you're probably not going to be on premises with every engineer to facilitate training, so you'll either be flying all over to help them or they're going to need to be able to do it themselves. If you're not absolutely committed, don't move. If you are committed to switch, you can piggyback on Subversion knowledge to get to an okay place with Mercurial. Git certainly won't make it simpler, but it almost doesn't even matter, so if you prefer it and you're leading, you might as well go with your preference.
- bigstartupdude 16y agoThanks for your response. > Do you really need the D in DVCS if you're not really distributed? What do you mean? I use a DVCS even for my personal projects. Git is so fast at creating a switching branches that I rarely edit on the trunk: I create a branch for every feature/bug and integrate it in when I'm ready. Right now our org encourages devs to work off of trunk simply because creating (and reintegrating) branches can take a few minutes - which isn't a show stopper, but not a lot of fun either. > the complexity of DVCS will be out of grasp... Yep, I know. Part of me thinks "wtf - we're a top-notch company - everyone should be smart enough to pick it up". That's a big part of why I'm asking. What does Facebook or Google use internally? Surely they don't pander to the lowest common denominator?
- RiderOfGiraffes 16y agoI recently asked a very similar question and I think the answers are relevant: http://news.ycombinator.com/item?id=2138718 http://news.ycombinator.com/item?id=2138718 Quoting from one of the comments there: > Hg, overall, seems a bit more user friendly for > doing the run-of-the-mill things such as branching, > merging, fetching code, delivering patches, etc. I > find it more pleasant to use without knowing much > about the internals. This makes it also easier to > explain to people that used SVN etc. > Git has a lot of 'magical command line switches', > and (at least used to be) documented qutie sparsely. > So you'll probably query google on how to get out of > seemingly simple situations. On the other hand, Git > allows a guru to do a lot of stuff such as re-ordering > history to make nicer patches. Once you master how > things work, these can be very useful. (from http://news.ycombinator.com/item?id=2138881 http://news.ycombinator.com/item?id=2138881)