BitKeeper vs Subversion

comparison matrix
This is a response to http://www.bitkeeper.com/Comparisons.Subversion.html. BitMover's comparison is biased and inaccurate, and I felt the need to correct a few things. Besides, with the recent news that Linus dropped BitKeeper, it's relevant at the moment.

BitKeeper has always been controversial because of its license. Should we use a tool written by a company who doesn't want to play nicely? Is it an ethical problem that Linux, the flagship of free software, depends on a company who rejects the core philosophies of Open Source? Will BitKeeper ever be free?

BitKeeper can be used without charge for only one reason: to help Linus not burn out. As Larry McVoy said (2): "BK makes it really easy to do what Linus is doing." But there is only one Linus; what about the rest of us? Which tools are best for what we're doing?

My personal opinion is that developers should use Subversion and/or Darcs, depending on project style and general preferences. If you want to use a central repository (cvs-style), use Subversion. If you want decentralized, BitKeeper-style private branches, use Darcs. Or, for really complex projects, SVK offers the best of both worlds.

Anyway, onto the comparison.
Tigris provides a nice set of corrections to part of the BitMover article, but does not include the comparison matrix. Here is what Tigris left out (and some things BitMover left out):

BitKeeper/Subversion Feature Comparison Matrix

Feature BK/Pro Subversion Notes
Open Source license No Yes
  • Why useOpen-Source Software?
Freely usable for any purpose No Yes
  • BK prohibits development of certain types of products, and use by certain types of developers.
Change sets Yes Yes
  • Every change is a reproducible snap shot
  • Aids in debugging and release management
Change sets are atomic Yes Yes
  • Avoids data corruption and synchronization problems.
Partial Checkouts, Subtrees No Yes
  • Allows you to incorporate components from one project into another
Revision Philosophy Patches Snapshots
  • Each approach is well-suited for some tasks and not for others
Graphical Interfaces One: some small but useful GUI tools come with BK Several complete GUIs are available: RapidSVN, TortoiseSVN, QSvn, eSvn, and plugins for many popular editors and IDEs (Eclipse, emacs, etc)
  • Graphical tools help new users learn, and help experienced users use the system more efficiently.
Other interfaces CLI, Web CLI, Web (chora, SVN::Web, ViewCVS (HEAD), mod_svn_view, trac, ViewSVN), WebDAV
  • Web access makes it easy to browse files and revisions.
  • WebDAV lets you mount the repo and use it like a hard drive, allowing you to create a shared "drive" with automatic version control
Dynamic branching Yes Yes; two methods: svk for distributed/private repos, or central branches with "svn cp"
  • Anyone can make their own first-class private branch with BK or SVK.
  • Central branches are easy and cheap with Subversion.
  • Advanced planning for branching is not needed.
"Pro Merge" Technology Yes No
  • Most accurate automerge available (?)
Accurate handling of renames Yes Yes, but support is basic
  • Increased productivity through a well organized source base
Peer to peer architecture Yes Yes (svk)
  • Supports any workflow for enhanced quality control
  • Pyramid architecture introduces bottlenecks at each level, slowing the adoption of patches.
Complete local history Yes svn: no
svk: Yes
  • Your developers can keep working even when your server or network doesn't
  • Inherent reliability through replication
  • Can require lots of extra space on each workstation.
True parallel development ? ?
  • What does this even mean?
Multi-site development Yes Yes (svk)
  • Provides 100% functionality and productivity at all distributed sites
Mobile/Off-network functionality Yes svk: Yes
svn: No, some commands require network access
  • Increased development productivity by allowing your developers to work while travelling, while at remote locations, while at customer sites, or without a network
Pre-event triggers Yes Yes
  • Ability to qualify events prior to changes which enhances compliance to your development policies
Post-event triggers Yes Yes
  • Supports notification of events and automated secondary operations which provides easier process management
Replicated repositories Yes Yes
  • Provides enhanced reliability along with the ability to perform transparent, automatic backups
Automatic integrity checks Yes Yes
  • Detects corruptions indicating potential hardware and software problems saving time and money associated with unplanned downtime
Accurate recording of all history No, only "pushed" changes are recorded Yes, all changes are forever recorded as a series of fixed snapshots
  • Accountability: Easy to find Who did What When
  • Provides a complete picture of your parallel development
  • SVK shares the same history problems as BK.
Minimal Administration Yes Yes
  • Head count can be used for development rather than taking care of the SCM system
Minimal hardware requirements Yes Yes
  • No need to purchase additional hardware
  • No requirement for large, expensive server
Easy conversion from CVS Mostly Yes
  • BK takes a while for CVS users to learn.
  • Most CVS users can use SVN in less than 5 minutes, because the basic workflow and commands are identical.
Marketed truthfully No Yes (?)
  • BitMover's Subversion comparison contains false information and FUD.
Last modified: April 11, 2005 @ 2:03 MDT
Copyright (C) 1996-2017 Selene Scriven