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 _______________________________________________ Monotone-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/monotone-devel
