{"id":62,"date":"2007-01-28T05:58:29","date_gmt":"2007-01-28T13:58:29","guid":{"rendered":"http:\/\/jaredrobinson.com\/blog\/?p=62"},"modified":"2007-01-28T05:58:29","modified_gmt":"2007-01-28T13:58:29","slug":"whats-happening-with-version-control-systems","status":"publish","type":"post","link":"https:\/\/jaredrobinson.com\/blog\/whats-happening-with-version-control-systems\/","title":{"rendered":"What’s happening with Version Control Systems?"},"content":{"rendered":"

\nI’ve long had an interest in version control systems<\/a> (VCS), also known
\nas source code management (SCM) systems — beginning with RCS, SCCS and
\nCVS. CVS<\/a>
\nwas already showing it’s age when I started using it in 1998. When the
\ncompany I worked for, Axent, was acquired by Symantec in 2000, we switched to
\nusing Perforce<\/a>. At first, I
\nthought Perforce was a step backwards from CVS. After using it heavily
\nfor a few months, it was clear that CVS and WinCVS<\/a>
\ndidn’t come close to the ease-of-use and features of Perforce and
\np4win. CVS was dreadfully slow compared to Perforce, which was
\nlightning fast (and still is).<\/p>\n

\nPerforce encourages third-party developers to develop add-ons for use
\nwith their software, which is almost as good as what you get with an
\nactive open-source project. Alough Perforce is proprietary, it’s about as open
\nas I’ve ever seen a commercial project. It runs on many platforms, has
\nconversion scripts to migrate CVS repositories to Perforce, etc. It’s not
\ncheap, unless you’re working on an open-source project, in which case, you can
\nget free licenses to use it.<\/p>\n

\nAt some point, I heard about the Subversion<\/a>
\nproject, which aimed to correct many of the deficiencies of CVS. Those
\nwere the pre-1.0 days, and it was interesting to watch the development
\nof Subversion.<\/p>\n

\nAbout the same time, Bitkeeper<\/a> was in the news. It was different than CVS, Subversion and Perforce because it was a distributed<\/span>
\nversion control system. The idea appealed to me because of the
\nidea that a developer could have version control for his\/her private
\nchanges without having to check-in to the main repository until they
\nwere ready. At that time, there weren’t any mature open-source
\ndistributed version control systems to investigate.<\/p>\n

\nI switched jobs late in 2004, and my new company was using Subversion.
\nOverall, I have been very pleased with Subversion in day-to-day use.
\nIt’s much better than CVS. We had some reliability problems with the
\nSubversion server. It was running on Windows with the BDB database
\nstorage back-end. When it was switched to a Linux server with the FSFS
\nback-end, it became much more reliable. My team uses TortiseSVN<\/a> — an
\nexcellent user interface that integrates with Windows Explorer.<\/p>\n

\nI’ve periodically kept tabs on version control systems. Many open-source variants have sprung up over the last few years: Mercurial<\/a>, Bazaar-NG<\/a>, Git<\/a>\/Cogito<\/a>, Darcs<\/a>, SVK<\/a>, Arch<\/a> and Monotone<\/a>.
\nLately though, I haven’t seen any great reviews on which ones are the
\nmost mature, or what the pros and cons are of each. So, I’ve done some
\ngoogle research to figure it out, focusing primarily on the distributed
\nvariants.<\/p>\n

\nThe conclusion I’ve come to is that the developers of each version
\ncontrol system are learning from the developers of the other version
\ncontrol systems, and each project is improving. The Subversion developers are
\nlearning from the distributed version control developers. Recently, there was
\nan SVN developer summit<\/a> and they tried out Mercurial, which tells me that there’s merit to the distributed approach.<\/p>\n

\nIf you’re already using a modern version control system, the cost to
\nswitch may outweight the benefit. Organizations seem to be able to
\ncope with legacy tools like Visual SourceSafe and CVS, although better tools
\ncan make developer’s lives easier.<\/p>\n

\nHere’s my own highly subjective comparison table. I’ve marked, in red, some of the things
\nI think are noteworthy. I focused my efforts on the compeitors that
\nseem to have garnered the most community adoption. I’ve included one
\ncommercial system, Perforce. Each item is rated on a scale of 1 to 10, 10 being the best. (Update: There’s a better table than mine at http:\/\/bazaar-vcs.org\/RcsComparisons<\/a> and various comparisons at Wikipedia<\/a>)<\/p>\n

\nComparison of Source Code Management systems<\/big><\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
January 31, 2007\n <\/td>\nSubversion<\/b><\/a><\/td>\nSVK<\/b><\/a><\/td>\nGit<\/a>\/Cogito<\/a><\/b><\/td>\nMercurial<\/b><\/a><\/td>\nBazaar-NG<\/b><\/a><\/td>\nDarcs<\/b><\/a><\/td>\nPerforce<\/b><\/a><\/td>\nNotes<\/b><\/td>\n<\/tr>\n
Command-line name<\/td>\nsvn<\/td>\nsvk<\/td>\ngit \/ cg<\/td>\nhg<\/td>\nbzr<\/td>\ndarcs<\/td>\np4<\/td>\n<\/td>\n<\/tr>\n
Cross-Platform<\/b><\/font><\/td>\n10<\/font><\/td>\n9<\/font><\/td>\n6<\/span><\/td>\n10<\/font><\/td>\n10<\/font><\/td>\n9<\/font><\/td>\n10<\/font><\/td>\nWindows, Linux, Mac, Solaris, etc.<\/td>\n<\/tr>\n
Maturity<\/b><\/td>\n9<\/td>\n6<\/td>\n8<\/td>\n7<\/td>\n5<\/td>\n8<\/td>\n10<\/td>\nMaturity based on lifetime, and project flux in code<\/td>\n<\/tr>\n
Maturity: GUI<\/b><\/td>\n9<\/font><\/td>\n0<\/td>\n5<\/td>\n4<\/td>\n3<\/td>\n1<\/td>\n10<\/td>\n<\/td>\n<\/tr>\n
Disconnected\/offline operation<\/b><\/font><\/td>\n2<\/td>\n10<\/td>\n10<\/font><\/td>\n10<\/font><\/td>\n10<\/font><\/td>\n10<\/font><\/td>\n0<\/td>\nDisconnected 1. editing of files, 2. branching, 3. merging, 4. history, etc. Especially handy when there’s no network connectivity, such as when on an airplane.<\/td>\n<\/tr>\n
Community Adoption<\/b><\/font><\/td>\n10<\/font><\/td>\n2<\/td>\n8<\/font><\/td>\n7<\/td>\n5<\/td>\n2<\/td>\n1<\/td>\n<\/td>\n<\/tr>\n
Documentation Quality<\/b><\/td>\n10<\/td>\n7<\/td>\n7<\/td>\n8<\/td>\n6<\/td>\n8<\/td>\n10<\/td>\n<\/td>\n<\/tr>\n
Storage Format: Robustness<\/b><\/td>\n5<\/td>\n5<\/td>\n10<\/font><\/td>\n8<\/td>\n7<\/td>\n5<\/td>\n5<\/td>\nStorage format least susceptible to corruption.<\/td>\n<\/tr>\n
Storage Format: Not in flux<\/b><\/td>\n1<\/td>\n1<\/td>\n10<\/font><\/td>\n8<\/td>\n1<\/td>\n1<\/td>\n?<\/td>\n<\/td>\n<\/tr>\n
(re)Merging support<\/b><\/td>\n0<\/td>\n9<\/font><\/td>\n9<\/font><\/td>\n9<\/font><\/td>\n9<\/font><\/td>\n10<\/font><\/td>\n4<\/td>\nRemembers prior merges, cherry-picking, etc.<\/td>\n<\/tr>\n
Repository Size<\/b><\/td>\n1<\/td>\n9<\/td>\n10<\/td>\n9<\/td>\n?<\/td>\n?<\/td>\n?<\/td>\n<\/td>\n<\/tr>\n
Speed<\/b><\/td>\n2<\/td>\n7<\/font><\/td>\n10<\/font><\/td>\n8<\/font><\/td>\n6<\/td>\n<\/td>\n10<\/font><\/td>\n<\/td>\n<\/tr>\n
Scalability<\/b><\/td>\n9<\/td>\n9<\/td>\n10<\/td>\n9<\/td>\n5<\/td>\n5<\/td>\n9<\/td>\n<\/td>\n<\/tr>\n
Commercial Backing<\/b><\/td>\n10<\/td>\n5<\/td>\n10<\/td>\n10<\/td>\n10<\/td>\n5<\/td>\n10<\/td>\n<\/td>\n<\/tr>\n
Subversion Integration<\/b><\/td>\n10<\/td>\n8<\/td>\n6<\/td>\n5<\/td>\n4<\/td>\n4<\/td>\n?<\/td>\nTailor<\/a> can be used to migrate changes between all systems<\/i>\n <\/td>\n<\/tr>\n
Totals:<\/b><\/td>\n88 <\/b><\/td>\n87 <\/b><\/td>\n119<\/b><\/td>\n112<\/b><\/td>\n81 <\/b><\/td>\n68 <\/b><\/td>\n79 <\/b><\/td>\n <\/b><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\nIf I were to pick a VCS system today, it would probably be Git, followed by Mercurial. What follows are my unpolished notes and ideas.\n<\/p>\n

\nGit\/Cogito<\/span><\/p>\n

\nGit is very scalable, and is
\nthe fastest<\/span>
\nopen-source version control system available. Git has a wide community
\nof professional engineers supporting it, and it has a bright
\nfuture. There are graphical user interfaces available for Git such as
\ngitk<\/a> and qgit<\/a>, although none of them are as mature as the user interfaces available for Subversion. Cogito<\/a> is the easy-to-use command-line wrapper around git. See also the Cogito Wiki<\/a>.
\nAccording to Keith Packard of xorg fame, Git has the most
\nrobust\/reliable repository storage format<\/a>. Advantages of git and all distributed VCSes include 1. offline repository access, 2.
\nprivate branches, 3. distributed backups including change history.<\/p>\n

\nFor those wishing to use Git\/Cogito on Windows, use Cygwin<\/a> and select the git and\/or cogito packages and read the information at http:\/\/git.or.cz\/gitwiki\/WindowsInstall<\/a>. For those organizations wishing for excellent Windows-Explorer integration, use git-cvsserver<\/a> in combination with TortiseCVS.<\/a><\/p>\n

\nTo install git and cogito on Fedora, run the following as root:
\n  yum install git cogito qgit<\/code><\/p>\n

\nI’ve reluctantly decided that Git isn’t as mature as Subversion, which
\nshouldn’t be surprising because Subversion has been around for longer. Git
\nisn’t the right fit for all projects. Git was designed for monolithic<\/em> code
\nbases, not for modular<\/em> code bases, although work is in progress to allow it to
\nsupport sub projects<\/a>
\n(similar to svn:externals<\/a>).
\n“Such flexibility is an implicit feature of centralized SCMs, but is much more
\ndifficult to implement in a distributed system like git. As a result, git
\ncurrently lacks built-in subproject support, although gitweb does have a notion
\nof subprojects.”\n<\/p>\n

\nThere’s a document that describes Common Mistakes made when using Git<\/a>. Unfortunately, most of it isn’t written yet — there’s only a loose outline.<\/p>\n

\nTutorials:<\/p>\n