Advice re. implementing Mercurial

[Martin Geisler]

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

> -----Original Message-----
> From: Martin Geisler [mailto:martin at geisler.net] 
> Sent: 09 February 2015 10:45
>
>> The traditional way to do this is really more of a take it all or take nothing approach.
>>
>>...
>>
>> This process goes on until QA is happy with the end result, namely
>> the diff from the very first commit to the last commit on this
>> branch. They then merge the code into the default branch -- so that
>> other developers can see the work and rebase their local branches on
>> top of it.
>>
>> Any other approach is bound to create extra cleanup steps. If I push
>> 5 commits and you graft 3 of them, well then I need to somehow get
>> rid of the two commits you > didn't pick. As I write below, the
>> evolve extension helps here.
>>
>> Everybody asks how to merge only commit 3 out of 5 commits and the
>> answer is "don't do that" since grafting it creates extra work. Try
>> instead to make developers > very conscious about not mixing
>> different lines of work together into one branch. Put refactorings
>> into a different branch than bugfixes and features.
>
> Thanks for the comments ... the problem is that I don't think
> all-or-nothing will work for us; if we released less frequently,
> perhaps, but as it is we release an updated version every[0] week[1].
> So we really can't be in a position where we've pushed 15 bugfixes
> into Development and none of them go out until all 15 pass QA - the
> option has to be there for QA to approve 11 of the fixes and hold back
> the other 4 for a future release.

The bugfixes should not go into the Development repository in one linear
string of commits. They should go in as a 15-headed monster -- each head
being pushed by the developer who made the urgent bugfix.

In other words, each bugfix will be made on the basic of the latest code
tested by the QA guys. After making a bugfix, you update back to this
head and make another:

  $ hg update latest-qa
  ... make bugfix ...
  $ hg commit -m 'Fixed last security problem'
  $ hg out -r .  # check if you're about to push what you expect
  $ hg push -f -r .  # you need -f since you'll be creating a new head

  $ hg update latest-qa
  ... make bugfix ...
  $ hg commit -m 'Made the thing work again'
  $ hg push -f -r .  # you need -f since you'll be creating a new head

The QA guys can then *merge* (not rebase or graft) precisely the
bugfixes that they like. Other bugfixes will be left behind as open
heads and the developers can then iterate on these branches until QA is
happy with the code.

> If we separated bugfixes into urgent / high / low priority branches I
> suppose that would potentially let us get around that - bugs already
> get classified on importance, of course - but I think we'd still have
> the same issue when a bug changed priority?

I think the grouping should be one branch/bookmark per bug. Don't try
and make bigger buckets than that.

> The same also applies to features, to some extent - we could quite
> easily have 5 new features land in Development in fairly short order,
> all of which were paid for by [potentially different] customers, and
> holding up 4 of them because the 5th failed QA *might* not be
> acceptable (obviously if we don't have customers waiting urgently for
> any of the 5, then great - we probably can wait until all 5 pass QA
> and merge them all at once).

Letting the features be separate topological or named branches (see 'hg
help glossary' if those names are strange) will solve this too: you
merge the features in any order you like.

> I can see graft is going to give us extra clean up work, but I don't
> currently see any way around that ... I think we'll certainly *aim* to
> approve changes without grafting, because why buy ourselves extra work
> if it's not necessary - but it looks like there's always going to be
> situations where we need to graft changes in.

I would try to forget about grafting for now. It's a tool made for a
different purpose than what you're trying to apply it to: it is used
when you have a change (a single commit) that you need to copy to
another branch.

This is typically the case when a bugfix is made on a development branch
by accident -- instead of being made on the production or bugfix branch
where it belonged. In that case you cannot simply merge the dev branch
into production since that would bring with it everything from the dev
branch (featurs not ready for release). Instead you use 'hg graft' to
selectively copy one or two commits from dev to prod.

So I don't recommend making a workflow around using graft all the time.
Like I said elsewhere, it will also lead to a buildup of cruft in your
intermediate repositories.

-- 
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/20150209/6c672f1c/attachment.asc>