Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Differences between revisions 1 and 88 (spanning 87 versions)
Revision 1 as of 2006-02-20 01:22:06
Size: 723
Comment: new comparison chart. Please help!
Revision 88 as of 2006-09-09 10:09:59
Size: 10446
Editor: SoloTurn
Comment: cherry picking is by far better in darcs compared to everything else.
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
/!\ This chart is a rough draft /!\ This page is a user-oriented comparison of different revision control system. For a more technical comparison, see ["RCSChoices"]. See also ["SCMComparisons"] (note: this may be better to move the content of this page here) for a brief presentation of each system and how they compare to Bazaar in particular. The determination on this chart is based upon the core installation and features that are already working in devel.
Line 3: Line 3:
||RCS Name ||Bazaar-NG||Arch||CVS||Subversion||Git||Hg || Monotone||
||Decentralized || Yes || No || No||Yes ||Yes||Yes|| Yes ||
||Simple/No Namespace||Yes ||Yes || No||No || ||No || No ||
||Supports Renames|| Yes ||Yes || No||Yes || ||No?|| ||
||Has Checkouts || Yes || No ||Yes||Yes || || || ||
||Has Snapshots || Yes ||Yes ||Yes||Yes || || || ||
||Supports Merge || Yes ||Yes || No||No ||No?|| ||Yes ||
||Cherrypicks || Yes ||Yes ||Yes||Yes || ||Yes|| ||
||Simple UI || Yes ||No ||No ||No ||No ||Yes||No ||
See also [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of Revision Control Software] on wikipedia for another relatively complete comparison.

/!\ Please discuss changes to this table on the freenode IRC network channel #bzr, or on the mailing list. The terms used in the table have precise meanings, and not all VCS's use the same term in the same way - which means that some translation is needed to fill it in properly.

= Overview =

||RCS Name ||Bazaar ||Arch ||CVS ||Subversion ||SVK ||Git ||Mercurial ||Monotone ||Darcs ||
||Decentralized ||<#88ff88>Yes ||<#88ff88>Yes||<#ff8888>No ||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes||<#88ff88>Yes||
||Disconnected Ops ||<#88ff88>Yes ||<#88ff88>Yes||<#ff8888>No ||<#ffff88>Limited ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes||<#88ff88>Yes||
||Simple Namespace ||<#88ff88>Yes ||<#ff8888>No ||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#ff8888>No ||<#ff8888>No ||<#ff8888>No ||<#88ff88>Yes||
||Supports Renames ||<#88ff88>Yes ||<#88ff88>Yes||<#ff8888>No ||<#ffff88>Somewhat||<#ffff88>Somewhat||<#ffff88>Somewhat||<#ffff88>Somewhat||<#88ff88>Yes||<#88ff88>Yes||
||Needs Repository ||<#88ff88>No ||<#ff8888>Yes||<#ff8888>Yes ||<#ff8888>Yes ||<#ff8888>Yes ||<#88ff88>No ||<#88ff88>No ||<#ff8888>Yes||<#88ff88>No||
||Supports Repository ||<#88ff88>Yes ||<#88ff88>Yes||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#ff8888>No ||<#ff8888>No ||<#88ff88>Yes||<#ffff88>Somewhat ||
||Checkouts ||<#88ff88>Yes ||<#88ff88>Yes||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#dddddd>? ||<#ff8888>No ||<#88ff88>Yes ||<#ff8888>No ||
||Partial Checkouts ||<#ff8888>No ||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#dddddd>No? ||<#ff8888>No ||<#dddddd>? ||<#ff8888>No ||
||Atomic Commit ||<#88ff88>Yes ||<#88ff88>Yes||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes||<#88ff88>Yes ||
||Cheap branching Anywhere ||<#88ff88>Yes ||<#88ff88>Yes||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#ff8888>No ||<#ff8888>No ||<#ff8888>No ||
||[:Merge:Smart Merge] ||<#88ff88>Yes ||<#88ff88>Yes||<#ff8888>No ||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes||<#88ff88>Yes||
||[:CherryPick:Cherrypicks] ||<#ffff88>Somewhat ||<#ffff88>Somewhat||<#ffff88>Somewhat ||<#ffff88>Somewhat ||<#ffff88>Somewhat ||<#ffff88>Somewhat ||<#ffff88>Somewhat ||<#ffff88>Somewhat ||<#88ff88>Yes||
||[:BzrPlugins:Plugins] ||<#88ff88>Yes ||<#ff8888>No ||<#ff8888>No ||<#dddddd>? ||<#ff8888>No ||<#dddddd>? ||<#88ff88>Yes ||<#dddddd>? ||<#ff8888>No ||
||Has Special Server ||<#ff8888>Soon||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||
||Req. Dedicated Server ||<#88ff88>No ||<#88ff88>No ||<#ff8888>Remote||<#ff8888>Remote ||<#ff8888>Remote ||<#88ff88>No ||<#88ff88>No ||<#88ff88>No ||<#88ff88>No ||
||Good Windows support ||<#88ff88>Yes ||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#ffff88>Somewhat||<#ff8888>No ||<#ffff88>Somewhat||<#88ff88>Yes ||<#88ff88>Yes ||
||Fast Local Performance ||<#88ff88>Yes ||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes||<#ff8888>No ||
||Fast Network Performance ||<#ff8888>Soon||<#ff8888>No ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes ||<#88ff88>Yes||<#ff8888>No ||
||Ease of Use ||<#ff8888>No ||<#ff8888>No ||<#ffff88>Somewhat||<#ffff88>Somewhat||<#ffff88>Somewhat||<#dddddd>? ||<#ffff88>Somewhat||<#dddddd>? ||<#88ff88>Yes||

