Monotone analysis

[Felipe Contreras]

On Tue, Jul 8, 2008 at 11:45 PM, Ka-Hing Cheung <khc at hxbc.us> wrote:
> On Tue, 2008-07-08 at 23:17 +0300, Felipe Contreras wrote:
>> = Git recommendation =
>
> Sure monotone is slower, but is it fast enough? Sure the monotone db is
> bigger, but is it really that much of a problem?

At some point in time 1M of ram was enough for most people, now it's
not. It depends on what you do, right? Except that what you can do
depends on what you have.

You can say mtn is fast enough for what you do, but that doesn't mean
that if you have something faster you won't be doing much more.

For example, 'mtn log' takes 62 seconds in my laptop, while 'git log'
takes 0.93 seconds. Is 'mtn log' fast enough? Well, that depends on
how often you do 'mtn log', and paradoxically, how often you do 'mtn
log' depends on how fast it is.

That's a physiologic feature of human beings; we must find ways to be
happy with what we have. It doesn't make sense to get desperate with
how slow a 100mhz computer was decades ago, but it does right now,
because now we can have something better.

> Maybe there are less
> tools for monotone, but the extra tools for other DVCSs are worthless if
> we don't plan to use them anyway.

Again cyclic stuff; you don't plan to use them because you couldn't have them.

> While I don't dislike git or anything else, and think that starting with
> monotone now is a little silly, I think the important thing here is
> whether the cost of switching is worth it. Many of us spent quite a
> while to learn monotone already, and it's hard to spend time to learn
> something else unless it's clear that there's significant return. Also,
> if we switch to X now, should we switch to Y when that becomes _better_?
>
> Pidgin isn't in the business of developing DVCSs. If monotone becomes
> not good enough, or if there's a clear winner in the DVCS space, then
> ya, maybe it's silly to keep using monotone then.

I think the false assumption here is that Monotone was a good choice
at the time; it wasn't. I've been reminded several times that you did
your homework and studied carefully all the options, but a quick look
at the repository format would have shown all the mtn deficiencies
I've mentioned.

The UIs, documentation, platform support, all those can change and
improve, but the underlying design doesn't.

Keith Packard understood this, and chose git knowing that the
fundamentals where right [1].

It's sensible to wait for a clear winner in the DSCM wars, that's why
I don't get why you chose mtn when I think it was never a clear
winner.

In any case; the important thing as you say is the cost of switching.
I bet switching to mtn was painful, but that doesn't mean switching to
git would be, that's why I mentioned all the GUIs, tools, tutorials,
etc. I've witnessed projects switching to git in a matter of weeks;
not a big deal.

[1] http://keithp.com/blogs/Repository_Formats_Matter/

-- 
Felipe Contreras