Talk:Comparison of revision control software

From Wikipedia, the free encyclopedia

Contents

[edit] Notable users is biased

I believe that the notable users column is a bit biased towards commercial software packages, since many/most open soruce projects do not have the resources to go around getting people to sign rights to allow them to list the names of their users companies. The editor coming along an listing all these as not suitable is just innapropriate. Everyone reading this page knows that pretty much any large organisation will have a mix of CVS, CVSNT and SVN in use somewhere in the organisation.

Arthur 07:14, 4 December 2007 (UTC)

[edit] Requests

I guess many improvements could be apply here:

1) Add others features like in following links: berlios comparison, bitkeeper Vs subversion and Wine Hacking Tips

Also (Thoglette 07:12, 6 November 2006 (UTC))

  • support for versioning of directories
  • support for distributed development
  • branching mechanism
  • configuration management

More than happy to add, for that which I understand.

2) Add others RCS like Rational ClearCase and Visual Source Safe (see below, Open Souce )

3) And I'd like to see if any of those can convert character sets on-the-fly (not file names, which CVSNT does, but file contents). None of the presented features are of any interest to me ;) --Lam 09:19, 21 June 2006 (UTC)

OK, I'll include those on the list of things to do. I have seen the comparisons you mention, and I didn't include all the categories because it's hard to extend the comparison to many different systems, and some are a matter of opinion. (The BerliOS comparison uses words like "excellent" and "poor" for some categories that I don't think would be tenable in neutral comparison.)
It would be even better if you or someone else could help with the changes. Wmahan. 17:22, 21 June 2006 (UTC)

4) (pls 2007-05-27) I'm very interested in support for international development. In particular, is there full diff/merge support for files in a) UTF-8, b) UTF-16LE or BE, or c) support for a designated character set that differs from the system character set. It seems that despite the growing amount of international development and adoption of various Unicode forms, very few revision control systems support Unicode files.

5) Spinky Sam (talk) 17:10, 4 March 2008 (UTC) In support of point (1) above, I think file rename doesn't really cover it as far as full support for refactoring. What we want is a more comprehensive column title, such as "file or directory moves and renames" (obviously with ability to retrieve full directory/file structure for a previous release) - the trick is to check for each of these whether they include the feature!

6) Ability to delete from history can be an important feature for legal reasons; pls add to comparison chart. —Preceding unsigned comment added by 196.202.237.199 (talk) 13:39, 7 June 2008 (UTC)

[edit] Concurrency

I made some changes in the Concurrency Lock vs. Merge column:

  • ClearCase uses the merge model by default, but many sites set a trigger to force locking on checkout which allows ClearCase to use a lock model. However, concurrency really doesn't apply to most ClearCase sites because most sites (and all sites that use ClearCase UCM), give each developer their own branch for their work. Concurrency issues only appear when the developer is ready to deliver their work to the main branch, and code is merged into the main branch.
  • Perforce and Subversion both allow for attributes to be set to force files to use the concurrency locking model. This is heavily discouraged, but some sites do insist on using concurrency locking. Concerrency locking is really only suppose to be used on files that cannot be merged like icons, JPG files, and MS-Word documents.

[edit] ClearCase

I know a bit about ClearCase. It seems to be the VCS that is used at many large corporations (HP, for example, uses it globally. IBM probably uses it in places too. Also, I know of several medium to large defense contractors that use ClearCase). I'll list the info that I know — I don't know several of the fields so I figure I'll post the info here rather than leave lots of question marks in the article.
  • General Information
    • Maintained by IBM. Not sure if it is actively developed or just maintained.
    • The repository is client/server.
