I'm sure most every ON developer has now suffered through the horrible
experience of being ready to integrate and doing a push only to discover
someone else has beaten them to the punch. Once this happens, we must go
through the mechanical and tedious process of
hg pull
hg merge
hg commit -m 'useless comment'
hg recommit (strip out useless comment)
... which itself can take several minutes when the gate and developer repo
are distant. In the meantime, someone else may again beat them to the
punch. I spent about two hours in this spin loop this morning, wasting
time thanks to this *dreadful* model that does not scale to our needs.
I was still fuming about this experience at lunch when Jonathan Adams
raised an alternative: given that the above is entirely mechanical, why
can't the gate do it for us? That is, why cant the hg push logic see that
there are other changesets but that none of them have conflicting files,
and do the above dance for the developer?
Yes, there is a chance that this *might* lead to a damaged gate (e.g.,
if there is a cross-file dependency, such as an API change). However:
* This already the case with the mechanical dance above. (Most
developers don't even rebuild -- let alone retest -- after doing
the dance above. If they did, they'd never get to integrate.)
* Teamware always had this risk, and yet development worked quite
well. I can't recall this ever actually leading to breakage.
So how about it?
--
meem
