List of things I don't like about using Monotone

[Luke Schierer]

On Mon, Apr 30, 2007 at 03:25:22AM -0500, Mark Doliner wrote:
> * 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, as have been noted, are problems with the trac/mailman/monotone
integration.  They are all solvable problems, we just need to find and
invest some time on figuring out the solutions.  I suspect this would
have been the case with any of the distributed VCS, because none of them
have widespread acceptance yet.

> 
> * Having to run 'mtn commit', 'mtn pull', 'mtn merge' then 'mtn push' to check
> stuff in.
> 
> * Having to run 'mtn pull' then 'mtn update' to check stuff out.
> 
> * 'mtn pull' and 'mtn push' take a long time compared to 'svn update'

While for simple commits 3 commands to commit can seem excessive, its
really only up from 2 with cvs (and minus the prospect of a conflict
destroying your copy), and approx 2 for svn.  For more complex changes,
I quite enjoyed being able to commit locally in stages as I was working
on renaming the old status branch.  I could have something that didn't
compile, but that still represented a step forward, and check it in
without fear or reproach.

Which brings me to the big win here.  I've not noticed a substantial
difference in speed between mtn pull and svn update, if anything I would
be tempted to say that mtn pull might even, in some cases, be faster.
That being said, I'd be prepared to accept some slowness here when I
consider that I'm doing this pull ONCE no matter how many workspaces I
have, and no matter how many branches I'm working on.  That is a HUGE
benefit.

In the past with svn, I had to do the svn update two and sometimes three
or more times to bring all my trees up to date.  No matter how much
slower mtn pull is for a given user, I cannot believe you are finding it
2x or 3x slower.  I know some of us have even had considerably larger
numbers of trees/workspaces to manage.  They will experience an even
greater gain from this one pull for all.

Along the same lines, Ethan and I have been talking about setting up a
different db, or similar, to give translators push access to a
repository.  Even though I still think that we would not want to give
all of them, especially considering how liable some of them are to
disappearance, write access on the main repostiroy, *we need not worry
about this.*  Because our VCS is now distributed, we can use that to
SIGNIFICANTLY reduce both their headaches (waiting for one of us to
merge their changes) and mine (having to deal with translations coming
in 1)sporadically 2)in a number of different formats.  This will now be
a simple commit && push for them, and a single pull & merge for us prior
to release.  What a gain!

In short, while there are aspects of our new system that need
improvement, I think that the benefits strongly outweigh the
shortcomings.

luke