[Python-Dev] Backport troubles with mercurial (original) (raw)
Georg Brandl g.brandl at gmx.net
Wed Dec 29 11:00:59 CET 2010
- Previous message: [Python-Dev] Backport troubles with mercurial
- Next message: [Python-Dev] Backport troubles with mercurial
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Backport troubles with mercurial
- Next message: [Python-Dev] Backport troubles with mercurial
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]