This seems incorrect in the list -- ClearCase is not distributed -- you can't access version history off-line. All you can do is hijack files and merge back when on-line. —Preceding unsigned comment added by 69.178.20.107 (talk) 23:25, 5 April 2008 (UTC)
  • Technical Information
    • Not sure what language it is written in.
    • The history model is snapshot. What does "patch" mean in this context?
    • The revision IDs are namespace.
    • Unsure what the repo size is bounded by.
    • ClearCase dynamic views piggyback on top of SMB (for Windows) or NFS (for Unix/Linux). The ClearCase Web Client and ClearCase Remote Client use HTTP, but don't support dynamic views.
  • Features
    • No on atomic commits.
    • File/directory renames supported.
    • Unsure on symbolic links. There are special ClearCase symlinks available, but I'm not sure if symlinks on a *nix system can be versioned.
    • Tons of hooks (triggers in ClearCase lingo) can be set up -- but only in Perl.
    • I'm not sure if it supports signed revisions.
    • Two modes: snapshot and dynamic. Snapshot makes a copy of the files on your local machine. Dynamic mounts a proprietary file-system that points at the repository and creates "virtual" files on the file-system. Accessing a file on a dynamic view (either editing or compiling) will cause the file to be copied across the network to the local machine.
    • Views: Clearcase uses views to provide an indirection between the repository and the files available to the user. A user creates a view-specification which details which files, directories, and versions are available to the user.
  • User Interfaces
    • not sure about web interface
    • GUIs are available for Windows and Unix for sure; not so sure about the other supported operating systems.
    • Stand-alone GUI for Windows and Unix as well as shell extensions to the standard Windows explorer.
  • Network protocol
    • proprietary, transactions are accomplished using many small packets which makes the system unresponsive if run over a WAN.
  • Multi-site
    • Each site has a copy of the repository. By default, elements are owned by one site only. Sharing is accomplished by branching each element for each site. Periodic repository synchronizations is required to give all users the same view. Changes made at one site will not be visible to the other site until a sync takes place.
    • Ownership (mastership) of elements can be passed between sites.

ClearCase also does a decent job tracking merges (something which CVS doesn't support, and svn doesn't support yet). Perhaps add a column for merge tracking to the "features" table? It might also be nice to have information on branching and tagging (but I think all VCS listed have these capabilities?).

Slartoff 02:10, 26 July 2006 (UTC)

Additions made by Cave Mike 04:21 30 Aug 2006 (UTC)

Edits made by W. Craig Trader 19:50 23 Feb 2007 (UTC)

[edit] Atomic Commits in ClearCase ?

ClearCase definitely cannot do this (allow changes to a group of files to be applied in one transaction). There is an extension called "ClearCase UCM" (with additional license cost) which supposedly provides this functionality, though the details are not clear.

Mister Farkas 23:39, 20 February 2007 (UTC)

This is an example of what makes this kind of exercise (comparing apples and oranges, as instances of an ill-defined category) ludicrous. Why is atomic commit needed? Because commit and deliver are coupled. What one wants is atomic delivery, nobody should care for atomic commit, on the contrary. The two are coupled in one case, which I call the /main/LATEST syndrome. How do you get an atomic delivery in base ClearCase? Rename a label type after you have applied it (note: this is atomic on the site where it was applied, not through replication. If you want an atomic delivery on an other site, apply an other label).

UCM doesn't need an additional cost. Everybody pays for it already. Marc Girod.

[edit] Atomic Commits in ClearCase

this is called "deliver" in UCM and will commit all changes in the UCM activity

in base ClearCase you could simply write a script: 1) use cleartool protect to prevent other users from making any modifications 2) perform all check-ins, merges, etc. while labelling all new version 3) if you want to roll-back, use cleartool rmversion on all labelled new versions 4) when you are finished use cleartool protect to allow other users access again

you could run such a script from clearcase context menu (run clearmenuadmin.exe) or queue check-ins and merges for a single transaction later

Michael Moors 00:00, 18 May2007 (GMT)

[edit] Telelogic SYNERGY

Was Continuus/CM. It should be added to this article. It's a player in this market, even though many people dislike it. This product introduced task development, if I understand correctly. Unfortunately, I don't know enough about SYNERGY to edit the article. Cernansky 00:15, 11 November 2006 (UTC)


