Comparisons

We've gone through the more popular SCM systems available today and contrasted them with BitKeeper based on our research and feedback from customers who have used both BitKeeper and one or more of the other systems.

If your favorite system isn't listed, let us know and we'll try and add it.

FEATURE	OTHER SCM	BITKEEPER	BENEFIT
Inherently reliable through replication	No	Yes	No downtime. Your developers spend their time developing your product, instead of waiting on a server rebuild.
File/directory renaming	Rarely	Yes	Increased productivity through well organized source base.
BK/ProMerge (tm)	No	Yes	Accurately reduces the number of merge conflicts, eases resolution of remaining conflicts.
True distributed system	No	Yes	100% productivity at geographically distributed sites at all times, with no loss of functionality or performance. Any user may modify any file on any branch at any time, without restriction.
Powerful GUI tools	No	Yes	Dramatically simplifies debugging, easier merges, improves check in comments.
All changes are reproducible snapshots	No	Yes	Easily remove bad changes, aids in debugging, aids in release management.
Web project tracking	Maybe	Yes	Allows management to track projects and estimate release dates.
Optimal performance for all users, local or remote	No	Yes	Database replication means all developers, local or remote, get optimal performance. BitKeeper works well even over low bandwidth, high latency links such as modem or satellite links.
Disconnected (laptop)	No	Yes	Productivity while traveling, at home, at remote offices with partial/slow network connectivity.
Peer-to-peer architecture	No	Yes	Work may flow in any direction, including "sideways" between two developers without involving a "master" copy.
Painless upgrades	No	Yes	Upgrading server does not affect developers.
Cross platform GUI	Rarely	Yes	Increased productivity, no retraining.
Scripting	Maybe	Yes	Easily customizable to your environment.
Customizable reports	Rarely	Yes	Accountability and status to/for managers.
Automatic integrity checks	No	Yes	Catches hardware/software problems promptly, while replicas are still available.
Active roadmap	Maybe	Yes	BitKeeper is actively developed by a world class development team. Follow on products for bug tracking, sales tracking, project management, project hosting are all actively being developed.

CVS

• CVS is in widespread use, mainly because it is free. It works fairly well for simple tasks, it's better than just using RCS. It has problems as the development effort gets large.
• CVS has a single repository model. Each work area is clear text only which means no revision control in the work area during development.
• No staging areas to protect the main source tree. With CVS, everyone checks into the same place and if someone breaks the tree, it's broken for everyone. With BitKeeper, you can put a staging area between each group of developers and the main integration tree, thereby protecting the main tree from bad checkins. Anyone who has lived through a change that broke the build can see the value of staging areas.
• CVS loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, CVS loses N-1 events.
• Merging in CVS is primitive at best.
• Branch management in CVS is a nightmare.
• CVS has no change sets, i.e., no atomic commits of changes which span files.
• CVS has no integrity checker which means files can be silently corrupted and you will never know until you try and roll backwards.
• CVS has no rename support.
• CVS was based on RCS and still has RCS' limitations.
• On the plus side, CVS is free, works well enough for some development projects, and CVS repositories are easily converted to BitKeeper. If you can't afford a good source management product, use CVS, we'll help you migrate off of it when the time comes.

Subversion

Subversion is a new system which is supposed to replace CVS. Unfortunately, Subversion shares many of CVS' problems and introduced some of its own problems:

• Subversion uses a binary file format for your revision control data and metadata and if that format gets corrupted you are out of luck, your whole team comes to a halt.
• Subversion has a single repository model, i.e., client/server. Each work area is clear text only which means no revision control in the work area during development.
• No staging areas to protect the main source tree. With Subversion, everyone checks into the same place and if someone breaks the tree, it's broken for everyone. With BitKeeper, you can put a staging area between each group of developers and the main integration tree, thereby protecting the main tree from bad checkins. Anyone who has lived through a change that broke the build can see the value of staging areas.
• Subversion loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, Subversion loses N-1 events.
• Merging in Subversion is no better than CVS, i.e., primitive at best.
• Branch management in Subversion is a nightmare.
• Subversion has no integrity checker which means files can be silently corrupted and you will never know until you try and roll backwards.
• Subversion has only weak rename support, that's something that is inherent in all centralized systems.

Perforce

Perforce is commercial tool similar in design to CVS. For small development efforts, it works as well as CVS for a lot of things and better for some others.

• Perforce is similar to CVS and shares some of the same problems, such as a central repository, only one repository, and no per work area history. It does have weak rename support and groups changes, but does not have true changeset support.
• Perforce does not provide per file commentary; only per change set commentary. It's a minor point, but sometimes you want that extra information, it helps the debugging process.
• Perforce loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, Perforce loses N-1 events.
• Perforce chooses speed over accuracy. The system remembers the set of files you have locked and prompts about only those files at checkin time. If you have added any files to your workspace, Perforce ignores those.
• Merging in Perforce is primitive at best.
• Perforce maintains state in a database next to the RCS files. In order for this state to be consistent with the RCS files, you must access the RCS files only through the Perforce daemon. The database is a single point of failure; if it gets corrupted, your source management system does not work. The real problem is that when the database gets corrupted, there is a high chance that you need Perforce to straighten it out.
• The Perforce daemon is a bottleneck. Long running operations lock out all other users. This isn't a problem with small repositories, only with large ones. Scalability becomes a problem.
• The database can use a dramatic amount of disk space.
• Upgrades are not reversible and lock the system for hours.
• Perforce has an integrity checker but it is only run if you ask for it, i.e., the default is to just hope that the data is correct. That means your data can get silently corrupted and you will never know until you try and roll backwards.
• The main issues are scaling, reliability, and accuracy. Perforce is marketed as the fast SCM system but it chooses speed over correctness. All systems with centralized repository have scaling problems, that is inherent in the design. Perforce has made an effort to make their database reliable, but even so, it can get corrupted, frequently through no fault on Perforce's part, i.e. a disk goes bad. When that happens, your development stops.
• Perforce uses the RCS file format with all of the problems that entails.

