Re: [Monotone-devel] newbie question - SHA1 vs serials

[K. Richard Pixley]

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.

--rich