How Is Mercurial different from CVS

  • "Very". You should read and understand Mercurial basics before undertaking work with Mercurial that you care about.
  • In a lot of places where CVS is per-file or per-directory, Mercurial is per-repository. For example, a single Mercurial changeset may contain changes to many files throughout the tree.
  • With Mercurial, a complete, fully armed and operational clone of the entire Mozilla repository is on your local hard drive. Even when you are offline, you can use hg log for a list of revisions to a file or hg blame to find out who is responsible for a line of code.
  • You can do work locally and check it in (hg commit) without affecting anybody else. To push changes upstream, use hg push after committing.
  • Mercurial makes branching quick and easy and keeps merging pretty much sane. (See Publishing Mercurial Clones.)
  • Mercurial queues (docs) can help you juggle patches. It's like Quilt. The idea behind Quilt is this:

    The scripts allow you to manage a series of patches by keeping track of the changes each patch makes. Patches can be applied, un-applied, refreshed, etc.

    The key philosophical concept is that your primary output is patches. Not ".c" files, not ".h" files. But patches. So patches are the first-class object here.

  • CVS leaves conflict markers in your files sometimes. Mercurial doesn't: instead, it wants you to fix the conflicts right now, using a merge program (like kdiff3) which it launches for you.

  • Mercurial has many options. For example, it can be configured to launch an external, interactive merge program instead of leaving conflict markers in the file. (If you like conflict markers, stick with "internal:merge".) DiffMerge is probably the most intuitive/least intimidating graphical merge program for anyone new to distributed version control and three way merging, and it's cross-platform.

  • We hope Mercurial will allow us to rethink the way we work. Teams and individuals should be able to branch and merge much more easily—without opening IT tickets. People outside the community who are powerhouse developers should be able to do surprising stuff with this. Companies maintaining forks of Mozilla should have an easier time too. It all sort of remains to be seen, though.