Monday, February 21, 2011

A version of change

You know how you know you need to do something... you want to do that thing... you NEED to do that thing eventually... but the law or inertia just works against you? I know you've been there. Well, our IT development shop has been there for years. We've been rocking CVS as our version control system (VCS) for years (on the same server), and it's actually been OK. But some of us have seen the day of change coming for a long time now... or at least I have. The CVS is now past its prime and with new hardware we are poised to replace software as well.

Our shop often works on small projects and our developers have to work with just about every development technology known to man -- often in the same day. We grew up doing Java/Oracle mostly, but find ourselves living in .Net world these days. So Visual Studio integration would be a nice change for folks. Our guys and gals just want to focus on programming and do not want to deal with learning something ELSE new so a lower learning curve will initially seem more beneficial. In this vane, we currently don't  use a distributed VCS model nor we do likely need one (but, maybe there's some benefit here we're not thinking of).

Our projects range from small to medium-large in terms of code, though we often abuse CVS by sticking non-code in it. So, speed is not a HUGE issue, but I'm sure everyone would appreciate a speed up. Everyone knows we need to improve our tagging/branching/merging, so a VCS that helps us do this easily/safely and doesn't get in our way is desirable. Our company is pretty much Microsoft across the infrastructure board, but we rock the occasional Linux server. Our local backup is being augmented by the enterprise over-the-wire Microsoft solution that sends daily changes back to the HQ. So, we'll likely shift to a VCS that happily (natively?) runs on Windows.

So, tonight I've done more reading (been thinking about this for years) and determining the next CVS lilly pad is going to me more challenging than ever. It seems that all of the leading contenders have matured greatly.

Candidate 1 - SVN

Subversion seems to be adequate. We don't need distributed VCS and there are a lot of tools out there for it. Some of the disk and speed issues seem to have improved over the years, but likely are still issues. SVN likely offers the lowest learning curve for folks, but we also don't gain as much from it. Oh, and the migration from CVS seems to be mature. There do seem to be Windows native installations possible.

Candidate 2 - Hg
 Distributed VCS, decent documentation and rich tool sets. Learning curve will be steeper than SVN. Performance should be better than SVN, but not as fast as Git. Its python based and seems to be Windows native. I need to read more about CVS migration and how simple you can make using it (can you do central version management if you want to?). A little more reading from somewhat older links indicates that we will have a hard time following a centralized model with mercurial (though that may be a good thing).

The Rest - Git and Bzr
Git and Bazaar are both annoyingly compelling and mature. I'm going to ignore them for now however as I can't see anything that they do differently than what Hg does -reletive to our need.

Bzr seems like it is very flexible, but the toolset seems a little behind Git and Hg. Plus, it still seems to support Linux better than Windows given the competition developers seem to focus more on Hg and oddly Git for tool/integration outside of Linux.

Git is powerful and has some huge momentum. But the learning curve sounds like it's steepest here. That said, the existing toolset and mindshare to support them, particularly on Windows, seems to be present and not losing steam.

So, we don't have a decision yet, but I've provided some links below for more information.


Bazaar (bzr)

Subversion (svn)


Mercurial (hg)
Git (Git)

Comparisons

Instructions, Tutorials, Stories



Posted by John Z at 9:41 AM

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)