Advice re. implementing Mercurial

[Martin Geisler]

David Capps <dcapps at keystonesoftware.co.uk> writes:

Hi David,

> -There is also a Release tree on the company server. Developers don't
> push directly to this: once QA have signed off a number of changes, a
> senior developer will pull those changes into Release

That sounds good.

> (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.

You'll then begin merging instead -- the merge is what incorporates the
commits with the current head of development.

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150208/7f8cc0f6/attachment.asc>