Monotone analysis

[Felipe Contreras]

2008/7/9 John Bailey <rekkanoryo at rekkanoryo.org>:
> Luke Schierer wrote:
>> I wouldn't mind switching now if 1)there were a clear benefit to doing
>> so and 2)a degree of certainty that we won't be switching again in
>> another couple years.  That being said, I don't think we want to throw
>> away our work on trac _now_, so we'd want to make sure all the pieces
>> were in place for trac integration _before_ the switch.
>>
>> Luke
>
> I don't see any reason to switch at all (hmm, deja vu--I recall saying this
> before the switch to svn).  Monotone does everything we need it to and then
> some.  Any extra tools we would gain may make some things easier or nicer, but
> they're just fluff--they're not *needed* to accomplish any task.
>
> I certainly am against a change to ANY VCS or DVCS that doesn't support
> microbranches in as simple-to-use a manner as mtn does.  Microbranches are
> immensely useful, particularly when trying to introduce a daggy fix, as has been
> discussed previously.  Sure, we do have a few more merges than are strictly
> necessary, but it's not going to kill us.

You can achieve with temporal/topic/local branches what you can
achieve with microbranches, except that you have control over what's
happening.

To me it seems microbranches is a bug renamed to feature; the
developers couldn't find a better way to handle the divergence so they
just left it there to be solved in the most uncreative way.

>From the mtn FAQ:
Isn't multiple heads on a branch dangerous or crazy?
Monotone takes the approach that divergence is a fundamental part of
being a VCS. Divergence always happens. The proper role of a VCS,
then, is not to try to prevent or hide divergence, but instead to make
it visible and provide tools to manage it.

Git/bzr/hg provide better tools to manage the divergence: cheap branches.

> Ease of use for outsiders isn't that big a deal.  We can always make an svn
> clone of im.pidgin.pidgin public if it's that important to us, but that incurs
> another maintenance cost that simply isn't worth it.  Monotone is not difficult
> to use, particularly after reading the UsingPidginMonotone wiki page.  If people
> want to complain about the size of the monotone database, I'd suggest they read
> the previous post in this thread about the size of our old git repo and be
> thankful mtn is better than that and that git has improved in the meantime.

I am almost sure you didn't pack the git repository, and now you are
blaming the size of the repo to git. I calculate that the size of the
unpacked repo at that time must have been around 700MB, maybe at that
time packing the repo wouldn't be as small as it is today, but
certainly not anywhere near 700MB.

No one has provided an answer to my question about packing the repo,
so I assume nobody did it.

Of course MTN isn't hard to use once you get used to it, CVS wasn't
either, but once you get used to something superior, you can't go back
to the madnes. Would you do serious development in CVS again? Even if
a project you want to contribute to is using it and they see no reason
to change?

There's a reason why nobody is using mtn: it's not ok.

-- 
Felipe Contreras