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.
Yes. Think of 2.7 as the oddball one, where revisions must be cherry-picked to, whereas the 3.x line can use the "commit in parent branch" system (and much more easily, since there are no changes in syntax and much less changes in code overall).
- 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.)
- 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.
(btw, now that I have "hg pull" another repo, how can I remove it? is my clone broken forever?)
No, you can "hg strip" away the root of the wrongly pulled revisions (which also strips all descendants), or use "hg clone -r XXX" to create a new clone with only a specified revision and all its ancestors. Georg