See How WANdisco Compares to:

Central CVS Server | Clear Case MultiSite | Perforce | CVSup | CVSProxy | Rsync | Central Subversion Server | Svnsync | SVNreplicate | SVNbackup | Pushmi | SVK | Bitkeeper | Visual Source Safe

Central CVS Server

• Many organizations using CVS simply go with a single master CVS server that remote sites access using VPN or a secure protocol such as SSH. While everyone is technically working from the same copy of CVS, there are a number of drawbacks to this approach.
• The central CVS server can become a single point of failure. This can be a significant issue for remote sites that are separated by large time zone differences when the master server goes down for any length of time, as it might take the administrator at the master server site until the next day (from the remote site's perspective) to get back up and running. Even if the central server is up, any loss of network connectivity will mean that the remote locations will be unable to commit changes.
• Every remote CVS request entails a WAN penalty. For example, a checkout of 500MB by a developer in India from a repository based in the US can take several hours. Each developer in India will end up doing independent updates that will bring the same revisions from the master server in the US multiple times. This wastes a significant amount of developer time, as well as network bandwidth.
• If a long running commit/import operation is interrupted due to a transient WAN outage, the developer has to restart the commit again from the beginning. WANdisco addresses this by providing a resilient data channel that allows remote transfers to automatically resume from where they left off. In addition, CVS uses a very chatty protocol. This compounds network latencies and forces many companies to absorb the cost of additional E-1 lines from India. WANdisco makes this unnecessary. On this basis alone, WANdisco easily pays for itself.
• Finally, a single CVS server will typically be hard to scale vertically as the number of CVS users grows. An offsite user will end up using more CPU/memory as the CVS server forked process lingers on much longer because of a slow network. This typically requires more expensive, larger machines. Many organizations rely on large dedicated SMP boxes to address scalability. In contrast, WANdisco's distributed architecture allows organizations to scale horizontally using inexpensive Linux boxes.

Back to Top

IBM ClearCase MultiSite

• The master ClearCase MultiSite repository can become a single point of failure. This can be a significant issue for remote sites that are separated by large time zone differences when the master server goes down for any length of time, as it might take the administrator at the master server site until the next day (from the remote site's perspective) to get back up and running. Even if the master server is up, any loss of network connectivity will mean that the remote locations will be unable to commit changes.
• Like many other multi-site solutions that lack WANdisco's active-active replication capabilities, ClearCase MultiSite compensates with source code branching and manual file merging. To prevent developers at one site from clobbering modules that developers at another site are working on, each development site is assigned a code branch. That code branch is writable by that development site only, and read only to the other sites. This effectively forces development work to be partitioned based on time zones, rather than where talent is located. Although branch mastership (ownership) can be exchanged between sites the process can be cumbersome and make collaboration between distributed teams difficult.
• When work from multiple development sites is integrated to complete a build, administrators must manually merge the files from each development site's code branches.
• ClearCase's architecture makes it complex to implement and administer. It is not uncommon for organizations to allocate a full time administrator to manage the ClearCase server and software at each development site. Synchronization is not automatic with each write operation and must be done on a scheduled basis with administrator monitoring. ClearCase provides no acknowledgement back to the sender to indicate that the updates have been transferred successfully. This means that ClearCase administrators at each site (sender and receiver) must manually confirm that files have been transferred completely. When work from multiple development sites is integrated to complete a build, administrators must manually merge the files from each development site's code branches.
• Recovery from network or server failures requires significant manual intervention by an administrator. ClearCase MultiSite does not provide the self healing capabilities offered by WANdisco that eliminate the risk of administrator error during disaster recovery.
• Developers and administrators who have been working with other SCMs will face a significant learning curve when they switch to ClearCase.

Back to Top

Perforce

• Perforce provides a central server architecture with a stateless caching proxy (P4P) to enhance WAN performance. P4P stores file revisions only when a client requests them. The performance gain offered by Perforce only comes into play after file revisions are cached.
• The master Perforce server can become a single point of failure. This can be a significant issue for remote sites that are separated by large time zone differences when the master server goes down for any length of time, as it might take the administrator at the master server site until the next day (from the remote site's perspective) to get back up and running. Even if the master server is up, any loss of network connectivity will mean that the remote locations will be unable to commit changes.
• Perforce does allow multiple P4P proxies to be created, but there is no replication capability to keep all of the caches in sync. P4P stores file revisions only when a client requests them. Unless the client asks for a specific version number, the proxy will have to verify with the master server if the revision changed. This can create WAN performance issues and renders P4P ineffective for many commonly used read operations such as full directory update.
• The proxy caches are not garbage collected automatically. Stale revisions have to be cleaned out manually. If manual clean up is not done, P4P can run out of disk space.

Back to Top

CVSup

• CVSup is a one-way file transfer tool that is used after changes have been made in CVS repository files. CVSup is an open source solution based on a "master/slave" configuration that was implemented to allow the FreeBSD community to pull FreeBSD sources on demand from a master server. CVSup can parse RCS files and transfer only files whose versions have changed.
• The master CVS server can become a single point of failure. This can be a significant issue for remote sites that are separated by large time zone differences when the master server goes down for any length of time, as it might take the administrator at the master server site until the next day (from the remote site's perspective) to get back up and running. Even if the master server is up, any loss of network connectivity will mean that the remote locations will be unable to commit changes
• CVSup computes a strong logical checksum for the RCS files that need to be transferred. Before the checksum can be computed, each RCS file to be transferred must be canonicalized to remove white spaces. This creates a tremendous load on the CPU as well as the disk i/o subsystem and network. Because of this, most administrators do infrequent updates, typically once per day. As a result, the slave CVS repositories are always out of sync with the master. Since CVSup transfers are only done periodically, fetch from master server is still the norm before a CVS user commits a change set. This is done to avoid up-to-date check failures at the remote CVS server site. This negates any benefits that should be derived from having a local read-only slave, as developers need to update to the master first.
• In addition, the operational model for CVS clients using CVSup is somewhat complex and error prone. Reads and writes must be handled by manually switching CVSROOT in order to connect with different CVS servers. Many developers find that this causes inadvertent source code merging and checkin snafus that lead to build breakages. This negatively impacts both developer and CVS administrator productivity.

Back to Top

CVSproxy

• CVSProxy is an enhancement added to the CVS code base that addresses the issue of forcing developers to switch CVSROOT between read-only slave replicas and the master repository. CVSProxy transparently redirects write commands to the master node, while reads are directed to the local read-only repository. This overcomes problems that result from inadvertent source code merging and check-in snafus that lead to build breakages when developers have to manually change CVSROOT.
• CVSproxy is currently supported with the :ext protocol, and not the more widely used :pserver protocol.
• CVSProxy does nothing to replicate changes to slave CVS repositories. Some organizations set up CVS scripting hooks such as loginfo, postadmin, posttag and postwatch on the primary or "master" server to replicate changes to the secondary slaves. The main problem with these approaches is that the clients are blocked until the scripts complete replication of any changes from the master to the slaves.
• As another alternative, many CVS shops often use CVSProxy in conjunction with CVSUp, or rsync to address file transfer to the slave repositories. These solutions in conjunction with CVSProxy can address the client blocking problem described above.
• CVSProxy used with or without CVSUp or rsync does nothing to address the problem of the master CVS repository becoming a single point of failure. This can be a significant issue for remote sites that are separated by large time zone differences when the master server goes down for any length of time, as it might take the administrator at the master server site until the next day (from the remote site's perspective) to get back up and running. Even if the master server is up, any loss of network connectivity will mean that the remote locations will be unable to commit changes.

Back to Top

Rsync

• Rsync is an open source general purpose utility for one-way incremental file transfer. Like CVSup, rsync is based on a "master/slave" configuration that can be used to create "slave" replicas of master repositories.
• Rsync computes strong and weak checksums for each and every file transferred. This creates a tremendous load on the CPU as well as the disk I/O subsystem and network. Because of this, most administrators typically do updates only once per day, so the slave CVS repositories are always out of sync with the master.
• Since Rsync transfers are only done periodically, developers typically perform a fetch from the master server before committing a change set. This is done to avoid up-to-date check failures at the remote CVS server site. This effectively negates any benefits that should be derived from having a local read-only slave, as developers need to update to the master first.
• Rsync suffers from an exploding tag problem. Since rsync doesn't understand the RCS format, it will treat each tagged file as changed and initiate file transfers for each of them. As a result, network bandwidth is consumed for no reason.
• The master CVS repository can become a single point of failure. This can be a significant issue for remote sites that are separated by large time zone differences when the master server goes down for any length of time, as it might take the administrator at the master server site until the next day (from the remote site's perspective) to get back up and running. Even if the master server is up, any loss of network connectivity will mean that the remote locations will be unable to commit changes.
• The operational model for CVS clients using Rsync is complex and error prone. As is the case with CVSup, reads and writes must be handled by manually switching CVSROOT in order to connect with different CVS servers. Many developers find that this causes inadvertent source code merging and checkin snafus that lead to build breakages. This negatively impacts both developer and CVS administrator productivity.

Back to Top

Central Subversion Server

• A central Subversion server, like a central CVS server, can become a single point of failure. This can have a significant impact on remote sites that are separated from the central Subversion server site by large time zone differences, as it can take the administrator at the central server site until the next business day (from the remote site's perspective) to restore access.
• Every remote request entails a WAN penalty. Although Subversion is more efficient than CVS when changes to existing source code files are committed, because only the modifications are sent over the network between the client and the Subversion server, when a new file is committed, or an existing file is checked out, the entire file is sent over the WAN.
• With each Subversion commit using the SVN RA protocol (Subversion without Apache) up to six WAN round trips will take place between a remote developer's Subversion client and the master Subversion server. These WAN round trips are required to open the connection, authenticate the user, and write the commit to the master server. In contrast, WANdisco sends the data in a single transaction over the WAN.
• When Subversion is implemented with an Apache Web Server as a front-end, and the WebDAV HTTP protocol is used, the WAN penalty can be significant. This is especially true for commits that consist of large numbers of files. For example, a commit of a directory consisting of 100 files would require 100 separate HTTP PUTs (one for each file) between the remote Subversion client and the central server over the WAN. WANdisco will send the data as a single transaction over the WAN, delivering a significant performance boost.
• If a long-running commit operation is interrupted due to a transient WAN connection failure, the entire commit has to be resubmitted by the developer. In contrast, WANdisco provides a resilient data channel that allows transactions from remote sites to automatically continue from where they left off.

Back to Top

Svnsync

• Svnsync is an asynchronous unidirectional synching tool for Subversion. It is an open source solution based on a master-slave configuration. This means that all checkins must be done to a master Subversion repository. Only the master repository is writeable. The master is then replicated back to each of the read only slaves on a periodic basis. Only one slave at a time can be updated. If there are multiple slave repositories, then multiple svnsync invocations will be required. It may be the case that if the replication to slave one succeeds, the replication to slave two may fail. This can get out of hand from an administrative perspective as the number of slave repositories increases.
• As a result, the read-only slaves that the remote sites do their checkouts from are frequently out of sync with the master. In order to avoid check in failures, remote developers will need to do updates against the master Subversion repository before doing their commits. This can negate the network performance benefits and reduced bandwidth usage that should be derived from having remote repository replicas.
• In contrast, WANdisco's architecture provides bi-directional real-time synchronization capabilities across a set of globally distributed Subversion repositories. With WANdisco, all of the repositories are writeable, and changes made to one are automatically replicated to all of the others in real-time. The repositories are in more of a peer-to-peer relationship than a master-slave one.
• With svnsync, the master Subversion server can become a single point of failure. This can be a significant issue for remote sites that are separated by large time zone differences when the master server goes down for any length of time, as it might take the administrator at the master server site until the next day (from the remote site's perspective) to get back up and running. Even if the master server is up, any loss of network connectivity means that the remote locations will be unable to commit changes.
• There are no self-healing capabilities or support for transactions provided with svnsync as there are with WANdisco. This means that with svnsync, all recovery will be manual if the replication job fails to complete due to network issues or other problems. With WANdisco, support for transactions is provided, and recovery is automatic.

Back to Top

SVNreplicate

SVNreplicate provides a suite of Subversion pre and post-commit hook scripts. SVNreplicate pre-commit hook scripts allow a user at a remote Subversion read-only slave repository site to issue a commit and have that commit redirected to the master by pre-commit hooks installed on the slave. Once the commit is written to the master, post-commit hook scripts installed on the master are triggered to replicate the commit back out to the slave repositories. This is not a true write-anywhere solution. Only the master repository is writeable. In addition, the master is a single point of failure for write transactions. If the master is down, no write transactions can happen. One-copy-equivalence is not guaranteed in the presence of concurrent writes at different sites, as it is with WANdisco. Finally, SVNreplicate doesn't provide any fault-tolerance or self-healing automated disaster recovery capabilities.

Back to Top

SVNbackup

SVNbackup is not a replication solution. This tool is used to create live backups. Since the backups are live, users can still write transactions to the SVN repository while the backup is being taken. The backup is then packaged as a tar-ball that can be loaded onto other Subversion repositories.

Back to Top

Pushmi

Pushmi is a master-slave solution. All write transactions are written to the central master server, and are then copied to the remote slave repositories by cron jobs.

The master server is a single point of failure. If the master is unavailable, no write transactions can take place.

One feature Pushmi offers in the event of update conflicts on the master, is that an immediate replication of the master to the slave is triggered. When the replication of the master is complete, the conflict is reported to the client at the slave repository site, so the client can update his sandbox, resolve the conflict and reattempt the commit on the master.

Back to Top

SVK

SVK uses Subversion's FSFS as a backend, but beyond that, it is its own SCM . SVK does allow multiple repositories to be readable as well as writeable, but there is no real-time enforcement of consistency across the repositories as there is with WANdisco. A commit can succeed on a developer's local repository where there are no conflicts, and fail when it's copied to other sites' repositories due to update conflicts. To avoid conflicts, each development site typically works on a separate branch. The challenge is that conflicts will not be caught until later in the development cycle when the branches are merged to create a build. This can lead to longer QA cycles and unplanned rework when the conflicts are discovered later in the development cycle. In contrast, with WANdisco's real-time active-active replication capability update conflicts and other problems are found and fixed as they occur. As a result, with WANdisco, there's less QA and rework.

Bitkeeper

• Bitkeeper uses a peer-to-peer merge model. With Bitkeeper each developer can merge with developers at various locations in a staging area before merging with the main source code tree. In effect, a hierarchy of repositories can be created, in contrast with CVS, which has a single repository model.
• From a multi-site perspective, if a group of developers in India is working with a group of developers in the US, they would still need to merge with each other's staging repositories. Bitkeeper does not have any capability of replicating the intermediate staging repositories. Changes to India's staging repository are not automatically propagated to the US location.
• If a network outage occurs during a long running commit with the remote central staging area, the developer has to restart the commit from the beginning. In contrast, WANdisco's resilient transfer channel allows remote transfers to pick up from where they left off.

Back to Top

Visual Source Safe

• Visual Source Safe (VSS) is an SCM solution from Microsoft that is implemented as a shared file system. VSS by itself is not a client server based solution like CVS. Instead it is a client filesystem solution. Within a LAN, file sharing is used to access the source code repository. However, this is not feasible for remote sites accessing the repository over a WAN. Microsoft recommends purchasing Source Gear's SourceOffsite to address this problem and effectively turn VSS into a client server solution that can support remote access over a WAN. This effectively brings VSS to the same level as CVS at an additional cost.
• The master VSS database acts as a single point of failure. This can be a significant issue for remote sites that are separated by large time zone differences when the master server goes down for any length of time, as it might take the administrator at the master server site until the next day (from the remote site's perspective) to get back up and running. Even if the master server is up, any loss of network connectivity will mean that the remote locations will mean that they will be unable to commit changes.
• A single VSS server will typically be hard to scale vertically as the number of users grows. An offsite user will end up using more CPU/memory as the cvs server forked process lingers on much longer because of a slow network. This typically requires more expensive, larger machines. Many organizations rely on large dedicated SMP boxes to address scalability. In contrast, WANdisco's distributed architecture allows organizations to scale horizontally using inexpensive Linux boxes.
• If a long running commit or import operation is interrupted due to a loss of WAN connectivity, the developer has to restart the commit from the beginning. There is no capability similar to WANdisco's resilient transfer channel, which allows file transfers to continue from where they left off.

Back to Top