On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea <j...@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>
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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
