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 al
2010/12/30 Terry Reedy :
> 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
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
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, m
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 n
> 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 m
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
> maintena
Le jeudi 30 décembre 2010 à 14:24 -0600, Benjamin Peterson a écrit :
> 2010/12/30 Antoine Pitrou :
> > On Thu, 30 Dec 2010 20:57:11 +0100
> > Éric Araujo wrote:
> >> Hi,
> >>
> >> One thing confuses me in this thread: Do the problems come from merging
> >> across different versions (i.e. different
2010/12/30 Antoine Pitrou :
> On Thu, 30 Dec 2010 20:57:11 +0100
> Éric Araujo 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 peo
On Thu, 30 Dec 2010 20:57:11 +0100
Éric Araujo 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
> a merge tool
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 S
On Fri, 31 Dec 2010 02:54:26 +0900, "Stephen J. Turnbull"
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.
> For cherypicki
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 t
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 tra
On Thu, 30 Dec 2010 14:42:48 +0900, "Stephen J. Turnbull"
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 that the
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 porti
On Wed, 29 Dec 2010 23:12:28 +0900, "Stephen J. Turnbull"
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
> many cases the
2010/12/29 Georg Brandl :
>>> 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 branches,
Am 29.12.2010 15:17, schrieb Amaury Forgeot d'Arc:
> 2010/12/29 Georg Brandl :
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 David Cournapeau :
> On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
> wrote:
>> 2010/12/29 David Cournapeau
>>>
>>> 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.co
2010/12/29 Georg Brandl :
>>> 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 course
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 f
On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
wrote:
> 2010/12/29 David Cournapeau
>>
>> 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
Am 29.12.2010 11:09, schrieb Amaury Forgeot d'Arc:
> 2010/12/29 Georg Brandl :
>>> 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 no
2010/12/29 Georg Brandl :
>> 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,
> features to t
Am 29.12.2010 10:53, schrieb Amaury Forgeot d'Arc:
> 2010/12/29 Georg Brandl
>>
>> 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 mer
On Wed, Dec 29, 2010 at 10:53, Amaury Forgeot d'Arc 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
___
Python-Dev mailing
2010/12/29 Georg Brandl
>
> 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 cluttering th
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
> pa
2010/12/29 David Cournapeau
> 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 cannot
> easi
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 s
On Wed, Dec 29, 2010 at 9:13 AM, Amaury Forgeot d'Arc
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 would have t
32 matches
Mail list logo
