Using Mercrial and breaking changeset up

Martin Geisler mg at aragost.com
Mon Jun 20 02:34:43 CDT 2011


Zak <ZakHurst at hotmail.com> writes:

Hi Zak

>   1. We have been use to working on individual files, but this gave us
> the flexability to decide what gets included in a release, we want to
> selectively apply a change on a branch and merge it in on the tip or
> another stream.

Since you talk about a "stream", are you coming from ClearCase?

> Similarly some changes done on a development we want to exclude from a
> build, this is rare but importnat and it happens close to the release
> date, needed to allow us to get through testing, this is like
> reverting a change, but really we need to tag a revision of a specific
> file level to be included in a release. Now we would and do take all
> the changes/revisions in sequnece i.e. take rev. 1,2,3 not 1,2,4. The
> result of taking 1,2,3 might mean pushing the changes made in 4 on to
> a future release/branch, we currently do this using a promotion model,
> so a change gets approved before we put it into the formal build, we
> hoped the gatekeeper model would allow us to do this, but this does
> not seem to be the case.

To "promote" a changeset in Mercurial you can

* merge the changeset into a certain branch

* push the changeset into a certain repository

Both methods have the same overall effect: the changeset itself and its
ancestors are now promoted. Since you say you take changes 1, 2, 3 and
not 1, 2, 4, then this would work for you: promote 1, 2, 3 and leave 4
un-promoted.


We also sometimes promote changesets from the default to the stable
branch with the transplant extension for Mercurial. This happens when a
bugfix was made on default when it should instead have been made on
stable. The transplant extension lets us copy the changeset to the
stable branch. This should be an exception, though, since it results in
duplicate changesets (they are harmless in themselves, but they are a
symptom of using the tool wrongly).

> I am not sure if HG queues are the way to go.

The MQ extension is not the way forward. That extension is a great tool
for working with patches locally, but it quickly becomes complicated if
you want to share your patch queue with others.


-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/


More information about the Mercurial mailing list