CVS Concepts

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!

TableOfContents(3)

Anchor(workflow)

Workflow in Mercurial compared to CVS

The main mental difficulty when switching form CVS to Mercurial lies in the slightly different workflow. In Mercurial the golden rule is: if you completed a piece of work, check in, regardless of other people.

With CVS, before committing you first pull in remote changes (cvs up) and merge before checking in. this of course risks that you might loose some work, it does not work as expected, etc.

With Mercurial you do first a checkin in your local repository. Afterwards you pull in remote changes, in many cases Mercurial creates then a second head. one contains your changes, one the other peoples changes. If you want to keep your head, do "hg merge other-head". Then you commit to the remote server (see Collaboration below for how to get it there). The checkin first policy allows for much more security, you can easily go back to your original version befor you started with pulling in changes.

This Mercurial workflow has just one major problem left: you need to have a tool which manages binary merge (and i do not know one on windows ...). kdiff3 is broken in this respect, and also mercurial does not pay attention as it calls kdiff3 with a binary file.

Anchor(convert)

Converting a CVS repository

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

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"].

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.

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.

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.

Tags

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

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.

Anchor(collab)

Collaborating with other people

While in CVS you get a copy of the files onto your disk, in Mercurial you get a complete repository and the files on your disk.

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

  • 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

• ["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

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.

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.

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.

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.

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.

See workflow in paragraph workflow for remaining difficulties with binary files with mercurial.

Anchor(keyword)

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"].