Perforce is a trademark of Perforce Software, Inc.

ClearCase

• ClearCase is integrated into the operating system as a file system. Experience has shown that this can be problematic each time the operating system is upgraded.
• ClearCase is slow for many common operations when compared against a local filesystem.
• ClearCase is quite resource hungry - it is not uncommon to spend as much as $300,000 for a large SMP server to serve up 20 developers. A $2000 PC can (and does) do the same job with BitKeeper.
• ClearCase is expensive in more ways than just seat costs. The hardware and administrative costs to run a ClearCase server can dwarf the seat costs. It is common to allocate a full time administrator to manage the ClearCase server and software.
• The ClearCase multisite feature is an attempt to decentralize a centralized system and it doesn't work as well as a truly distributed system. The basic idea is that each site gets a branch, that branch is writable by that site only, the other site's branches are read only. BitKeeper has no such restrictions, all sites can work on the same branch at the same time.
• BitKeeper improves debugging efficiency of developers through changesets; it is trivial to go from a line of code to the changeset which introduced that line.
• Development managers can perform better code reviews with BitKeeper.
• Management can easily track project progress through the BK/Web interface.
• BitKeeper is easier for administrative staff to learn and support.
• BitKeeper is more reliable - all repositories are database replicas.
• BitKeeper allows full-development efficiency at remote sites, with no loss of performance or functionality.
• BitKeeper saves money through dramatically reduced hardware requirements.
• BitKeeper is fast - maintains single user performance levels.
• Summary: ClearCase is the mature market leader, but has a centralized architecture which implies many limitations. BitKeeper has a proven distributed, replicated architecture without those same limitations. Total cost of ownership with ClearCase can easily exceed 5 times that of BitKeeper for the same development effort.

ClearCase is a trademark of Rational Software Corporation.

Sun Teamware

• BitKeeper has changesets, Teamware does not. Changesets guarantee that the tree is reproducible, Teamware can not.
• BitKeeper rollback always works, Teamware rollback rarely works.
• BitKeeper can import/export diff-style patches for the entire tree.
• Many of the BitKeeper graphical tools are substantially better than the ones in TeamWare. The BitKeeper file merge is easier to use, works better, and merges faster. Citool is a graphical checkin tool which reduces human errors (missed files) and produces better checkin comments. There are no analogous tools in TeamWare for citool, difftool, renametool, csettool or helptool.
• All of your TeamWare knowledge transfers over -- conceptually, BitKeeper is similar to TeamWare.
• BitKeeper has better event triggers (more fine grained control).
• BitKeeper has much better rename support for files and directories. Renames in Teamware are not an undo-able event.
• BitKeeper uses much less bandwidth when synchronizing with remote repositories over the WAN or dial-up (null updates take less than a second over an SSH connection regardless of repository size).
• BitKeeper has compressed repositories. In one import of 19 years of Teamware managed data the size of the resulting repository was slightly more than 2 times the size of the checked out files. In other words, BitKeeper was able to store 19 years of changes in the same space as the flat, checked out files. No other SCM system comes close.

VSS

Visual Source Safe is a low end commercial tool that integrates with the Visual Studio environment.

• Visual Source Safe has a single repository model. Each work area is clear text only which means no revision control in the work area during development. If the VSS repository goes down for any reason your developers are down.
• VSS does not have changesets.
• VSS loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, VSS loses N-1 events.
• Merging in VSS is primitive at best.
• Branching can be a nightmare.
• Integrity checks are not done automatically with VSS. Data corruptions are a common occurrence with VSS and manual checks are recommended frequently.
• VSS does not have replicated repositories, this means no work flow support, no disconnected operations, etc.

RCS

RCS is not an SCM system, it is a file based system. However, many commercial systems use the inferior RCS file format so we felt it was worth having RCS in the comparisons.

• RCS has no checksum. RCS files can get silently corrupted and RCS will never notice unless you happen to ask for a delta that is part of the corrupted area of the file. Because of the way RCS is designed, it is unlikely to ever notice a problem until too late. BitKeeper checksums the entire file as well as each delta and verifies the checksum on each operation.
• Lack of compression. BitKeeper supports compressed contents. The administrative part of the file (typically less than 5% of the file size) is uncompressed; the rest may be compressed to gain back disk space and use less disk/network bandwidth.
• RCS has no rename support. BitKeeper records pathnames with the deltas so that files may be moved around easily without losing track of where they once lived.