Re: [Monotone-devel] Future of monotone

[Ethan Blanton]

Thomas Keller spake unto us the following wisdom:
> There are still quite a lot dedicated people who care about this 
> software (put yourself on the list if you read this with a tear in your 
> eye) and I'm sure all these people don't want to let this software die 
> silently. On the other hand it seems that there are not *enough* of us 
> which have actually enough spare time, knowledge and/or steady interest 
> to bring this project really forward.

I certainly am still pinning my DVCS hopes and dreams on monotone;
it's come a long way since I first started paying attention.

> So where lacks monotone the most?

Speaking from the point of view of a Pidgin developer, which I think
puts me in the minority of actually using monotone for a project of
nontrivial size and activity (OpenEmbedded is the other example I see
come up a lot), my primary concerns are:

1) Occasional UI glitches (which are rapidly being ironed out), where
   long and laborious activities (such as manual merges) are aborted
   due to checkable pre-conditions failing after the fact.  I am not
   aware of any *specific* instances of this right now, but there have
   been quite a few, and doubtless will be more.  Fortunately, they're
   fixed pretty much as they're found.

2) Speed of common operations such as 'annotate', 'diff', various 'ls'
   options.  These have improved greatly with, e.g., heights, but
   still leave much to be desired.

3) Speed of netsync.  This possibly should be #1.  Pulling pidgin from
   pidgin.im is basically an hour-long process.  Not only is it so
   slow that most casual developers give up (many have even told us
   this), but it's hard on the server.

4) Locking troubles.  We have to solve a LOT of problems with netsync
   to the public server, even on localhost, because multiple monotone
   processes do not share one database well.  This wouldn't be as
   painful if (as previously mentioned) netsync were not so expensive.

5) Workspace merge.  This was started, but never finished.
   3-way-merge tools are all well and good, but sometimes the Right
   Answer is just a developer in an editor.  I see a lot of grumbling
   about this on our chat channels and mailing list.  Extremely large
   merges are particularly annoying, because they have to be handled
   in monotone's preferred order, the context around changes is hard
   to find (e.g., you don't know what another, successfully
   auto-merged file looks like, because you can't reference the
   merge-in-progress until it's done), and they have to be completed
   all in one shot without any failures.

6) Occasional bad merge glitches.  We've seen lines deleted which we
   could not justify, hunks added or missing, etc.  I've discussed a
   couple of these on IRC, but they generally boil down to such long
   merge chains that it's hard to debug as an outsider, and monotone
   regulars face a huge cost in setting up and trolling through
   Pidgin's 250MB revision database.

As bad as all this sounds, I think we're generally pretty happy.  :-)
I'm certainly sorry to see Graydon throw in the towel, but I'm
grateful for his work on monotone, and the work of all the subsequent
developers who have brought us to this point.

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

signature.asc
Description: Digital signature