|
| From: | Joel Crisp |
| Subject: | Re: [Monotone-devel] newbie question - SHA1 vs serials |
| Date: | Wed, 20 Apr 2005 21:43:21 +0100 |
| User-agent: | Mozilla Thunderbird 1.0 (Windows/20041206) |
Other modes are completely user controlled branching (base clearcase) and multiple views on a single branch, which case is normally mixed with UCM single developer streams if you want to have 'wildcat' development or peer programming.
The UCM stuff, along with Clearcase Multi-site allowed us to scale to 150 developers with minimal problems, most of which were project organisation issues highlighted by SCM rather than SCM tool issues.
Joel Jon Bright wrote:
K. Richard Pixley wrote:To extend monotone to include some concept of actual users will require separating the concepts of authentication mechanism from whatever token is used for user identification purposes. I think this will ultimately be inevitable if monotone is to scale into widespread corporate or commercial use and probably inevitable if monotone is to support any significant number of developers concurrently.I think you have a point, but I also think that this kind of support for a situation which (in my opinion) only large corporate users need is likely to need sponsorship from some large corporate user in order to get implemented :-)No, I'm honestly talking about 128 developers all working on the same branch, pretty much concurrently. This is the interesting scaling issue. If monotone can only solve this problem via partitioning, either partitioning users by branching, or partitioning checkin's by time, or whatever, then monotone necessarily forces a working methodology onto it's users very early, which, IMO, is a fatal flaw in a tool of this type. Existing tools can manage this case either directly or via feature branching.I'm pretty sure the case of 128 developers working on the same branch at the same time would be a rare one. Since branches are such light-weight things, I think it's much more likely you end up with (as we have now) net.venge.monotone and net.venge.monotone.cvssync - the person working on the cvssync feature works away in their own branch and will eventually merge back to head. Every small group of developers could work on branches such as com.foo.project.feature.subfeature.module.ad.infinitum - whatever the project, I think there's liable to be such a reasonable hierarchical classification (though of course, there's no real need to adhere to a hierarchy other than for ease of understanding).However, in commercial development, if management strongly urges code production speed over all other considerations, then merging and/or unity tends to fall by the wayside. This is just an unfortunate fact of most commercial development, I'm afraid.So don't count code as produced until it's merged from the branch where it was being produced into mainline (or the mainline for this subproject, or whichever). One ready-made motivation for getting branches merged closer to mainline (and therefore for getting heads in your branch merged, since otherwise you can't merge to mainline).But somewhere around 128 users or so, we'll need to invent methods for backing up and archiving the central repository without any down time.You can do this today. Run a second copy of monotone on the central machine, pull with it from the first. Stop it. Back up its DB. Repeat. Presto, continual backups, as often as you want, of the central repository.CVS doesn't handle branching very well, and merging is even worse.monotone handles branching very, very well and merging.. well, certainly much better than CVS. I think the relative ease of branches in monotone might be something you're overlooking.My current estimate is that monotone's merging support and it's ability to support geographic disparity, will allow it to support at least as many concurrent developers as subversion. I think the key distribution problem will be a scale limiting factor before head management. I think they key distribution problem will begin to be uncomfortable at 32, become difficult at 64, and become impossible at 92 or with even modest turnover.We probably have 32 developers on monotone itself now, though granted only maybe 8 are active. I'd personally be in favour of waiting and seeing what problems arise, and coming up with solutions to those problems when they've arisen and we know all about them. I'm not saying you're wrong, but I think there are probably plenty of reasons why monotone is inappropriate for corporate deployment atm. The issues (if there turn out to be some) with key deployment will (I assume) show up before the other corporate-blocking problems are solved.
| [Prev in Thread] | Current Thread | [Next in Thread] |