[Stackless] bitbucket processes

Christian Tismer tismer at stackless.com
Mon Jan 6 21:42:32 CET 2014


Howdy,

now I think I _have_ understood it after quite a long search, from

http://docs.python.org/devguide/faq.html#how-do-i-make-a-null-merge

but it was not very understandable before I looked up the options to see
what it does (docs written by someone who knows too much).

So the trick is to do a merge and throw the changes away, to make hg shut up
and stop trying to merge. Waah...

did I mention that I like git better meanwhile? ;-)

cheers & thanks -- Chris


On 06.01.14 19:09, Christian Tismer wrote:
> 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 <kristjan at ccpgames.com> 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:tismer at stackless.com]
>> 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:tismer at stackless.com><mailto:tismer at stackless.com>
>>
>> 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
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless


-- 
Christian Tismer             :^)   <mailto:tismer at stackless.com>
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/




More information about the Stackless mailing list