Strategies for push/merge problem?

[Peter Arrenbrecht]

On Tue, Jul 22, 2008 at 9:29 PM, Risto Kankkunen
<risto.kankkunen at gmail.com> wrote:
> Douglas Philips <dgou <at> mac.com> writes:
>> Sounds like you want to have intermediate commits collapsed before
>> they are pushed. That is certainly one policy. Another policy is that
>> a set of changesets which are pushed together should not fail the
>> testsuite. There is work going on with the group-ing extension which
>> formalizes this since some find it is useful to have the extra meta-
>> data made explicit.
>
> Regulating what can be pushed or committed goes against many of the benefits of
> DVCS and can make it harder to review the history later. The grouping extension
> could indeed be used to collect incremental changes into coherent chunks.
>
> However, I'm wondering couldn't you use branches in Mercurial for the same
> thing: develop, commit and push your changes to a separate branch until they are
> stable enough and pass the test suite before merging into the mainline. Anyone
> care to comment does this work in practice?

Cannot say for sure yet, but I am experimenting with using
conceptually stacked branches as a replacement for mq when developing
patches. This is inspired by bzr's loom extension [1] and daggy fixes
[2]. The basic idea is to develop each patch in a separate branch. So
you can keep track of changes to patches (after reviews, for instance)
in a simple and easy-to-review fashion. And it's likely going to be
far easier to collaborate on patches than using versioned
.hg/patches/.

However, to submit the work I currently think I would just generate a
diff from a patch branch's base to its tip and submit that. So the
intermediate history would get lost on submission. Grouped csets could
avoid this loss, if one wants to keep the info.

Shall announce again when I have more concrete experience and code to show.

[1] https://launchpad.net/bzr-loom
[2] http://www.venge.net/mtn-wiki/DaggyFixes

-parren