I have still not understood the null-merge thing, but the merge (with a few grafts) to 2.8-slp worked fine so far.
Sent from my Ei4Steve > On Jan 6, 2014, at 16:59, Kristján Valur Jónsson <[email protected]> > wrote: > > Yes. cPython uses merges between branches of the 2.x family, and of the 3.x > family. But to get a change/fix over from 2 to 3, it is grafted. > This is they have diverged too much for branching/merging to be effective, I > think. > > For 2.7 to 2.8 I would merge. > > aside: > Note that there is this thing called a “null merge”. this produces a merge > without changing any destination files, effectively setting the starting > position for future merges. > When I had merged 3.2 to 3.2-slp and 3.3. to 3.3-slp, I had to do this. > Normally, a merge from 3.2-slp to 3.3-slp would only bring over the recent > stackless-only changes. But after merging from cPython, suddenly there was a > lot of non-stackless changes that a merge between the branches would have > caused to happen (for whatever reason that is). To reset the merge status, I > did a null-merge between 3.2-slp to 3.3-2lp. > Basically, once you have your two branches in a state where you want merging > to produce no change to the target, but the merge algorithm still wants to > bring something over, you perform a null merge to reset it…. > </aside> > > I don’t know what the state is of 2.8-slp vs. 2.7-slp or when it was branched > off, but I imagine that it should just merge fine. > > From: Christian Tismer [mailto:[email protected]] > Sent: 6. janúar 2014 13:42 > To: The Stackless Python Mailing List; Kristján Valur Jónsson > Subject: Re: [Stackless] bitbucket processes > > On 06.01.14 13:32, Kristján Valur Jónsson wrote: > Hi, I just wanted to discuss our practices on BitBucket. > While the repo is still private, we who have access should probably stick to > some guidelines. > > > 1) Commit comments should include ticket references, so that we get > proper cross-references: > https://confluence.atlassian.com/display/BITBUCKET/Mark+up+comments%2C+issues%2C+and+commit+messages > and > https://confluence.atlassian.com/display/BITBUCKET/Resolve+issues+automatically+when+users+push+code > In particular, when a commit is pertaining to a ticket, use the “re #34” > syntax or equivalent. This should cause a link to the changeset to be > automatically added to the issue. > > 2) Python 3 support: IMHO, contributors should be responsible > themselves for porting changes/fixes to the other branches, much as is the > case for cPython development. For a change made in 2.7-slp, that change > should be grafted to 3.2-slp. 3.2-slp should then be „merged“ into 3.3-slp. > (once we drop 3.2-slp, we will graft directly to 3.3-slp) 3.2 is still > VS2008 and should be compilable and testable by all. > If we don‘t do this, we run the risk of divergence. I have been doing > synchronization sessions from time to time trying to port stuff over, but it > is easy to lose track, and it shouldn‘t be the responsibility of one person > to keep our branch tree in sync. > > 3) All fixes/changes should be accompanied by a unittest by now. > > 4) We should probaby try to write the unittests in a 2/3 neutral mode > (i.e. use from __future__ import print_statement). This will allow us to > diff the unittests between branches more easily and thus discover any > discrepancy. They should really be the same. Running the _same_ unittests > in different branches should then help us ensure that point 2) is adhered to > above. > > Thoughts? > > I just tried graft for the first time, and I see how it replays patches > exactly. > What is best to do for 2.8: merge or graft? > > I started merging, then reverted and tried graft. > Confused - merge is probably better here? > > cheers - Chris > > > -- > > Christian Tismer :^) > <mailto:[email protected]><mailto:[email protected]> > > Software Consulting : Have a break! Take a ride on Python's > > Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ > > 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de > > phone +49 173 24 18 776 fax +49 (30) 700143-0023 > > PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 > > whom do you want to sponsor today? http://www.stackless.com/ > <winmail.dat> _______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
