Question

I am developing a web database that is already in use for about a dozen separate installations, most of which I also manage. Each installation has a fair bit of local configuration and customization. Having just switched to mercurial from svn, I would like to take advantage of its distributed nature to keep track of local modifications. I have set up each installed server as its own repo (and configured apache not to serve the .hg directories).

My difficulty is that the development tree also contains local configuration, and I want to avoid placing every bit of it in an unversioned config file. So, how do I set things up to avoid propagating local configuration to the master repo and to the installed copies?

Example: I have a long config.ini file that should be versioned and distributed. The “clean” version contains placeholders for the database connection parameters, and I don’t want the development server’s passwords to end up in the repositories for the installed copies. But now and then I’ll make changes (e.g., new defaults) that I do need to propagate. There are several files in a similar situation.

The best I could work out so far involves installing mq and turning the local modifications into a patch (two patches, actually, with logically separate changesets). Every time I want to commit a regular changeset to the local repo, I need to pop all patches, commit the modifications, and re-apply the patches. When I’m ready to push to the master repo, I must again pop the patches, push, and re-apply them. This is all convoluted and error-prone.

The only other alternative I can see is to forget about push and only propagate changesets as patches, which seems like an even worse solution. Can someone suggest a better set-up? I can’t imagine that this is such an unusual configuration, but I haven’t found anything about it.

Edit: After following up on the suggestions here, I’m coming to the conclusion that named branches plus rebase provide a simple and workable solution. I’ve added a description in the form of my own answer. Please take a look.

Answer 1

Having followed up on the suggestions here, I came to the conclusion that named branches plus rebase provide a simple and reliable solution. I’ve been using the following method for some time now and it works very well. Basically, the history around the local changes is separated into named branches which can be easily rearranged with rebase.

I use a branch local for configuration information. When all my repos support Phases, I’ll mark the local branch secret; but the method works without it. local depends on default, but default does not depend on local so it can be pushed independently (with hg push -r default). Here’s how it works:

1. Suppose the main line of development is in the default branch. (You could have more branches; this is for concreteness). There is a master (stable) repo that does not contain passwords etc.:

   ---o--o--o   (default)
   

2. In each deployed (non-development) clone, I create a branch local and commit all local state to it.

   ...o--o--o   (default)
             \
              L--L    (local)
   

3. Updates from upstream will always be in default. Whenever I pull updates, I merge them into local (n is a sequence of new updates):

   ...o--o--o--n--n    (default)
             \     \
              L--L--N     (local)
   

   The local branch tracks the evolution of default, and I can still return to old configurations if something goes wrong.

4. On the development server, I start with the same set-up: a local branch with config settings as above. This will never be pushed. But at the tip of local I create a third branch, dev. This is where new development happens.

   ...o--o   (default)
          \
           L--L    (local)
               \
                d--d--d     (dev)
   

5. When I am ready to publish some features to the main repository, I first rebase the entire dev branch onto the tip of default:

   hg rebase --source "min(branch('dev'))" --dest default --detach
   

   The previous tree becomes:

   ...o--o--d--d--d   (default)
          \
           L--L    (local)
   

   The rebased changesets now belong to branch default. (With feature branches, add --keepbranches to the rebase command to retain the branch name). The new features no longer have any ancestors in local, and I can publish them with push -r default without dragging along the local revisions. (Never merge from local into default; only the other way around). If you forget to say -r default when pushing, no problem: Your push gets rejected since it would add a new head.

6. On the development server, I merge the rebased revs into local as if I’d just pulled them:

   ...o--o--d--d--d   (default)
          \        \
           L--L-----N    (local)
   

7. I can now create a new dev branch on top of local, and continue development.

This has the benefits that I can develop on a version-controlled, configured setup; that I don’t need to mess with patches; that previous configuration stages remain in the history (if my webserver stops working after an update, I can update back to a configured version); and that I only rebase once, when I’m ready to publish changes. The rebasing and subsequent merge might lead to conflicts if a revision conflicts with local configuration changes; but if that’s going to happen, it’s better if they occur when merge facilities can help resolve them.