monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Self-intro and topics


From: Jonathan S. Shapiro
Subject: [Monotone-devel] Self-intro and topics
Date: Fri, 04 Aug 2006 13:05:35 -0400

I'm Jonathan Shapiro, one of the OpenCM folks. Obviously I'm new to the
list.

Monotone and OpenCM share a bunch of ideas, and differ radically in a
bunch of others. From what I'm seeing, monotone looks like very good
work. Since OpenCM has stalled for lack of time, I'm exploring whether
we should encourage OpenCM users to shift to monotone. This is prompting
several questions:

1. There are two *trivial* and backwards compatible features that OpenCM
users really like that we think monotone should adopt. I'ld probably be
willing to supply the patch.

2. There are some scalability problems (in size of project) that we ran
into, and it appears (from the schema) that monotone will probably hit
them too. I'ld like to identify them. Maybe there is a reason monotone
isn't hitting them, or maybe you *will* hit them. That seems worth
talking about.

3. There are some places where the "theory of operation" between the two
systems is really different. I'ld like to describe some usage scenarios
that we have in OpenCM and understand how to deal with them in monotone.
The mtn manual probably has all of the facts, but it's not obvious how
to glue them together, and the usage model probably needs to be adapted.

The one big thing that I really want to congratulate you guys on is
finding a way to dodge the bullet on the "one server controls a branch"
issue. I don't have enough experience with multi-headed branches to
understand how usable they are, and I'm wondering about what happens as
the number of developers scales up, but I think the approach is really
interesting.

I also want to add that Monotone made a bunch of good implementation
choices, and I really wish that some of those options had been available
to OpenCM when we started.

I'm going to start with the features, because they are easy to explain,
pretty obvious, and probably not controversial.


Regards,


shap





reply via email to

[Prev in Thread] Current Thread [Next in Thread]