Advice re. implementing Mercurial

BOGGESS Rod CORE Rod.Boggess at tenova.com
Fri Feb 6 17:04:11 UTC 2015



Tenova: advanced technologies for the metals and mining industries
Visit our website at www.tenova.com
------------------------------------------------------------------
Confidentiality Notice : This message, together with its attachments, contains strictly confidential information and is intended only for the addressee identified above,who is the sole party authorized to use
 and copy it and, assuming any related liability , to forward it to others. Anyone receiving this message by mistake or reading it without authorization is hereby notified that storage, reproduction, disclosure or distribution of the message to persons other than the addressee is strictly forbidden. They are asked to return the message immediately to the sender and to erase the original message received.
Thank you.


-----Original Message-----

Just following on from this, it looks like rebase doesn’t do what we want (since it won’t operate on public changes, and we’re only selecting which changes to move forwards *after* they've been published to our Development tree and QA have had a chance to break them), but graft does seem to do exactly what we want.

-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-

I always wondered how the lieutenants (gatekeepers, etc.) in Open Source (like Mercurial) managed patches. I always assumed they received a patch, sucked it into MQ, applied it atop the development branch and decided if it solved the problem, then decided to commit it or delete the patch that way. But it's clear that most of the folks here (including at the lieutenants) don't really use MQ extensively.

So, anyone here care to share? How do you do QA in Open Source without hopelessly corrupting the repo's history?


More information about the Mercurial mailing list