On Mon, Apr 11, 2011 at 6:58 AM, Neil <n
...@parkwaycc.co.uk> wrote:
> John O'Duinn wrote:
>> 2) Pull from m-c to a new head on aurora. Note exact changesets used, as
>> this will be needed for next drop.
> Won't this want to pull on to the head created from the last pull that you
> tried to close in step 8 last time?
I think the key here is to think of each head of Aurora like a
relbranch in our previous model. We'll pull m-c into Aurora, say
changeset XYZ winds up being the head. Then we land version
bumps/backouts/whatever else on top of XYZ, to make changeset XYZ123
the head, which winds up being Firefox 5 later down the road. Then,
when we're ready to take the next m-c pull, changeset XYZ will be the
common ancestor, with all the descendant changesets that landed on top
of it on m-c, with new head ABC. The head XYZ123 will be closed, and
ABC is the new head, rinse and repeat.
>> 3) Query hg.m.o for list of changes since known changeset / tag of the
>> previous drop.
> Is this not the same as doing hg incoming first, or have I misunderstood?
AFAICT, the point is to get all the changes that landed on top of the
previous common ancestor, so the descendants of XYZ in my previous
example.
-Ted