[edit] Atomic Commits in SYNERGY?

SYNERGY does not provide atomic commits. If you interrupt your client while completing a task you'll have a partially completed task. Same when you create baselines, you will have partially created baselines... All single operations affecting multiple files/objects are not atomic in SYNERGY.

[edit] VSS

Yes, it is not the industry leader. But to ignore it is just silly Thoglette 07:13, 6 November 2006 (UTC)

[edit] Open source

Is this open-source only listing? If so, its title should be changed. If not, I'm going to add our product, Code Co-op to the list. -- Bartosz 19:49, 31 May 2006 (UTC)

It's not intended to be open-source only, although I'd prefer to only have notable projects so that the article doesn't get cluttered. You are welcome to add your product, but I might add more columns later, so help keeping the entry up to date would be appreciated.
If your product has any outstanding features that you think distinguish it from other systems, feel free to add columns for those. Of course, all the information should be presented in a neutral and verifiable way. Wmahan. 20:30, 31 May 2006 (UTC)

[edit] Explanation of terms

What is namespace revision IDs? -- Bartosz 19:54, 31 May 2006 (UTC)

I borrowed the terminology from [1]. Basically I was trying to indicate how a user refers to particular revision. By namespace I mean that the system uses a filename and maybe a simple version number. Other systems use hex values representing hashes of a file's contents. I realize that the concept is a little unclear as currently presented, and I'm open to suggestions. Wmahan. 20:28, 31 May 2006 (UTC

)

The table has subversion listed as using snapshots for the history model. That's a common misconception; while svn presents the history to the user as a list of snapshots, the change is actually stored internally as a changeset. If a repository uses the fsfs backend, you can see the individual changesets in db/revs/nnn.

OK. I'm not sure whether that column represents a useful distinction. I was trying to show that systems can use very different ways of storing revisions internally. But to be honest, I'm not sure I understand each system well enough to come up with an accurate comparison in this area. Maybe I should just remove that column. Wmahan. 05:27, 19 June 2006 (UTC)

[edit] email notification

There is no column specifying which products send email on various actions. I believe this is a good evaluation decider, and should be included.

To start off, I know that :
CVSNT : Yes
SourceSafe : No —Preceding unsigned comment added by IanVaughan (talk • contribs)

IMHO, whether the VCS directly supports email notification is not very important - if it supports triggers, emails can be sent using those. Bullestock 20:44, 28 October 2007 (UTC)

[edit] ACL's

I propose to add a column indicating whether the VCS supports access control lists. I know that CVSNT does, and CVS doesn't - no doubt most of the commercial big players do as well. Bullestock 20:44, 28 October 2007 (UTC)

CVS "admin" (and RCS of course) have at least per-file lists of users who are allowed to modify a file. I've been using the feature for quite a while Tedickey 20:51, 28 October 2007 (UTC)

[edit] History models

I find the words used to describe the "history models" to be rather un-informative. The present revision of the article, for example, makes it appear as though VSS and StarTeam use the same model, which is simply not true. StarTeam stores full copies of each revision, whereas VSS uses reverse deltas. The term "changeset" implies forward deltas, but this seems impractical and is far from clear. Similarly, the terms "patch" and "changes" seem to be used more or less interchangeably in this section. How many different methods are there for storing revisions? --Craig Stuntz 15:32, 13 December 2006 (UTC)

I agree. It would be far clearer to separate the history interface from the history implementation. While the revision control system might present snapshots or changesets, these are implemented as snapshots, forward delta, reverse delta (such as VSS), bidirectional delta (such as darcs), or hierarchical forward delta (such as Subversion). If we don't card about the details though, perhaps the column should just be renamed so that it clearly only refers to the interface. -- JRBruce 2007-03-30 20:18

Also, both SVK and Subversion use exactly the same system (SVK works on top of SVN), so they shouldn't have different history models. Each revision represents a snapshot, but as JRBruce says, they store deltas.--Cynebeald 06:27, 10 October 2007 (UTC)

