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 <[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
--
Christian Tismer :^) <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
