<br><br><div class="gmail_quote">On Wed, Mar 16, 2011 at 10:14 PM, R. David Murray <span dir="ltr"><<a href="mailto:rdmurray@bitdance.com">rdmurray@bitdance.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea <<a href="mailto:jcea@jcea.es">jcea@jcea.es</a>> wrote:<br>
> On 17/03/11 04:41, R. David Murray wrote:<br>
> > Dealing with a null merge when someone else has committed between the<br>
> > time I started the merge dance (I always pull just before I start that)<br>
> > and the time I push is not that hard either. It pretty much amounts to<br>
> > having to do an additional set of merges. (In my case I do a strip and<br>
> > restart my merge dance, but I'm not sure I should recommend that since<br>
> > altering history is considered dangerous :).<br>
><br>
> Could you possibly describe your current approach, marking it with a<br>
> huge "NOT SAFE; AT YOUR OWN RISK" banner?. I wonders how other people<br>
> manage this.<br>
><br>
> I too do a "pull" before doing the merge, but I don't push each merge<br>
> separatelly but I do the all the merges locally and then do an unique<br>
> push. Than can take some time, moreover if I run the complete testsuite<br>
> in all changed branches. Resolving a "+1 head" here is tricky, if I<br>
> *WANT* the other developer to manage her own merging by herself. As it<br>
> should.<br>
<br>
</div>Yes, running the entire test suite puts rather a delay into the process.<br>
Generally what I do is run the full test suite in the first branch I'm<br>
patching, and then only run the specific test suite in the other branches<br>
during the merge. This is a bit suboptimal since default will have more<br>
code and more tests for that code than the source branch, but I figure<br>
the buildbots will yell if something was missed. On the other hand,<br>
when we aren't in sprint-commit-frenzy, I may run the full test suite<br>
on default before doing the push.<br>
<br>
OK, so BIG DISCLAIMER: TRY THIS AT YOUR OWN RISK :)<br>
<br>
My setup is using the share extension. This means I have one repository<br>
with multiple checkout directories. I also have one pristine clone<br>
of cpython in case I screw up and need to recreate my share setup.<br>
The share setup looks like this:<br>
<br>
hg clone cpython p33<br>
hg share p33 p32<br>
hg share p33 p31<br>
hg share p33 p27<br>
cd p33; hg up default<br>
cd ../p32; hg up 3.2<br>
cd ../p31; hg up 3.1<br>
cd ../p27; hg up 2.7<br>
<br>
And then I build python in each branch checkout. With luck I only<br>
have to do this once (in practice I've had to do it twice so far,<br>
but I'm not really expecting to have to do it again, now that I've<br>
learned how things work).<br>
<br>
My working process is to cd into the checkout for the branch I'm<br>
patching first (usually 3.1), and do an hg pull followed by an hg up.<br>
(It's important the this be two separate commands rather than an hg<br>
pull -u because this is a shared setup: pull -u won't update the local<br>
working copy if there are no changesets pulled, while hg up updates<br>
it unconditionally.) I then apply the patch, and do whatever testing<br>
and fixing and NEWS and ACK entries I need, including running the full<br>
tests suite. When I'm satisfied, I start the merge dance:<br>
<br>
do hg pull; hg up (I could use hg<br>
pull -u here since I know I haven't done a pull in some other checkout).<br>
<br>
Then I:<br>
<br>
hg diff >temp.patch<br>
hg pull<br>
hg up<br>
hg ci<br>
cd ../p32<br>
hg up<br>
hg merge 3.1<br>
[run tests applicable to the patch]<br>
hg ci<br>
cd ../p33<br>
hg up<br>
hg merge 3.2<br>
[run tests applicable to the patch]<br>
(if needed:<br>
cd ../p27<br>
hg up<br>
patch -p1 <../p31/temp.patch<br>
[fix and test]<br>
[if there were a bunch of changes, hg diff >temp.patch]<br>
hg ci<br>
)<br>
hg pull<br></blockquote><div><br></div><div>why do you use hg diff and patch above rather than hg export and hg import?</div><div><br></div><div>(not implying one is better than the other, learning here...)</div><div>-gps</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
If this pull shows no changesets, I do an hg push.<br>
<br>
The fun part comes if there are changesets. At this point there<br>
are two options: go through each of the branches doing an up/merge/ci,<br>
and then pull/push. Or, what I actually do:<br>
<br>
hg log<br>
hg strip <the changeset id of my first checkin><br>
<br>
Then I start from the top of the section above, but starting by reapplying<br>
my temp.patch. There's one other detail, though: because I'm using<br>
share, the checkouts lose their parent id when I do the strip. So in<br>
each checkout I also need to do 'hg debugsetparent <branch>' before<br>
doing the hg up.<br>
<br>
Clearly, this procedure is not for everyone, and I may decide it is<br>
not for me by and by. But it has worked well so far during the<br>
sprints. There's also some room for automation here.<br>
<br>
I think part of the reason I like it is that it is fairly close to the<br>
workflow I had for svn, except the merges go in the opposite direction<br>
and they go a *lot* faster. 2.7, though, is more of a pain than with<br>
svn because I have to use patch instead of getting the nice merge markers<br>
that svnmerge gave me. And I prefer to do all the merges and then push<br>
(rather than push-per-merge like Ezio) because I have all the way until<br>
that final push to realize I've made a mistake.<br>
<br>
Which reminds me: I said I'd hit a race twice during the sprints, but<br>
that isn't true. It was only once. The other time I used strip,<br>
it was because I realized just before the push that I'd screwed up<br>
the patch, so I went back and started over. To me that's a definite<br>
benefit of hg over svn.<br>
<br>
The roundup update hook is also very lovely :)<br>
<div class="im"><br>
--<br>
R. David Murray <a href="http://www.bitdance.com" target="_blank">www.bitdance.com</a><br>
_______________________________________________<br>
</div><div><div></div><div class="h5">Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/python-dev" target="_blank">http://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="http://mail.python.org/mailman/options/python-dev/greg%40krypto.org" target="_blank">http://mail.python.org/mailman/options/python-dev/greg%40krypto.org</a><br>
</div></div></blockquote></div><br>