Advanced Rails - Building Industrial-Strength Web Apps in Record Time

Version Control | 305

changeset: 1:800424c888ed

user: Brad Ediger <[email protected]>

date: Fri Oct 26 13:08:57 2007 -0500

summary: added another CSS class

$ hg merge

merging public/stylesheets/main.css

0 files updated, 1 files merged, 0 files removed, 0 files unresolved

(branch merge, don't forget to commit)

$ hg ci -m "Merged"

The newly committed merge shows the two changesets from earlier as its parents:

$ hg tip

changeset: 3:5f98ca15ccbc

tag: tip

parent: 1:800424c888ed

parent: 2:18bb8b07ec40

user: Brad Ediger <[email protected]>

date: Fri Oct 26 13:10:00 2007 -0500

summary: Merged

Often, cloning a repository in this way can be difficult. Rails applications can accu-
mulate a good deal of configuration files (in particular,database.yml) that are not
version controlled, and so must be recreated on each clone. There are a few ways
around this:

• hg cloneis basically an atomic recursive copy when working between two reposito-
  ries on the same filesystem. So, if you can be sure that the source repository will not
  change during the copy, the following two commands are roughly equivalent:
  $ hg clone trunk trunk-newcolors
  $ cp -R trunk trunk-newcolors

Mercurial Revision Numbers

Note the changeset identifiers in this example; in particular, the changeset we pulled

fromtrunk-newcolorsintotrunkhas the same hexadecimal ID in both repositories

(18bb8b07ec40), but a different numeric ID (1 versus 2).

Because changesets can be copied somewhat arbitrarily between repositories, their

numeric IDs (which simply reflect the order in which they were added to the reposi-

tory) will differ. But the hex IDs, which are SHA-1 hashes of the content of the chang-

eset and its history, remain the same.

Mercurial shows both identifiers, and either of them can be used to identify a revision,

as can tags (hg update 2,hg update 18bb8b07ec40, andhg update tipare all the same thing

in the preceding example). But the hex IDs are the only ones that are valid when talking

with another developer, or even when working between repositories on the same

machine, as we see here.