[Python-Dev] Backport troubles with mercurial

[David Cournapeau]

On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
<amauryfa at gmail.com> wrote:
> 2010/12/29 David Cournapeau <cournape at gmail.com>
>>
>> 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
>> easily refer to the original commit the cherry pick is coming from
>> (i.e. no equivalent to git cherry-pick -x), and the conflict
>> resolution is quite dumb.
>
> This is precisely why I proposed a specific example.
> Which precise steps do you take?
> How much typing or manual copy/paste is required for this very simple case?
> Can you do the merge in less than 10 minutes?

I don't know in this specific case. As I said, when I have to use hg,
that's the technique I use, and you get the issue you mention. That's
a hg limitation AFAICS.

> And finally the biased question:
> can you find one improvement over the current situation with svn?

I am not involved in the hg conversion process nor its decision (I am
not even a python committer). Cherry picking is actually easier to do
with svn by "accident", because its merge method, up to 1.5 at least,
was really dumb and never remembered the ancestors of a previous
merge.

As for a few data points which may or may not be relevant:  in numpy
we convereted from  svn -> git recently, and it has worked pretty
well, with numerous new contributions happening, and better, new
contributors appearing. I have been the release manager for numpy for
several years, and as such had to do the kind of tasks you mention
numerous times with svn, and the only words that comes to mind when
remember this period would not be appropriate on a public mailing
list: I always found svn to be horrible. I started using git to make
my life as release manager simpler, actually. I would be surprised if
python's situation did not end up being similar to numpy's one. Other
projects related to numpy made the changes to a DVCS (ipython, nipy,
lean scikit) before and none of them ever regretted it AFAIK, and
sometimes the people who become the most vocal proponents of the new
tool were the most sceptic ones before. Certainly, very few people if
any asked to revert the process.

cheers,

David