[Python-Dev] Backport troubles with mercurial

[Georg Brandl]

Am 29.12.2010 10:53, schrieb Amaury Forgeot d'Arc:
> 2010/12/29 Georg Brandl <g.brandl at 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 cluttering the py3k change log. And think of the
>> > horror
>> > if someone forgets this dummy merge.
>>
>> No horror at all: the next committer notices the extra changes in his merge and
>> removes them.  *Never* commit merges without reviewing the diff.  (The
>> situtation is similar, by the way, to someone typing the wrong revision number
>> when using svnmerge, and not noticing it because he does not review the diff.)
> 
> Except that it's easy to overlook a diff and not notice another small change
> mixed in your merge. Checking "hg merge -P" is probably better.
> But is it possible to "remove" the extra change?

No; hg merging is DAG-based, so you will always merge all ancestors.  The only
way to "remove" it is a null-merge.

> 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 trunk.  You need to think about which category your change is
right now too, when deciding what to backport/svnmerge.

Accordingly, I would apply doc patches in release31-maint and merge them
to trunk, probably all at once with one merge commit.

>> > - in any case, the actual repositories in http://code.python.org/hg/ are not clones
>> > of each other, so "hg merge" won't work and "hg pull" will clone the whole
>> > remote repository.
>>
>> Note that the repos on code.python.org are not the results of our conversion
>> process.  Those will be on hg.python.org.  The former are repos contributed
>> by Antoine (I think) that he uses with hgsubversion to work on Python using
>> Mercurial right now; they will disappear after hg.python.org works.
> 
> ok. I used them because other the repos I found were really old.
> And http://hg.python.org/cpython/ probably needs an initial "dummy merge"
> on every branch.

Yes, that is a very old conversion result.  We should get a new one in a few days.

Georg