Comparison between Arch, Bazaar, Darcs, Mercurial, Monotone

Back to main page

SCM feature:	Arch [-]	Bazaar [-]	Darcs [-]	Mercurial [-]	Monotone [-]	Add to comparison: +CVS +AccuRev +Aegis +AllChange +BitKeeper +ClearCase +CM+ +CMSynergy +Co-Op +Fortress +Git +LibreSource Synchronizer +OpenCM +Perforce +PureCM +SourceAnywhere +Subversion +Superversion +Surround SCM +svk +Team Foundation Server +Vault +Vesta +Visual SourceSafe
Atomic Commits	Arch: Yes. Commits are atomic.	Bazaar: Yes. Commits are atomic.	Darcs: Yes. Commits are atomic.	Mercurial: Yes.	Monotone: Yes.
Files and Directories Moves or Renames	Arch: Yes. Renames are supported.	Bazaar: Yes. Renames are supported for files and directories.	Darcs: Yes. Renames are supported.	Mercurial: Yes. Renames are supported.	Monotone: Yes. Renames are supported.
Intelligent Merging after Moves or Renames	Arch: Yes. Renames can be merged intelligently.	Bazaar: Yes. Renames are intelligent.	Darcs: Unknown.	Mercurial: Yes, intelligent merging after renames is supported. the Mercurial book says: "If I modify a file, and you rename it to a new name, and then we merge our respective changes, my modifications to the file under its original name will be propagated into the file under its new name. (This is something you might expect to 'simply work,' but not all revision control systems actually do this.)"	Monotone: Yes. Intelligent merging is fully supported.
File and Directory Copies	Arch: No. Copies of files and directory structures are not supported.	Bazaar: No. Copies are not supported.	Darcs: No. Copies of files and directory structures are not supported.	Mercurial: Yes. Copies are supported	Monotone: No. "Tracked" copies are currently not supported, i.e. monotone does not track information about copied files.
Remote Repository Replication	Yes.
Propagating Changes to Parent Repositories	Yes.
Repository Permissions	Arch: Yes. It is possible to define permissions on access to different parts of a remote repository based on the permission systems of the underlying protocol.	Bazaar: Basic access control can be implemented through a contributed hook script. ACL support for the Bazaar server is planned.	Darcs: No.	Mercurial: Yes. It is possible to lock down repositories, subdirectories, or files using hooks.	Monotone: Current monotone has specific read permissions with which you can control the access to certain parts (aka branch patterns) for known user ids, but less specific write permissions. Basically, if a user is allowed to write to a server, they can write everything there pretty much unrestricted.
Changesets' Support	Yes. Changesets are supported.
Tracking Line-wise File History	Arch: Not in the command line client, but ViewARCH, a web-interface for Arch, has it.	Bazaar: Yes. (bzr annotate).	Darcs: Yes. (darcs annotate)	Mercurial: Yes. (hg annotate)	Monotone: Yes. (mtn annotate)
Ability to Work only on One Directory of the Repository	Arch: It is possible to commit only a certain directory. However, one must check out the entire repository as a whole.	Bazaar: For checkouts: No. For checkins: Yes.	Darcs: It is possible to commit only a certain directory. However, one must check out the entire repository as a whole.	Mercurial: It is possible to commit changes only in a subset of the tree. There are plans for partial checkouts.	Monotone: It is possible to commit changes only in a subset of the tree. However, one must extract the entire tree to work on it.
Tracking Uncommited Changes	Arch: Yes, using "tla changes".	Bazaar: Yes, using "bzr diff".	Darcs: Yes, using "darcs whatsnew".	Mercurial: Yes. Using hg diff.	Monotone: Yes. In a similar fashion to CVS.
Per-File Commit Messages	Arch: No.	Bazaar: With respect to pure Bazaar: No. At least one plugin (bzr-gtk) supports it though.	Darcs: No.	Mercurial: No.	Monotone: No. Commit messages are per-changeset.
Documentation	Arch: Medium. There are two online tutorials and a comprehensive online documentation. The command line client also supplies a reference page. However, some of the documentation is out of date or incomplete.	Bazaar: Excellent. Apart from online help in the command line client there exist tutorials, a reference card ("Quick Start Guide"), several full fledged guides and references, and documents on specialized topics, such as migration from other VCS systems and different workflows. The documentation comes in html and plain-text formats. The API of the underlying library is fully documented. In the UI design of the command line client special attention was paid to make it easy to get started with Bazaar.	Darcs: Good. The manual contains a brief tutorial and a solid reference. Every sub-command can print its usage. Because the command-set is small and the model is simple, many users find it easy to get started.	Mercurial: Very good. There is a companion book and a wiki. Every command has integrated help.	Monotone: Good. There's a lot of documentation available in PDF and HTML formats. The client supplies documentation for every command.
Ease of Deployment	Arch: Excellent. An arch service is nothing but a filesystem-space hosted by any of its supported protocols (FTP, SFTP, WebDAV, etc.). The arch client is written in C, and is portable across UNIX systems (and on Win32 only with a UNIX emulation layer).	Bazaar: Very easy. Bazaar has an installer for MS Windows and packages for some major Linux distributions, FreeBSD, and Mac OS X. The dependencies for manual installation are listed on the Bazaar website.	Darcs: Very good. darcs requires few external libraries, however you need the Glasgow Haskell Compiler if you cannot find a binary. To start working, just "darcs init".	Mercurial: Excellent. Binary packages are available for all popular platforms. Building from source requires only Python 2.3 (or later) and a C compiler.	Monotone: Excellent. It is possible to copy or compile the executable to the user's machine, without any configuration or external dependencies.
Command Set	Arch: Many commands are compatible with CVS or BitKeeper. However, there are many other commands for it for different uses. Aliasing of commands is possible so it it may be possible to make it more compatible.	Bazaar: Tries to follow CVS conventions, but deviates where there is a different design.	Darcs: The command set is fairly compact and the core commands are easy to understand. Follows CVS in a few places, but since the model is different most commands are unique.	Mercurial: Tries to follow CVS conventions, but deviates where there is a different design.	Monotone: Tries to follow CVS conventions, but deviates where there is a different design.
Networking Support	Arch: Excellent. Arch can utilize a multitude of protocols for its service, which is nothing but a dumb remote filesystem server. Currently supported protocols include FTP, SFTP, WebDAV (remote file access over HTTP), as well as any remote filesystem protocol (NFS, SMB).	Bazaar: Excellent. Works natively over HTTP (read-only), FTP and SFTP without having Bazaar installed at the remote end. Works over HTTP, SSH and a custom protocol when talking to a remote Bazaar server. Supports RSYNC and WebDAV (experimental) through plugins.	Darcs: Good. Darcs supports getting patches over HTTP, and getting and sending patches over SSH and email.	Mercurial: Excellent. Uses HTTP or ssh. Remote access also works safely without locks over read-only network filesystems.	Monotone: Good. Uses a custom protocol called "netsync".
Portability	Arch: Good. The source is portable across all UNIXes, but requires a UNIX emulation layer on Windows. (need to verify). A service can be hosted on any platform that sports a suitable Internet service.	Bazaar: Works on MS Windows, Linux, Mac OS X, FreeBSD, UNIX, and basically on any system that has a recent Python port. With case-insensitive file systems there are some issues that can be avoided by using a graphical frontend. On MS Windows there is a plugin to support tracking of symlinks even if they are not supported natively by the file system.	Darcs: Very good. Supports many UNIXes, Mac OS X, and Windows, and is written in a portable language.	Mercurial: Excellent. Runs on all platforms supported by Python. Repositories are portable across CPU architectures and endian conventions.	Monotone: Excellent. Executable is portable across all UNIXes and Win32.
Web Interface	Arch: There's ViewARCH, and ArchZoom which are works in progress.	Bazaar: Yes, several: Loggerhead, Webserve, Bzrweb, and Trac.	Darcs: darcs.cgi is included in the distribution.	Mercurial: Yes. The web interface is a bundled component.	Monotone: Yes. ViewMTN and a Trac plug-in.
Availability of Graphical User-Interfaces.	Arch: There are tlator, Octopy, and ArchWay and possibly others under development.	Bazaar: There are several graphical frontends in development, see the Bazaar Plugins page and the Third-party Tools page. Notable are QBzr (Qt) and bzr-gtk (GTK+), which can be considered beta quality. Work is also being done on integrating Bazaar with Windows Explorer, Eclipse, Nautilus, and Meld.	Darcs: None to speak of. (There is a modest graphical interface to a few commands in the distribution, but it is not being developed currently.)	Mercurial: History viewing available with hgit extension; check-in extension (hgct) makes committing easier. Some third-party IDEs and GUI tools (e.g. eric3, meld) have integrated Mercurial support.	Monotone: Yes, there is mtn-browse (which should be considered the "best of breed"), monotone-viz and guitone (whose development was abandoned). There's a complete list of tools available on the Monotone wiki.