Sunday, March 15, 2009

Bespin, Mercurial and keeping your patch up-todate

While hacking on bespin I experimented some of the possible ways to keep a patch in sync with tip (this is how they call "trunk" in hg land).

Just cloning the repo for developing the patch

this is the easiest, and seems quite popular. Unfortunately you are switching physical directories when you switch between clones, and in the case of bespin, where running server-instances are tied to a physical directory, it requires either a smart approach for running the instances in parallel or easily shutting down one and starting up he other. And if you are working on different unrelated patches, it can get quite messy to do manual merges when tip changes. To sum up, easy to get started with, but lots of disadvantages.

Using branches

Branches are easy to create and easy to switch between them and they have one big advantage compared to cloning: You stay on the same physical directory if you switch branches. However, the pain of manual merges when tip changes seemed to me even worse than with cloning.

Using queues extension

this is currently my preferred way. With queues extension you have always a clean tip, can develop patches, apply them, remove them, apply /remove patch-sets and easily change the order of the patches in the set. Updating tip is as easy as:

hg qrefresh # update current patch with local changes
hg qpop -a # remove all patches
hg pull
hg update
hg qpush -a # apply all patches

What I haven't figured out yet is how to use bundles with queues extensions.

Update:
By enabling rebase extension, rebasing with tip got even easier. The lines above got reduced now to:

hg qrefresh # update current patch with local changes
hg pull --rebase

Update II:
Lately I just push my local repo with applied MQ patches to my personal public repo at bitbucket, with the purpose of facilitating the pull of my patches.

No comments: