|From:||K. Richard Pixley|
|Subject:||Re: [Monotone-devel] newbie question - SHA1 vs serials|
|Date:||Wed, 20 Apr 2005 10:20:53 -0700|
|User-agent:||Mozilla Thunderbird 1.0.2 (Macintosh/20050317)|
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 :-)
Right now I'm just sorting my own thoughts out and testing the attitudes of the community. :-).
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.
That is one instance of what I mean by partitioning. I'm pretty sure that all software development concurrency problems can be solved by partitioning. That's really just a fancy way of saying we can solve the problem manually if the tool doesn't offer us sufficient support.
My point is that currently available tools offer differing levels of support before solving the problem manually is required. 128 concurrent developers is only rare because existing tools have maxed out in this range forcing people to think in terms of solving the problem manually, (ie, partitioning), much sooner. Partitioning has a high overhead so we'd really prefer to avoid it for as long as possible although partitioning is better than failing to solve the problem.
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).
This is not how programming is currently taught. We've had source code control for at least 30 years and yet source code control is still a new concept to many developers. I agree that a change task isn't complete until it's delivered to the appropriate branch, perhaps not until it's suitably tested, and maybe not even until it's in the customer's hands. However, as a CSM professional, I'm well aware that that's not currently how most coders think. I can educate. And I do. But it's not currently a reasonable expectation.
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.
No key distribution. No backups of system software or configurations. What I really want is the ability to reload the original machine's (replacement) hard disk with a verbatim copy of whatever it had yesterday. I'm talking about disaster recovery, not necessarily archival, court records, or data redundancy.
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.
I don't think so. I take ease of branching for granted. It's management of the branches that seems to be an issue in most free systems today. Contrast to clearcase branches, which, while nominally more user overhead, are significantly and seriously easier to track and manage. In a distributed system, I can't even ask what branches exist, since no perspective is necessarily even complete.
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.
Frankly, I'm there already. Of my past 5 or 6 clients, the key distribution problem would have prevented monotone deployment. My current client has no common or centralized user authentication model atm, so this might not be a blocker for them. We'll see. I'm not sure monotone has the critical mass or maturity needed either but I think the multiple heads mechanism is stunning and perhaps revolutionary.
|[Prev in Thread]||Current Thread||[Next in Thread]|