Advice re. implementing Mercurial

[David Capps]

-----Original Message-----
From: Martin Geisler [mailto:martin at geisler.net] 
Sent: 08 February 2015 13:08
Subject: Re: Advice re. implementing Mercurial

> (rebasing as necessary to avoid pulling in unapproved changes).

This step is not going to be as smooth as you hope. When changesets have been pushed to another repository, they are normally moved from the "draft" phase to the "public" phase. Rebase will not let you operate on public changesets -- since they've already been shared and thus shouldn't be modified.

The "changeset evolution" concept will help remove this limitation in a safe way, but as far as I know, the extension is still considered experimental and is not as polished as the rest of Mercurial.

> In an ideal world every change within a given period is signed off, in 
> which case it's easy to just pull all the changes up to a given point; 
> in practice I assume QA may pass a number of changes and reject some 
> others; I think rebase can help us cope with that...?

In general, rebasing is a local process, it's something you do to your local repository to move commits around. You typically do this when your commits are behind the latest head of the branch:

  $ hg pull # adds 10 new commits that made it through the QA process
  $ hg rebase # moves your local commits on top of the new commits

When you begin submitting your commits for review (and if you submit them with "hg push" to some remote repo) it's too late to rebase.

=======================================================================================

Hi Martin,

Yes, I've found this out while testing our setup here; rebase certainly won't work for us since QA only pick things up after they've been pushed to a public (Development) tree.

Graft does appear to, though. Essentially the situation we're thinking of is that various developers have pushed up 5 changes over the past day or so, merging their changes into head on the Development tree, and then QA approves 3 of the 5 to move forwards (and potentially not the first 3 changes that were pushed up to Development. Obviously if that situation does happen, then happy days, things are trivial). While I haven't tried grafting *large* changesets, my testing worked fine using it to pick out arbitrary changes from Development and merging them into head on Release.

I'll take a quick look at evolution, but if it's experimental, and since graft appears to do what we want, I'll probably start off on the assumption that graft will be used [where necessary] for our process.


Cheers,

David Capps