306 | Chapter 10: Large Projects
Of course, the latter has the advantage of preserving files that are not kept under
revision control.- Mercurial keeps all of its revision control metadata, including the entire reposi-
tory, in a single.hgdirectory under the project root. You can recursively copy
this.hgdirectory over the.hgdirectory of another repository and then perform
anhg update --cleanfrom the target repository to update the working copy
(which may contain extra, non-version-controlled files).
Mercurial also has support fornamed branches, which are separate branches of devel-
opment within one repository. This support has been mature since version 0.9.4.
However, named branches complicate certain aspects of using Mercurial, and they
are a somewhat advanced feature. Named branches are preferable for long-lived
development branches, while branching by cloning is still preferred for feature
branches. Chapter 8 ofDistributed Revision Control with Mercurialgoes into detail
about branching and merging (http://hgbook.red-bean.com/hgbookch8.html).
Database Migrations
When working with large Rails projects, especially those with multiple developers or
feature branches, an issue that frequently comes up is synchronizing database migra-
tions. Since Rails migrations are numbered sequentially in the order in which they
are generated (with respect to the current project), the generate script will happily
use a number that may have been in use elsewhere, in other versions of the project.
This causes difficulty upon merging. The typical workflow is this:
- The current migration version number in the trunk is 123. You branch the
project for a new feature, and in the branch you generate a migration for the
database support:
[branches/feature]$ script/generate migration AddNewFeature
exists db/migrate
create db/migrate/124_add_new_feature.rb - You need to fix an issue in the trunk, so you create and apply a migration to
trunk. It is created with version number 124, because the other version 124 is
not visible yet:
[trunk]$ script/generate migration BugFix
exists db/migrate
create db/migrate/124_bug_fix.rb - Upon merging, there are two migrations with version 124. These must be manu-
ally renumbered, which can be difficult if there were many migrations. The data-
base must then be migrated down to the lowest migration common to both
branches, and migrated back up. If the migrations are not fully reversible, the
changes may have to be applied manually.
This situation can also happen when there are multiple developers generating their
own migrations. The solution for that situation is good communication: developers