On Wed, Mar 16, 2011 at 10:14 PM, R. David Murray <rdmur...@bitdance.com>wrote:
> 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 > 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@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org >
_______________________________________________ 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