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/
_______________________________________________ Stackless mailing list [email protected] http://www.stackless.com/mailman/listinfo/stackless
