[Python-Dev] Backport troubles with mercurial
g.brandl at gmx.net
Wed Dec 29 09:20:18 CET 2010
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
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
> - 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
> 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.
More information about the Python-Dev