Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Differences between revisions 26 and 28 (spanning 2 versions)
Revision 26 as of 2006-02-20 18:24:44
Size: 5228
Editor: MatthieuMoy
Comment: Lock step development
Revision 28 as of 2006-02-21 16:06:31
Size: 3623
Comment: taking another stab at RcsComparisons
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
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-NG in particular. 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-NG in particular. The determination on this chart is based upon the core installation and features that are already working in devel.
Line 7: Line 7:
||RCS Name ||Bazaar-NG||Arch||CVS ||Subversion||Git ||Hg ||Monotone || Darcs ||
||Decentralized || Yes ||Yes ||No ||No[#3 (3)]||Yes ||Yes ||Yes ||Yes ||
||Simple/No Namespace||Yes ||No ||No ||Yes || ||No ||No ||Yes ||
||Supports Renames || Yes ||Yes ||No ||Yes ||Yes[#2 (2)]||No[#1 (1)]||Yes ||Yes ||
||Optional Repository||None ||Req ||Req ||Req || || || || ||
||Has standalone branches||Yes||No ||No ||No ||Yes? ||Yes || ||Yes ||
||Has Checkouts || Yes ||Yes ||Yes ||Yes || || || ||No ||
||Has Revisions || Yes ||Yes ||No ||Yes || || || || ||
||Smart Merge || Yes ||Yes ||No ||No ||No? || ||Yes ||Yes ||
||Cherrypicks || Yes ||Yes ||Yes ||Yes || ||Yes ||Somewhat[#5 (5)]||Yes ||
||Plugins || Yes ||No ||No || || || || || ||
||Can use standard fileserver||Yes||Yes||No||No || ||Somewhat ||No ||Yes ||
||Can work over email||Planned||No ||No ||No || || || ||Yes ||
||Work on partial checkout||No||No ||Yes ||Yes || || || ||No? ||
||Windows support || Yes ||Poor||Yes ||Yes ||No [#4 (4)]||Yes || || ||
||Lock step development||Optional||Optional||Yes||Yes ||no? ||No? ||No ||No? ||

(note: it would be interesting to have a small benchmark too, like "time to run XXX diff/import/commit in the linux kernel",)
||RCS Name ||Bazaar-NG||Arch||CVS ||Subversion||Git ||Hg ||Monotone||Darcs||
||Decentralized ||Yes ||Yes ||No ||No ||Yes ||Yes||Yes ||Yes ||
||Simple Namespace ||Yes ||No ||No ||Yes ||No ||No ||No ||Yes ||
||Supports Renames ||Yes ||Yes ||No ||Yes ||Yes ||No ||Yes ||Yes ||
||Needs Repository ||No ||Yes ||Yes ||Yes || || || || ||
||Checkouts ||Yes ||No ||Yes ||Yes || || || ||No ||
||Atomic Commit ||Yes ||Yes ||No ||Yes || || || || ||
||Smart Merge ||Yes ||Yes ||No ||No ||No? || ||Yes ||Yes ||
||[Cherrypicks ||Yes ||Yes ||Yes ||Yes || ||Yes||Yes ||Yes ||
||Plugins ||Yes ||No ||No || || || || || ||
||Has Special Server ||No ||No ||Yes ||Yes || || || || ||
||Req. Dedicated Server||No ||No ||Remote||Remote ||No ||No ||No ||Yes ||
||Good Windows support ||Yes ||No ||Yes ||Yes ||No ||Yes|| || ||
Line 29: Line 24:
Whether the tool is designed to allow [:Branch:branches] of the same project to be in different remote [:Repository:repositories].
Line 30: Line 26:
Whether the tool is designed to allow branches of the same project to be in different remote 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.
Line 32: Line 29:
== Simple/No Namespace ==

The namespace is the way a revision control system identifies a revision uniquely. It can be user-visible (GNU Arch), or tool internal (bzr, git, ...).

== Optional Repository ==

?

What does "req" mean?
== Needs Repository ==
Some revision control systems require that branches be aggregated into [:Repository:repositories].
Line 43: Line 33:

Whether the tool supports file renaming and merging changes to a renamed file.
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.
Line 47: Line 36:
A ["Checkout"] is a [:WorkingTree:working tree] that points elsewhere for its RCS data.
Line 48: Line 38:
A [Checkout checkout] is a working tree with a relatively small amount of metadata.

== Has Revisions ==

?

== Has standalone branches ==

A StandaloneBranch is a directory containing both a working tree and the history.
== Atomic Commit ==
Does the RCS track which files were associated with which commit.
Line 59: Line 42:
Line 63: Line 45:
Line 67: Line 48:

Whether the tool is extensible with plugins. See BzrPlugins for the case of bzr.
Whether the tool is extensible with plugins. Our plugins are on the BzrPlugins page.
Line 71: Line 51:
Line 74: Line 53:
== Can work over email ==

Whether the tool can easily work over email. This is usefull for example for an occasional contribution to a project, without having to publish a branch. See SubmitByMail.
Line 79: Line 54:
Line 83: Line 57:
Line 85: Line 58:

== Lock step development ==

Whether users are forced to be up-to-date to be able to commit. This prevents divergent branches. This is by-nature the case for centralized RCS, and might optionaly be implemented in distributed RCS.

= Footnotes =

[[Anchor(1)]] 1. Support for renames in hg is being implemented. Unlike bzr, it uses rename history instead of unique file ID.

[[Anchor(2)]] 2. Git has a very particular management of renames. It does not track renames at commit time at all. However, it "guesses" them at merge time. Since it uses hashes, it can immediately see renames without modifications, and otherwise, it has to use a heuristic to find the file with the closest content. Linus claims that this is the best model, while other find it completely broken. See for example [http://www.mail-archive.com/git@vger.kernel.org/msg03711.html this post].

[[Anchor(3)]] 3. Subversion is surely not a decentralized revision control system (see for example [http://subversion.tigris.org/subversion-linus.html this page] if you're not convinced). However, [http://svk.elixus.org/ svk] is built on top of subversion and is a decentralized revision control system.

[[Anchor(4)]] 4. Can be made to work on cygwin, but with poor performance.

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-NG in particular. The determination on this chart is based upon the core installation and features that are already working in devel.

Overview

RCS Name

Bazaar-NG

Arch

CVS

Subversion

Git

Hg

Monotone

Darcs

Decentralized

Yes

Yes

No

No

Yes

Yes

Yes

Yes

Simple Namespace

Yes

No

No

Yes

No

No

No

Yes

Supports Renames

Yes

Yes

No

Yes

Yes

No

Yes

Yes

Needs Repository

No

Yes

Yes

Yes

Checkouts

Yes

No

Yes

Yes

No

Atomic Commit

Yes

Yes

No

Yes

Smart Merge

Yes

Yes

No

No

No?

Yes

Yes

[Cherrypicks

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Plugins

Yes

No

No

Has Special Server

No

No

Yes

Yes

Req. Dedicated Server

No

No

Remote

Remote

No

No

No

Yes

Good Windows support

Yes

No

Yes

Yes

No

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

Some revision control systems require that branches be aggregated into [:Repository:repositories].

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.

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.

Smart Merge

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

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 is well supported.