[Python-Dev] Hg: inter-branch workflow

[Gregory P. Smith]

On Wed, Mar 16, 2011 at 10:14 PM, R. David Murray <rdmurray at bitdance.com>wrote:

> 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
>

why do you use hg diff and patch above rather than hg export and hg import?

(not implying one is better than the other, learning here...)
-gps


>
> 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>
>
> Then I start from the top of the section above, but starting by reapplying
> my temp.patch.  There's one other detail, though:  because I'm using
> share, the checkouts lose their parent id when I do the strip.  So in
> each checkout I also need to do 'hg debugsetparent <branch>' before
> doing the hg up.
>
> Clearly, this procedure is not for everyone, and I may decide it is
> not for me by and by.  But it has worked well so far during the
> sprints.  There's also some room for automation here.
>
> I think part of the reason I like it is that it is fairly close to the
> workflow I had for svn, except the merges go in the opposite direction
> and they go a *lot* faster.  2.7, though, is more of a pain than with
> svn because I have to use patch instead of getting the nice merge markers
> that svnmerge gave me.  And I prefer to do all the merges and then push
> (rather than push-per-merge like Ezio) because I have all the way until
> that final push to realize I've made a mistake.
>
> Which reminds me: I said I'd hit a race twice during the sprints, but
> that isn't true.  It was only once.  The other time I used strip,
> it was because I realized just before the push that I'd screwed up
> the patch, so I went back and started over.  To me that's a definite
> benefit of hg over svn.
>
> The roundup update hook is also very lovely :)
>
> --
> R. David Murray                                      www.bitdance.com
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20110316/a62d524b/attachment.html>