= Details about each feature =

== Decentralized ==
Whether the tool is designed to allow [:Branch:branches] of the same project to be in different remote [:Repository:repositories].

== Simple Namespace ==
The namespace is the way the RCS communicates with the user the various resources for the RCS such as the names for branches and the names for [:Revision:revisions] that are [:Merge:merge]. For example: requiring the user to refer to revisions with base-16 numbers is not considered "simple" in this document.

== Needs Repository / Supports Repository ==
Some revision control systems require that branches be aggregated into [:Repository:repositories]. Bzr can use repositories if you like, for greater space efficiency, convenient publishing and backups.

== Supports Renames ==
If a user can rename a file in the RCS without loosing the RCS history for a file, then renames are considered supported. If the operation resultes in a delete/add (aka "DA pair"), then renames are not considered supported. If the operation results in a copy/delete pair, renames are considered "somewhat" supported. The problem with copy support is that it is hard to define sane merge semantics for copies.

== Has Checkouts ==
A ["Checkout"] is a [:WorkingTree:working tree] that points elsewhere for its RCS data.

== Atomic Commit ==
Does the RCS track which files were associated with which [:Commit:commit].

== Smart Merge ==
Whether the tool is able to know which revisions have to be merged (recording [:Merge:merge] history is a necessary condition for this).

== Cheap Branching Anywhere ==
Some systems only support cheap branching on filesystems that support hard links, but bzr can do cheap branching on any filesystem, and even on FTP servers.

== Cherrypicks ==
Whether the tool allows CherryPick (fine-grained selection of revisions to be merged).

== Plugins ==
Whether the tool is extensible with plugins. Our plugins are on the BzrPlugins page.

== Can use standard fileserver ==
Whether the tool can work with a standard file server (HTTP for read-only operations, ftp/sftp/webdav or others for write operations). This allows you to host a repository on almost any internet service provider without dedicated support.

== Work on partial checkout ==
Whether a user can checkout only a subdirectory of a project and work on it.

== Windows support ==
Whether the Microsoft Windows platform has good native support. Cygwin support is not sufficient.

== Fast Local Performance ==
Whether local operations (commit, "which files have I changed?", diff, switch to different revision, merge) are fast.

== Fast Network Performance ==
Whether network operations (pull, push, clone) are fast.

