I've found the Arch/SubVersion/CVS comparison page a bit hard to get a good grasp on what Arch does do and what other systems are capable of. This will be my page where I could something I find a bit easier to understand.
-- AnandKumria
Version Control Systems
At their heart every Version Control System (VCS) is designed to provide a mechanism for you to record change you (or others) perform to a set of files. The changes may be meta-data (permissions, location) or content related. You might be able to perform operations in a disconnected distributed manner or you might have to be explicitly specificy each file to modify to a central server.
Concurrent Versioning System: Baseline
Concurrent Versioning System (CVS) is the most widely used VCS. For my purposes it will be considered as a baseline to measure every other VCS against. An ideal system will be capable of everything CVS is and provide more features and be easier to use, setup and maintain.
However I'm not going to waste time pointing out things each system does right, instead I'll try to expose as many flaws and I am aware of.
Contenders
There are a number of proposed replacements for CVS.
Arch
Steep learning curve of primary interface (tla).
Only ported to POSIX (or highly Unix-like systems) currently.
Bazaar-NG
Bazaar-NG is a revision control system resulting from a study of existing revision control systems.
Names |
Bazaar-NG |
Nicknames |
bzr |
Homepage |
|
Active Devs. |
10 |
Decentralized |
Yes |
Speed |
Good for locally existing data |
Merge quality |
Better than average |
UI Quality |
High |
Built in help |
Good |
Doc Quality |
Average |
Implemented in |
Python |
Platforms |
*nix, Darwin, Cygwin, Win32 Native |
BitKeeper
What (in my mind) brought about this plethora of VCS.
Is a proprietary version control system, with a proprietary protocol.
When merging from one tree to another you always merge against the head. This means you'll typically have two trees, a tree you work on and another you'll ask someone else to pull your changes from. They can either pull the tree in its entirety or not. No cherry-picking of changes.
DARCS
No concept of file identity, file renames require full history to be available
git
This is the system Linus Torvalds' created after the BitKeeper fiasco. Also has front ends (e.g., cogito). Can someone say something about the relative benefits of this vs arch?
Monotone
Currently considered (May 2005) by some key developers to be "somewhat alpha" and in interface flux. This means that all history will be preserved going forward, but format storing it and interfaces for accessing it may change.
Uses SQLite -- another binary format.
No ability to cherry-pick (pick only those item you feel are important / relevant) changes.
Subversion
Subversion uses APR (Apache Portable Runtime) to achieve platform independence, and can be ported to the platforms that support APR.
There are two available database back-ends. The FSFS (FileSystem FileSystem) backend, a native, file oriented data base with one file per revision, has been available since version 1.1, and has been the default since version 1.3 (Subversion is currently in version 1.5). The Berkley Database Backend (BDB) was the initial storage format, and is available for backwards compatibility.
Remote access can be achieved through Apache (which depends on webdav through Apache2 and the subversion module). Alternative ways to achieve remote access are through svnserve, or through SSH tunnelling.
