On Dec 30, 2010, at 02:50 AM, R. David Murray wrote:
You are welcome; thanks for the feedback. (I sometimes feel
like I'm working in a bit of a vacuum, though Barry does chime in
occasionally...but I do realize that people are busy; that's
why I inherited this job in the first place, after all
R. David Murray writes:
I thought Amaury was saying it was harder than svnmerge, not harder
than patching by hand (ie: that it *was* patching by hand, including
.rej files and the lack of tracking). I also heard Georg say that this
should be fixable, and that he's partly fixed the
Am 30.12.2010 18:54, schrieb Stephen J. Turnbull:
R. David Murray writes:
I thought Amaury was saying it was harder than svnmerge, not harder
than patching by hand (ie: that it *was* patching by hand, including
.rej files and the lack of tracking). I also heard Georg say that this
On Fri, 31 Dec 2010 02:54:26 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
I don't see why the tracking issue is any different than it would be
for svn. If you're actually merging, either a dummy merge (what git
Martin already said most of what I would have in response to your
post.
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems that come up because people don’t want to use
a merge tool? I for one immensely like Mercurial’s merge and utterly
dislike
On Thu, 30 Dec 2010 20:57:11 +0100
Éric Araujo mer...@netwok.org wrote:
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems that come up because people don’t want to use
2010/12/30 Antoine Pitrou solip...@pitrou.net:
On Thu, 30 Dec 2010 20:57:11 +0100
Éric Araujo mer...@netwok.org wrote:
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems
Le jeudi 30 décembre 2010 à 14:24 -0600, Benjamin Peterson a écrit :
2010/12/30 Antoine Pitrou solip...@pitrou.net:
On Thu, 30 Dec 2010 20:57:11 +0100
Éric Araujo mer...@netwok.org wrote:
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different
Am 30.12.2010 19:31, schrieb Martin v. Löwis:
But using the adapted workflow simply requires learning new names for
old operations. Annoying, but it will make a fair number of core devs
quite happy.
I think the new workflow will simply result in (even) less care for the
maintenance
Also, it's not really necessary for everyone to merge every change from
maintenance to trunk: a) they can do multiple commits on the same
subject and merge once, and b) if the change is small and no problems can
be expected from merging, merging can also be done by others, just like
the mass
Am 30.12.2010 20:57, schrieb Éric Araujo:
Hi,
One thing confuses me in this thread: Do the problems come from merging
across different versions (i.e. different syntax and module names), or
are they regular problems that come up because people don’t want to use
a merge tool?
Neither nor.
Am 30.12.2010 22:38, schrieb Martin v. Löwis:
Also, it's not really necessary for everyone to merge every change from
maintenance to trunk: a) they can do multiple commits on the same
subject and merge once, and b) if the change is small and no problems can
be expected from merging, merging
On 12/30/2010 4:44 PM, Georg Brandl wrote:
But you can't use Mercurial's merge functionality for that, right?
You have to use some kind of transplant/cherry-picking to merge from the
3.3 branch to the 3.2 branch, right?
Oh, I wrote the above assuming 3.2-3.3 merging. For the other direction
2010/12/30 Terry Reedy tjre...@udel.edu:
On 12/30/2010 4:44 PM, Georg Brandl wrote:
But you can't use Mercurial's merge functionality for that, right?
You have to use some kind of transplant/cherry-picking to merge from the
3.3 branch to the 3.2 branch, right?
Oh, I wrote the above assuming
Am 29.12.2010 01:13, schrieb Amaury Forgeot d'Arc:
Hello,
The PyPy project recently switched from svn to mercurial. Since this day I
have some
difficulties to perform simple tasks, and my questions did not receive
satisfying answers.
I was sure the Python project would have the same
2010/12/29 David Cournapeau courn...@gmail.com
The easiest way I found to emulate git cherry-pick (which does exactly
what you want) with hg is to use import/export commands:
http://mercurial.selenic.com/wiki/CommunicatingChanges
It is indeed quite a pain to use in my experience, because you
Am 29.12.2010 09:02, schrieb Amaury Forgeot d'Arc:
I've read all this, and this method does not work, for several reasons:
- py3k / 2.7 / 3.1 cannot be ordered, there is no earliest possible parent..
we usually consider py3k as a child of both 2.7 and 3.1, and there is no
common
parent.
2010/12/29 Georg Brandl g.bra...@gmx.net
Am 29.12.2010 09:02, schrieb Amaury Forgeot d'Arc:
- even if there was one, there is the problem of changes specifically made
for 2.7
that make no sense in py3k. You'd have to perform a dummy merge to py3k
which has the disadvantage of
On Wed, Dec 29, 2010 at 10:53, Amaury Forgeot d'Arc amaur...@gmail.com wrote:
And http://hg.python.org/cpython/ probably needs an initial dummy merge
on every branch.
Yes, the present delays are all about getting that right.
Cheers,
Dirkjan
___
Am 29.12.2010 10:53, schrieb Amaury Forgeot d'Arc:
2010/12/29 Georg Brandl g.bra...@gmx.net
Am 29.12.2010 09:02, schrieb Amaury Forgeot d'Arc:
- even if there was one, there is the problem of changes specifically made
for 2.7
that make no sense in py3k. You'd have to perform a dummy
2010/12/29 Georg Brandl g.bra...@gmx.net:
What worries me more is the requirement to find the correct branch before I
can
even edit the file. How would you, Georg, deal with doc patches
(typos, bad markup)?
Finding the correct branch is not really hard. Bugfixes go to maintenance,
Am 29.12.2010 11:09, schrieb Amaury Forgeot d'Arc:
2010/12/29 Georg Brandl g.bra...@gmx.net:
What worries me more is the requirement to find the correct branch before I
can
even edit the file. How would you, Georg, deal with doc patches
(typos, bad markup)?
Finding the correct branch is
On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2010/12/29 David Cournapeau courn...@gmail.com
The easiest way I found to emulate git cherry-pick (which does exactly
what you want) with hg is to use import/export commands:
Amaury Forgeot d'Arc writes:
Which precise steps do you take [to cherrypick with export/import]?
hg export -r $CHERRY .tmp.patch
xemacs .tmp.patch
;; Move to end of log message, type Cherry-picked from: , then
;; C-u M-! hg id -i -r $CHERRY RET C-x C-s C-x C-c
hg import .tmp.patch
worked for
2010/12/29 Georg Brandl g.bra...@gmx.net:
You need to think about which category your change is
right now too, when deciding what to backport/svnmerge.
No, today this decision can take place after the development,
some tickets got reopened because a backport was needed.
A change can of
2010/12/29 David Cournapeau courn...@gmail.com:
On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
2010/12/29 David Cournapeau courn...@gmail.com
The easiest way I found to emulate git cherry-pick (which does exactly
what you want) with hg is to use import/export
Am 29.12.2010 15:17, schrieb Amaury Forgeot d'Arc:
2010/12/29 Georg Brandl g.bra...@gmx.net:
You need to think about which category your change is
right now too, when deciding what to backport/svnmerge.
No, today this decision can take place after the development,
some tickets got reopened
2010/12/29 Georg Brandl g.bra...@gmx.net:
A change can of course also be transplanted after the fact. It requires
another
merge, but usually a trivial one.
No, it's not trivial with hg: this is the very subject of the thread!
I don't understand: if you make the same change in two
On Wed, 29 Dec 2010 23:12:28 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
worked for me the one time I tried it, IIRC. Now I use patch queues,
and avoid cherry-picking as much as possible. (Avoiding cherry-pick
is not going to be possible for 3.x - 2.x porting, of course, but in
R. David Murray writes:
We merge bug fixes to 2.7 on a routine basis. It is the rule rather
than the exception, by a long shot.
For bugfixes, of course it's routine. I understand that. My point
was that the case Amaury fears, where the (new) VCS makes things
harder than patching or
On Thu, 30 Dec 2010 14:42:48 +0900, Stephen J. Turnbull step...@xemacs.org
wrote:
R. David Murray writes:
We merge bug fixes to 2.7 on a routine basis. It is the rule rather
than the exception, by a long shot.
For bugfixes, of course it's routine. I understand that. My point
was
Hello,
The PyPy project recently switched from svn to mercurial. Since this day I
have some
difficulties to perform simple tasks, and my questions did not receive
satisfying answers.
I was sure the Python project would have the same issues;
so I started from the repositories in
On Wed, Dec 29, 2010 at 9:13 AM, Amaury Forgeot d'Arc
amaur...@gmail.com wrote:
Hello,
The PyPy project recently switched from svn to mercurial. Since this day I
have some
difficulties to perform simple tasks, and my questions did not receive
satisfying answers.
I was sure the Python project
33 matches
Mail list logo
