Mercurial for CVS users
(The structure of this topic is borrowed from the [http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ap-a Subversion Book]. Thanks, guys!)
- [#convert Converting a CVS repository]
- [#rev Revisions]
- [#disconnect Disconnected operation]
- [#tag Modules, branching and tagging]
- [#collab Collaborating with other people]
- [#server Running a server]
- [#watch Watching files]
- [#binary Binary files]
- [#keyword Keywords expansion]
1. Converting a CVS repository
For details of how to convert a ["CVS"] repository to a ["Mercurial"] ["Repository"], see ConvertingRepositories.
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. 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. 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.
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.
A Mercurial ["Tag"] is just a symbolic name for a ChangeSet. See ["Tag"] for a little more discussion.
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. 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:
["Export"] one or more ["ChangeSet"]s and
["Push"] (or rsync) the ["ChangeSet"]s into a ["Repository"] from which other people can ["Pull"] them
- ["Clone"] a copy of the ["Repository"] onto a CD-ROM and hand it to someone else
6. 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. 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. 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. Keywords expansion
["CVS"] expands keywords such as $Revision: 1.12 $ by adding information from it. This feature is not in ["Mercurial"] - see http://www.selenic.com/pipermail/mercurial/2005-August/003887.html, ["KeywordPlan"], ["KeywordExpansionExtension"].