Advice re. implementing Mercurial

[Martin Geisler]

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

>> 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.
>
> Hm, OK. My worry with that was we end up with a *lot* of heads and
> then the merge process gets done by QA at a future point, rather than
> by the developer who actually wrote the code just after they've
> finished writing it (and have the changes fresh in their mind so are
> more likely to spot potential merge issues).

That is a very fair worry -- merges are often best done by the people
who wrote the code.

However, you can still let the developers do the merge: you can ask the
person responsible for a given branch to do the merge and push it to his
branch. He does this after QA has had a change to look at the code and
said that they want it included in the next release. After the merge, QA
should probably test things again -- maybe they can run smaller tests
now since they've already tested the feature in isolation (but beware of
how the change interacts with other changes that were merged after the
developer started his branch).

> But I can see that it keeps the tree much cleaner this way.

I think the result will be a more branchy repository than what you had
hoped to achieve with the post-push rebasing or grafting. However, this
history flow will be append-only, which is really the best way to work
with a DVCS.

> Probably we need to actually try using Mercurial in anger and see what
> happens.



-- 
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/ca8b76eb/attachment.asc>