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

[Emile Snyder]

On Wed, 2005-04-20 at 10:20, K. Richard Pixley wrote:
> 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.

Could you say a little more about how existing tools support this
massively concurrent mode better?  To be concrete, in a previous message
you referenced a case where you have ReallyImportantHeader.h that
everything depends on and that is churning alot.  I'm probably just
lacking in imagination, but if you want all your developers to get code
back on mainline quickly (ie. want to avoid partitioning to slightly
longer lived branches) how do you get away from spending lots of time
merging?  Or do you just want the tool to force you to merge more often?
>
> > 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.

Is this really in the scope of monotone?  Seems like it's better handled
by hosting the main monotone db/server on a system with a snapshotting
filesystem or something.

> 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.

What sort of support is clearcase giving you that makes
tracking/managing branches more to your liking?  (I have no clearcase
experience, sorry.)  How is the fact that someone might have a branch
that's not pushed to the canonical server different from the case where
a developer has some working dir that they haven't checked in at all
yet?

> 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.

I would hesitate to host large mission critical projects with monotone
just yet; seems like we're still working out quite a few kinks that
people who don't want to hack on monotone would be pretty annoyed with. 
But it sure is progressing quickly ;)

Thanks alot for all your input; it's great to hear from someone with
your perspective.

-emile

> --rich
> 
> 
> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel

+----------------------------------------------------------------------
/* I can C clearly now */ 
+----------------------------------------------------------------------