Mercurial_ The Definitive Guide - Bryan O'Sullivan [55]
Detecting Case Conflicts
When operating in the working directory, Mercurial honors the naming policy of the filesystem where the working directory is located. If the filesystem is case preserving, but insensitive, Mercurial will treat names that differ only in case as the same.
An important aspect of this approach is that it is possible to commit a changeset on a case-sensitive (typically Linux or Unix) filesystem that will cause trouble for users on case-insensitive (usually Windows and Mac OS) filesystems. If a Linux user commits changes to two files, one named myfile.c and the other named MyFile.C, they will be stored correctly in the repository. And in the working directories of other Linux users, they will be correctly represented as separate files.
If a Windows or Mac user pulls this change, they will not initially have a problem, because Mercurial’s repository storage mechanism is case safe. However, once the user tries to hg update the working directory to that changeset, or hg merge with that changeset, Mercurial will spot the conflict between the two filenames that the filesystem would treat as the same, and forbid the update or merge from occurring.
Fixing a Case Conflict
If you are using Windows or a Mac in a mixed environment where some of your collaborators are using Linux or Unix, and Mercurial reports a case-folding conflict when you try to hg update or hg merge, the procedure to fix the problem is simple.
Just find a nearby Linux or Unix box, clone the problem repository onto it, and use Mercurial’s hg rename command to change the names of any offending files or directories so that they will no longer cause case-folding conflicts. Commit this change, hg pull or hg push it across to your Windows or Mac OS system, and hg update to the revision with the non-conflicting names.
The changeset with case-conflicting names will remain in your project’s history, and you still won’t be able to hg update your working directory to that changeset on a Windows or Mac OS system, but you can continue development unimpeded.
Chapter 8. Managing Releases and Branchy Development
Mercurial provides several mechanisms for you to manage a project that is progressing on multiple fronts at once. To understand these mechanisms, let’s first take a brief look at a fairly normal software project structure.
Many software projects issue periodic “major” releases that contain substantial new features. In parallel, they may issue “minor” releases. These are usually identical to the major releases off which they’re based, but with a few bugs fixed.
In this chapter, we’ll start by talking about how to keep records of project milestones such as releases. We’ll then continue on to talk about the flow of work between different phases of a project, and how Mercurial can help you to isolate and manage this work.
Giving a Persistent Name to a Revision
Once you decide that you’d like to call a particular revision a “release,” it’s a good idea to record the identity of that revision. This will let you reproduce that release at a later date, for whatever purpose you might need at the time (reproducing a bug, porting to a new platform, etc.).
$ hg init mytag
$ cd mytag
$ echo hello > myfile
$ hg commit -A -m 'Initial commit'
adding myfile
Mercurial lets you give a permanent name to any revision using the hg tag command. Not surprisingly, these names are called “tags.”
$ hg tag v1.0
A tag is nothing more than a “symbolic name” for a revision. Tags exist purely for your convenience, so that you have a handy, permanent way to refer to a revision; Mercurial doesn’t interpret the tag names in any way. Neither does Mercurial place any restrictions on the name of a tag, beyond a few that are necessary to ensure that a tag can be parsed unambiguously. A tag name cannot contain any of