[Stackless] bitbucket processes

Richard Tew richard.m.tew at gmail.com
Mon Jan 6 21:45:36 CET 2014


I find git and hg interchangeable.  What I'd like to know how to do
with hg, is when I do an hg pull, it tells me the ongoing process with
bytes transferred and other updated statistics, like git does.

Cheers,
Richard.

On 1/7/14, Christian Tismer <tismer at stackless.com> wrote:
> 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/
>
>
> _______________________________________________
> Stackless mailing list
> Stackless at stackless.com
> http://www.stackless.com/mailman/listinfo/stackless



More information about the Stackless mailing list