List of things I don't like about using Monotone

[Ethan Blanton]

Mark Doliner spake unto us the following wisdom:
> As promised, here's my list of reasons why I don't like using
> Monotone.  Some of these might be fixable, some of them are just my
> opinion, and some of them are barely even rational.  Basically I just
> think the added complexity of a distributed version control system is
> annoying and unnecessary.

Great, thanks!

While I agree that a DVCS adds (some) complexity for us, the regular
developers, it makes a lot of things possible for casual developers
who do not have permission to push changes to pidgin.im, in that they
can version their own history with all of the power that we version
ours.  Non-distributed VCS systems, on the other hand, force them to
be second-class citizens, incapable of using much of the power of the
tool simply because they don't have permission to write to some server
somewhere that they have no control over.

I'm going to point-by-point through these, to help identify where
solutions might lie.  It will probably appear that I am dismissing
some of these points; that doesn't mean they aren't real, but that I
either don't see an immediate solution, or I see a fix that seems
adequate for now.  You may disagree.

> * Not being able to run "meld ." in the root directory of my source to view a
> beautiful tree of all my changes.

My version of meld appears to do this.  I have 1.1.4.

> * There's no way to view the revision history for a given file in the web
> interface in trac.
> 
> * Commit emails don't always include a diff, the subject line is useless and
> the emails don't always arrive chronologically from when they were committed.

These two are tools problems, not monotone problems, for which we are
looking (for some definition of looking) for fixes.  I was unaware of
the subject line problem (?), but it is probably trivially fixed if
you tell us what you want.  Chronological ordering of emails is a bit
more difficult, for several reasons -- for one, we can only ever hope
for chronological ordering of when they were *pushed*, not committed.

> * Having to run 'mtn commit', 'mtn pull', 'mtn merge' then 'mtn push'
> to check stuff in.

Remember that, for svn, you have to run 'svn update' then 'svn
commit'; with monotone, under best-case scenarios, you can get by with
exactly this plus a push.  The other mechanisms are needed only when
you have multiple local commits that need to be pushed together.

> * Having to run 'mtn pull' then 'mtn update' to check stuff out.

Fine, alias it.  This has been a discussion on monotone-devel at
several points, but I don't really see the problem.

> * 'mtn pull' and 'mtn push' take a long time compared to 'svn update'

I do not find this to be the case, necessarily; mtn pull takes a
similar amount of time to svn update, but for updates of any size, mtn
up is much faster than svn up (in my experience).  You can also use
inodeprints (which I do not) to speed this up even more.

> * 'mtn annotate' is really slow.

Make sure you're using a recent version; in 0.34 it does not appear to
take appreciably longer than svn annotate for me, and it doesn't have
to contact the server to do it.

> * Given a revision number, I can't just subtract 1 to get the previous
> revision.

True.

> * I have to freaking compile my own deb for Ubuntu in order to use a version
> that isn't ancient.

OK.

> * Having to read large amounts of documentation to figure out how to use it.

It's almost like better tools take time to learn.  ;-)  I feel your
pain here, but I really think the benefits for us, and for the
community as a whole, are worth it.

Look at it this way; it's not subversion!  Anyone who had to merge or
manipulate branches through any of our tree reshuffles, or after a
long period of divergence, can tell you how painful *that* was.  Such
problems should be gone, now, or going away -- as rlaager can attest,
merges with a lot of conflicts can still be painful, until workspace
merge gets all fixed up.  They're just a different kind of painful
from svn, and one which is far less likely to strike, due to
algorithmic improvements.

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20070430/3e4c9312/attachment.sig>