Mercurial for CVS users

(The structure of this topic is borrowed from the [http:/''''en''1.1''svn-book.html#svn-ap-a Subversion Book]. Thanks, guys!)

** {anchorlink: server Running a server}

1. {anchor: convert} Converting a CVS repository

For details of how to convert a ["CVS"] repository to a ["Mercurial"] ["Repository"], see ConvertingRepositories.

2. {anchor: rev} Revisions

In CVS, revision numbers describe the history of individual files. In ["Mercurial"], ["RevisionNumber"]s describe the history of an entire ["Repository"]. Furthermore, in ["Mercurial"], a RevisionNumber is local to a repository. To uniquely identify a ChangeSet, use a ChangeSetID.

3. {anchor: disconnect} Disconnected operation

["CVS"] requires that you have access to the central repository in order to perform any operation other than a simple text edit. By contrast, a ["Repository"] in ["Mercurial"] is a self-contained entity that contains the complete history of all files in the repository. You do not need to be connected to any server in order to perform any operation. You can even share your changes with others using USB memory sticks.

4. {anchor: tag} Modules, branching and tagging

["CVS"] has a very confused and confusing notion of modules, branching and tagging. I won't even attempt to describe these ideas. Pretend you never heard about any of it.

4.1. Branches

In ["Mercurial"], a branch is a repository. Nothing more or less. A repository is a branch. Repeat the soothing mantra.

The verb "to branch" simply means "to make a clone of a repository at a particular revision".

If every repository is a branch, how do you keep track of which one is which? That's simply a matter of convention. ["Mercurial"] has no idea which ["Repository"] is the "trunk", or which is a "branch"; it's all a matter of how you use the repositories. See WorkingPractices and CvsLikePractice for some suggestions.

4.2. Tags

A Mercurial ["Tag"] is just a symbolic name for a ChangeSet. See ["Tag"] for a little more discussion.

4.3. Modules

In ["CVS"], a module is a collection of directories that you can check out under one name.

The equivalent Mercurial concept is the ["Repository"], but there's no notion in Mercurial of "bundling" repositories together in the way that CVS bundles modules under the CVSROOT directory.

5. {anchor: collab} Collaborating with other people

With CVS, the standard way to share changes with other people is simply to check them in. Some projects have a convention of posting UnifiedDiff patches to a mailing list before making a checkin.

In ["Mercurial"], collaboration is much more flexible. You can share changes in any number of ways, including (but not limited to) the following:

** put the exported ["PatchFile"]s on a server for someone to download ** email the ["PatchFile"]s to a maintainer or mailing list ** copy the ["PatchFile"]s onto a memory stick and give them to someone else

6. {anchor: server} Running a server

With ["CVS"], the common way to manage a server is to provide anonymous access using the pserver command, and authenticated access over ssh.

6.1. Anonymous access

In ["Mercurial"], you can provide anonymous access using HTTP. You can do this either with a CGI script (see the hgweb.cgi script in the distribution) or by running a dedicated server (using the hg serve command).

Mercurial's HTTP server provides no access controls, so anyone who can connect to your web server can clone any repositories you publish, unless you take steps to secure them in some way.

6.2. Authenticated access

Mercurial allows authenticated access to repositories, by tunnelling using the ssh command. To perform an operation over ssh, compatible versions of Mercurial must be installed on both the local and remote sides, and available through your shell's search path on the remote side.

7. {anchor: watch} Watching files

["CVS"] lets you "put a watch" on files, which requires that other developers run cvs edit before they can edit a file. ["Mercurial"] has no corresponding concept, since a Mercurial ["Repository"] is a single-user entity that is not "connected" to any other.

8. {anchor: binary} Binary files

The delta algorithm used by ["Mercurial"] handles text and binary files equally well, this meaning that only the differences between revisions are stored. On the other hand, ["CVS"] was designed to work with ASCII text, and stores a full copy of each binary file version, with the consequent waste of space.

9. {anchor: keyword} Keywords expansion

["CVS"] expands keywords such as $Revision: 1.12 $ by adding information from it.