Am 17.03.2011 06:14, schrieb R. David Murray: > 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>
Uh... wouldn't using the rebase extension make this much easier? Georg _______________________________________________ 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