[edit] BitKeeper

Why is BitKeeper not represented in this comparison? Billdav 02:07, 19 January 2007 (UTC)

Because nobody has added it yet, of course. You are welcome to do so if you are familiar with it. -- intgr 11:22, 22 January 2007 (UTC)

[edit] Perforce does not operate on the merge model

You always lock the file in Perforce; it's an advisory lock, but it's a lock, and unsophisticated user don't expect anyone else to be able to check out the file. Perforce also does no automatic merging, unlike CVS and Subversion and others.

Merging is a fallback in Perforce. —The preceding unsigned comment was added by 68.34.156.186 (talk) 17:19, 3 May 2007 (UTC).

[edit] It operates under merge or lock

The footnote in the article, "In Perforce, file attributes can be set to allow for the lock model. However, this is discouraged by Perforce and should only be used on files (typically binaries) that cannot be easily merged on check in." is

a) incomplete: files can be opened locked, in addition to specifying that all files of a particular type default to opened locked, and b) incorrect as far as I can tell: reading nearly all of the documentation on the Perforce website I find no recommendations against locking

I'm removing the footnote and changing the model to Merge or Lock.

Regarding a, see [2] or [3]. Regarding b, if someone can come up with a reference saying locking is discouraged, then cool, but Locking is still supported regardless.

Cheers. 75.45.127.0 06:48, 19 June 2007 (UTC)

[edit] CodeVille mentioned once

CodeVille is only mentioned once, and is not included in most of the comparisons. -Jason Espinosa

[edit] Repos size = O(entropy(x))?

A lot of revision control systems compress their data. For example, git saves commits as a pointer to a version of each file, but the versions are delta-encoded so its size is actually O(change entropy). I don't know about all systems, but shouldn't repos size for the compressed systems read O(patch entropy) for example? O(patch entropy) is quite different from O(patch), because saving a terabyte of zeroes won't take up a lot of space but saving a gigabyte of random data will. Boemanneke 17:06, 30 June 2007 (UTC)

You're right, but that's a level of detail that is unnecessary for a high-level overview like this. O(patch) means "proportional to the size of the change", with a poorly specified "change" metric. Talking about entropy doesn't change that quibble; we just talk about the model that the entropy is relative to. The column basically translates to "does delta compression?", but it's made less ambiguous by using an objectively measurable metric. So leave it as is. 71.41.210.146 (talk) 11:09, 8 June 2008 (UTC)

[edit] Relationship to List of revision control software

There's no good reason to merge, since the articles deal with different aspects - comparison to highlight differences, and a list to show the range of possibilities. If the topics were small, then the merged article might save. But they're not. Tedickey 12:39, 5 September 2007 (UTC)


[edit] Changes

  • Added the price for Accurev (1,495$) which was previously set as unknown.
  • Moved the new "Razor" system to its appropriate place in the alphabet. Also changed its internal link to razor(Revision Control System) since its current link was pointing to the regular Razor page.
  • I noticed that a few more systems were out of order. Resorted them, and they are on their proper places now. Going to have a look if i can replace a few "?" from the tables with actual information.