== Ease of Use ==
The learning curve to do what you want to do. See the following comparisons, evals:
 * [http://www.kdedevelopers.org/node/2024 darcs vs bzr, some hints to tla]
 * [http://opensolaris.org/os/community/tools/scm/ bazaar, git, mercurial (after eliminating Monotone, SVK, TeamWare in a first phase)]
 * [http://darcs.net/DarcsWiki/WorkFlowsVsSubversion darcs vs svn (by darcs people)]
 * [http://www.selenic.com/mercurial/wiki/index.cgi/UserSurvey all of them a little (mercurial user survey)]

= Details of particular VCSes =
In some cases, it is hard to answer 'yes' or 'no' to a particular question.

== Bazaar ==
The current implementation of Bazaar has somewhat mediocre network performance for propagating changes. The current knit format is much better about this than the old weave format. 0.9 has improved as well (see ["Performance/0.9"]), and a ["SmartServer"] is planned which will make network operations ''much'' faster.

== Mercurial ==
Mercurial does not support renames, representing them as copy+delete instead. Its merge doesn't handle renames (support is pending). Other operations such as diff and log also don't follow renames. Since it does not track directories, directory renames are hard for it to represent and remember.

Mercurial supports something called a "repository", but it's not what we mean by repositories: a collection of persistent branches and their revisions. In Mercurial repositories, branches are not persistent: when a merge is committed, the two branches become one.

Mercurial's namespace is complicated because its "named branches" do not have unique urls-- instead, they are a combination of repository URL and a tag name.

The recommended method of branching involves creating a new repository, which is expensive when hardlinks are not available.

== Git ==
Git does not store renames. However, features like merge can make pretty good guesses about renames.
Git does not work on native Windows, but does work (slowly) on Cygwin.

== Subversion ==
Subversion does not support decentralized operation, but svk is a decentralized VCS implemented on top of svn. Subversion can also do some things (like comparisons of the working directory against the checked out version) without a connection to the server, but for anything that actually affects the repository (like a checkin), Subversion needs to be able to talk to the server.
Subversion records renames as copy + delete. (See their [http://subversion.tigris.org/issues/show_bug.cgi?id=898 true rename support] bug)

== SVK ==
SVK achieves distribution by mirroring parts of remote subversion repositories into a local one. It has to be set up explicitely and only pulls over changesets on selected branches. That works well for setups with central repository or a simple star topology, but more ad-hoc topologies get hard to manage and may cause situations where merge does not work because the most recent common ancestor is not available.
SVK's rename support is limited by what Subversion provides and only works as well as Subversion one's does.

This page is a user-oriented comparison of different revision control system. For a more technical comparison, see ["RCSChoices"]. See also ["SCMComparisons"] (note: this may be better to move the content of this page here) for a brief presentation of each system and how they compare to Bazaar in particular. The determination on this chart is based upon the core installation and features that are already working in devel.

See also [http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Comparison of Revision Control Software] on wikipedia for another relatively complete comparison.

Please discuss changes to this table on the freenode IRC network channel #bzr, or on the mailing list. The terms used in the table have precise meanings, and not all VCS's use the same term in the same way - which means that some translation is needed to fill it in properly.

Overview

RCS Name

Bazaar

Arch

CVS

Subversion

SVK

Git

Mercurial

Monotone

Darcs

Decentralized

Yes

Yes

No

No

Yes

Yes

Yes

Yes

Yes

Disconnected Ops

Yes

Yes

No

Limited

Yes

Yes

Yes

Yes

Yes

Simple Namespace

Yes

No

No

Yes

Yes

No

No

No

Yes

Supports Renames

Yes

Yes

No

Somewhat

Somewhat

Somewhat

Somewhat

Yes

Yes

Needs Repository

No

Yes

Yes

Yes

Yes

No

No

Yes

No

Supports Repository

Yes

Yes

Yes

Yes

Yes

No

No

Yes

Somewhat

Checkouts

Yes

Yes

Yes

Yes

Yes

?

No

Yes

No

Partial Checkouts

No

No

Yes

Yes

Yes

No?

No

?

No

Atomic Commit

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

Cheap branching Anywhere

Yes

Yes

No

Yes

Yes

Yes

No

No

No

[:Merge:Smart Merge]

Yes

Yes

No

No

Yes

Yes

Yes

Yes

Yes

[:CherryPick:Cherrypicks]

Somewhat

Somewhat

Somewhat

Somewhat

Somewhat

Somewhat

Somewhat

Somewhat

Yes

[:BzrPlugins:Plugins]

Yes

No

No

?

No

?

Yes

?

No

Has Special Server

Soon

No

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Req. Dedicated Server

No

No

Remote

Remote

Remote

No

No

No

No

Good Windows support

Yes

No

Yes

Yes

Somewhat

No

Somewhat

Yes

Yes

Fast Local Performance

Yes

No

Yes

Yes

Yes

Yes

Yes

Yes

No

Fast Network Performance

Soon

No

Yes

Yes

Yes

Yes

Yes

Yes

No

Ease of Use

No

No

Somewhat

Somewhat

Somewhat

?

Somewhat

?

Yes

Details about each feature

Decentralized

Whether the tool is designed to allow [:Branch:branches] of the same project to be in different remote [:Repository:repositories].

Simple Namespace

The namespace is the way the RCS communicates with the user the various resources for the RCS such as the names for branches and the names for [:Revision:revisions] that are [:Merge:merge]. For example: requiring the user to refer to revisions with base-16 numbers is not considered "simple" in this document.

Needs Repository / Supports Repository

Some revision control systems require that branches be aggregated into [:Repository:repositories]. Bzr can use repositories if you like, for greater space efficiency, convenient publishing and backups.

Supports Renames

If a user can rename a file in the RCS without loosing the RCS history for a file, then renames are considered supported. If the operation resultes in a delete/add (aka "DA pair"), then renames are not considered supported. If the operation results in a copy/delete pair, renames are considered "somewhat" supported. The problem with copy support is that it is hard to define sane merge semantics for copies.

Has Checkouts

A ["Checkout"] is a [:WorkingTree:working tree] that points elsewhere for its RCS data.

Atomic Commit

Does the RCS track which files were associated with which [:Commit:commit].

Smart Merge

Whether the tool is able to know which revisions have to be merged (recording [:Merge:merge] history is a necessary condition for this).

Cheap Branching Anywhere

Some systems only support cheap branching on filesystems that support hard links, but bzr can do cheap branching on any filesystem, and even on FTP servers.

Cherrypicks

Whether the tool allows CherryPick (fine-grained selection of revisions to be merged).

Plugins

Whether the tool is extensible with plugins. Our plugins are on the BzrPlugins page.

Can use standard fileserver

Whether the tool can work with a standard file server (HTTP for read-only operations, ftp/sftp/webdav or others for write operations). This allows you to host a repository on almost any internet service provider without dedicated support.

Work on partial checkout

Whether a user can checkout only a subdirectory of a project and work on it.

Windows support

Whether the Microsoft Windows platform has good native support. Cygwin support is not sufficient.

Fast Local Performance

Whether local operations (commit, "which files have I changed?", diff, switch to different revision, merge) are fast.

Fast Network Performance

Whether network operations (pull, push, clone) are fast.

Ease of Use

The learning curve to do what you want to do. See the following comparisons, evals:

Details of particular VCSes

In some cases, it is hard to answer 'yes' or 'no' to a particular question.

Bazaar

The current implementation of Bazaar has somewhat mediocre network performance for propagating changes. The current knit format is much better about this than the old weave format. 0.9 has improved as well (see ["Performance/0.9"]), and a ["SmartServer"] is planned which will make network operations much faster.

Mercurial

Mercurial does not support renames, representing them as copy+delete instead. Its merge doesn't handle renames (support is pending). Other operations such as diff and log also don't follow renames. Since it does not track directories, directory renames are hard for it to represent and remember.

Mercurial supports something called a "repository", but it's not what we mean by repositories: a collection of persistent branches and their revisions. In Mercurial repositories, branches are not persistent: when a merge is committed, the two branches become one.

Mercurial's namespace is complicated because its "named branches" do not have unique urls-- instead, they are a combination of repository URL and a tag name.

The recommended method of branching involves creating a new repository, which is expensive when hardlinks are not available.

Git

Git does not store renames. However, features like merge can make pretty good guesses about renames. Git does not work on native Windows, but does work (slowly) on Cygwin.

Subversion

Subversion does not support decentralized operation, but svk is a decentralized VCS implemented on top of svn. Subversion can also do some things (like comparisons of the working directory against the checked out version) without a connection to the server, but for anything that actually affects the repository (like a checkin), Subversion needs to be able to talk to the server. Subversion records renames as copy + delete. (See their [http://subversion.tigris.org/issues/show_bug.cgi?id=898 true rename support] bug)

SVK

SVK achieves distribution by mirroring parts of remote subversion repositories into a local one. It has to be set up explicitely and only pulls over changesets on selected branches. That works well for setups with central repository or a simple star topology, but more ad-hoc topologies get hard to manage and may cause situations where merge does not work because the most recent common ancestor is not available. SVK's rename support is limited by what Subversion provides and only works as well as Subversion one's does.