Moving to Hg without any analysis at all

Felipe Contreras felipe.contreras at
Mon Feb 7 22:57:23 EST 2011

On Tue, Feb 8, 2011 at 2:51 AM, Ethan Blanton <elb at> wrote:
> Felipe Contreras spake unto us the following wisdom:
>> Last time when I criticized the move to monotone, Luke mentioned this:
>> > We spent considerable time and effort evaluating our options when we made
>> > this switch. I am a little tired of the idea that we made it relatively
>> > arbitrarily.
>> This time there was no analysis at all, there's no list of pros and
>> cons, and no list of reasons why the move to hg is desirable.
>> For posterity, the only reason you have picked hg over the
>> alternatives, is because more people voted for it. People didn't even
>> had to list a reason for their vote, or even cast it publicly.
> For posterity ... you're wrong.  We *did* discuss pros and cons, at
> length.  We discussed the impact on migration, the loss of information
> in moving from monotone to hg or git, developers' experiences with hg,
> git, and other DVCSes which did not make the final cut.  We looked at
> repository sizes and talked about speed.  We discussed the differences
> in branches, tags, naming, etc. in the various systems.  We talked
> about bug tracker integration, both with trac and moving trackers.  We
> even talked about how hilariously wrong your explanations of non-git
> VCSes are, and how they've not improved since the times when you
> didn't understand monotone.

Easy to say. The only recorded "discussion" was between me and John
Bailey, which he abandoned after I provided strong arguments against
his notion of "branch". And whatever you said about me not
understanding monotone was probably behind doors, and wrong, as nobody
has every provided evidence of me not understanding something about
monotone... not that it matters. And what I said about non-git VCSes
still stands.

Now, the issue is not that you discussed (without hardly any record),
the issue is that there is no conclusion. There's no analysis
anywhere. There's no list of pros and cons. There's no list reasons.
All those are probably on your mind, and it's hard to counter argue
with those.

Why don't you provide an analysis? Some official explanation?

> These discussions took place on mailing lists, on IRC, in the XMPP
> MUC, in public, in private, and all over the place.  You simply
> weren't present, which was your own choice.  Your arguments were
> heard, and weighed, despite the fact that you interjected them
> one-sided, misinformed, and late in the process.

_My_ choice? You have banned me from the IRC channel. And I am looking
at the online mail archive. There's hardly anything there.

>> Hopefully you would agree that this time the decision is arbitrary,
>> and you didn't give a chance at all to the alternatives. Given the
>> fact that you have to use monotone right now I can see why you would
>> want to move with haste, but I still think you should _at least_
>> provide a list of reasons to your community, not just "Because we say
>> so".
> We do not.  We also are not moving with haste -- we've been discussing
> this move since before you ever even saw monotone.  We have simply
> decided that the time for a changeover has come, and there is a
> developer with the energy to do the heavy lifting.
> Many Pidgin developers have used hg extensively at work, on other open
> source projects, and on their own time.  We (I am included in that
> group) have considered it very successful at actually *getting things
> done*.  It is fast, it is accurate, it branches and merges cleanly, it
> runs everywhere, and it is comfortable to use.  Those are the reasons
> we are choosing it.

git is also fast, accurate, branches and merges cleanly, it runs
everywhere, and is comfortable to use.

What you are basically saying is: monotone the tool we know, and we
are comfortable with. So, again, you are not giving it a chance to
anything else.

> This is not an eternal condemnation of git.  Some of us like it very
> much.  We simply aren't choosing to use it for day-to-day Pidgin
> development.

Yeah, but nobody has said why. No analysis, halted discussions, just
counting hands.

> On top of that, most of the work done to perform an hg
> conversion is required for a git conversion, anyway, due to the fact
> that git and hg have very similar metadata deficiencies in comparison
> to mtn -- a conversion from hg to git would be easier than a
> conversion from mtn to git.

Huh? The mtn to git conversion is natively supported by monotone, and
there has been a git clone of the mtn repo for years. I have been
spent a long long time on it. I developed my own script (mtn2git), and
I helped developed the 'mtn git_export' tool, making sure the tree is
exactly the same. I wrote tools to find out missing authors. I
searched for all the missing information of the authors, and made sure
the mapping was up-to-date. And finally, I spent days finding out the
authors of the patches from the SVN days. All this was available first
on my pidgin-git-import scripts, and later on pidgin-mtn-conv-files.
Now I am writing a script to fix the changelogs based on the work on
pidgin-mtn-conv-files; it's basically done.

I say it's the other way around; it's easier to first convert to git,
and then to hg.

Has anyone even checked that the output is correct? Same graph?
Correct dates? etc.


Felipe Contreras

More information about the Devel mailing list