(I'm resigning the date each time i add something, so most changes are older then the date displayed!)

Excirial 14:58, 5 October 2007 (UTC)

[edit] SVK

Informations about SVK are outdated. See http://bestpractical.typepad.com/worst_impractical/2007/01/svk_20_is_bette.html --201.52.25.118 04:02, 1 November 2007 (UTC)--

[edit] Other names for 'revision control software'

Should these:

* (List of) Source Configuration Management
* (List of) Version Control Systems

be redirected here? Arauzo (talk) 17:08, 19 November 2007 (UTC)

[edit] Divide this article in two?

What do you contributors think about dividing this article in two, one for centralized and other for decentralized VCSs?

The rationale is that one of the very first decisions you make when making your choice of VCS, is whether it should be decentralized or it can be client-server. This is directly tied to your development model. After you have decided which model of VCS you want, then you compare the features provided by those software that provide that model.

The benefits are that the tables would be smaller and easier to read and compare them, and each article may focus on features specific to a single model (like inter-repository merging (push/pull) facilities and support, that are specific for distributed VCSs).

--Juliano (T) 20:35, 6 May 2008 (UTC)

[edit] add "language" field ?

Hello, what do you think of adding as a field the language (C, Python etc.) the application is written in ? Eric.dane (talk) 17:03, 18 May 2008 (UTC)

I see that this field has already been added, but I don't understand why anyone would care. The focus of this page appears to be for selecting which one to use. As a developer you care about details like that, but as a SCM admin (my day job), that is an unimportant detail. Performance, atomic commits, centralized vs. decentralized, ACLs, and so forth are all wonderful characteristics, but its source language isn't one of 'em. Likewise I don't care if the source comments are in French (or whatever else) because I'll never be looking at them.

I think it would make more sense to have a separate page, or at least a separate table, with characteristics that interest potential contributors. Obviously the proprietary tools could be left off of that one. —Preceding unsigned comment added by 128.221.197.20 (talk) 21:25, 29 May 2008 (UTC)

Actually, I found the language information useful; if there isn't a suitable pre-built binary available, then installing the software implies building it, and if that means first installing a build system for the language, then an alternative tool might be preferable. For this aspect to be fully covered, it would however be necessary to rather make a table of external dependencies in general: scripting languages, compression libraries, networking libraries, etc. 81.231.36.22 (talk) 21:26, 2 June 2008 (UTC)

[edit] Migration possibilities?

One factor which is relevant when choosing a revision control system is whether existing projects can be moved into it, and conversely moved out from it, without losing the revision history. (I'd normally use the terms import and export for these, but the Revision control page defines "export" as an operation which "creates a clean directory tree without the version control metadata".) Migration tools generally seem to be separate utilities rather than integrated parts of the various systems, but it is nontheless interesting to know that they exist and which moves are supported by existing software.

When considering whether to start using revision control system X, it is obviously important whether one's old projects currently controlled by system Y can be moved to the new system — even if this isn't something one does immediately, it is probably something one considers doing eventually, since why move unless the new system X has some attractive features not found in system Y?

The need to move out is the need to have the option to undo a decision, in case it after several months of experience turns out to have been a bad one. It might also arise because one wishes to switch from a distributed to a client–server system (or vice versa). It is of course always possible to take the tip of trunk in system X and check that back into the old system Y as just a new version, but that loses all the history that was recorded using system Y, and file renames are likely to be lost track of. 81.231.36.22 (talk) 21:59, 2 June 2008 (UTC)

There's probably not a lot of material here - there are import features in various tools, mainly provided as a competitive measure. A few of those are done well; users of the target systems tend to be uninformed about the topic of import limitations since the developers of the tools tend to blame the original system. Exports (other than providing a snapshot as noted above) fare worse. Tedickey (talk) 22:07, 2 June 2008 (UTC)

[edit] Signed revisions in Perforce

The article claims Perforce supports digital signing of revisions. I can find no evidence of this either in Perforce itself or on the Internet. Does anyone know if this is accurate? MoraSique (talk) 20:13, 3 June 2008 (UTC)

[edit] Useful external link—second opinion solicited

This revert was by a bot that objected to a link to an ongoing DCVS comparison comparing Bazaar, Git, and Mercurial, because it's hosted on blogspot, and blogs are generally not good sources.

However, in this case it's actually (unrefereed) primary research, that just happens to use blogspot for publication. And in a field under active development, current (June 2008) information is very valuable; by the time it's in a more formal form, it will be obsolete. I requested a second opinion, and the feedback was that such a second opinion would be better sought here on the talk page.

So.. I'm asking. Any opinions? Basically, "Mr. Speaker, I hereby move that this link be added. Do I have a second?" If you'd like to second, just undo the bot's edit; the bot will then leave it alone. 71.41.210.146 (talk) 09:11, 8 June 2008 (UTC)