[Python-Dev] Hg: inter-branch workflow

[Georg Brandl]

Am 17.03.2011 06:14, schrieb R. David Murray:
> On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea <jcea at jcea.es> wrote:
>> On 17/03/11 04:41, R. David Murray wrote:
>> > Dealing with a null merge when someone else has committed between the
>> > time I started the merge dance (I always pull just before I start that)
>> > and the time I push is not that hard either.  It pretty much amounts to
>> > having to do an additional set of merges.  (In my case I do a strip and
>> > restart my merge dance, but I'm not sure I should recommend that since
>> > altering history is considered dangerous :).
>> 
>> Could you possibly describe your current approach, marking it with a
>> huge "NOT SAFE; AT YOUR OWN RISK" banner?. I wonders how other people
>> manage this.
>> 
>> I too do a "pull" before doing the merge, but I don't push each merge
>> separatelly but I do the all the merges locally and then do an unique
>> push. Than can take some time, moreover if I run the complete testsuite
>> in all changed branches. Resolving a "+1 head" here is tricky, if I
>> *WANT* the other developer to manage her own merging by herself. As it
>> should.
> 
> Yes, running the entire test suite puts rather a delay into the process.
> Generally what I do is run the full test suite in the first branch I'm
> patching, and then only run the specific test suite in the other branches
> during the merge.  This is a bit suboptimal since default will have more
> code and more tests for that code than the source branch, but I figure
> the buildbots will yell if something was missed.  On the other hand,
> when we aren't in sprint-commit-frenzy, I may run the full test suite
> on default before doing the push.
> 
> OK, so BIG DISCLAIMER: TRY THIS AT YOUR OWN RISK :)
> 
> My setup is using the share extension.  This means I have one repository
> with multiple checkout directories.  I also have one pristine clone
> of cpython in case I screw up and need to recreate my share setup.
> The share setup looks like this:
> 
>     hg clone cpython p33
>     hg share p33 p32
>     hg share p33 p31
>     hg share p33 p27
>     cd p33; hg up default
>     cd ../p32; hg up 3.2
>     cd ../p31; hg up 3.1
>     cd ../p27; hg up 2.7
> 
> And then I build python in each branch checkout.  With luck I only
> have to do this once (in practice I've had to do it twice so far,
> but I'm not really expecting to have to do it again, now that I've
> learned how things work).
> 
> My working process is to cd into the checkout for the branch I'm
> patching first (usually 3.1), and do an hg pull followed by an hg up.
> (It's important the this be two separate commands rather than an hg
> pull -u because this is a shared setup: pull -u won't update the local
> working copy if there are no changesets pulled, while hg up updates
> it unconditionally.)  I then apply the patch, and do whatever testing
> and fixing and NEWS and ACK entries I need, including running the full
> tests suite.  When I'm satisfied, I start the merge dance:
> 
> do hg pull; hg up (I could use hg
> pull -u here since I know I haven't done a pull in some other checkout).
> 
> Then I:
> 
> hg diff >temp.patch
> hg pull
> hg up
> hg ci
> cd ../p32
> hg up
> hg merge 3.1
> [run tests applicable to the patch]
> hg ci
> cd ../p33
> hg up
> hg merge 3.2
> [run tests applicable to the patch]
> (if needed:
>  cd ../p27
>  hg up
>  patch -p1 <../p31/temp.patch
>  [fix and test]
>  [if there were a bunch of changes, hg diff >temp.patch]
>  hg ci
> )
> hg pull
> 
> If this pull shows no changesets, I do an hg push.
> 
> The fun part comes if there are changesets.  At this point there
> are two options: go through each of the branches doing an up/merge/ci,
> and then pull/push.  Or, what I actually do:
> 
> hg log
> hg strip <the changeset id of my first checkin>

Uh... wouldn't using the rebase extension make this much easier?

Georg