begin  quoting Christian Seberino as of Fri, Aug 17, 2007 at 12:09:11AM -0700:
> 
[snip]
> ** Linus was saying a big thing is that distributed SCM avoids the
> political quagmire for open source projects having to decide who gets SVN
> access to the trunk and who doesn't.  He said that feature in itself may
> be enough to justify open source projects all moving to distributed SCM.

Um... you still need a definitive release authority.

I suppose if the release authority can pull from all the candidate
repositories, then nobody has commit access to anyone else's repository,
which sorta-kinda solves the political problem of "who has access".

But once you get more than one person acting as the release authority,
you'd be back where you started, no?

> ** Also, because everyone essentially has their own "trunk" you don't have
> the common problem of subgroups waiting 2 weeks to test their patches to
> death to avoid missing their quarterly bonus before they submit it to the
> central tree.  They can now pull evolving code from *each other* and
> evolve *faster* together before sharing with the wider world.

Every decent version control system I'm aware of allows merging
between branches.  I would think that this sort of thing would be
*less* likely with a distributed SCM.

> ** You have everything on your local hard drive and don't have to trust
> the family jewels to Sourceforge's IT staff.
 
So a local disk crash loses your codebase. Not good.

A remote repository is a *good* thing.

> ** You can work offline as if you were still connected to your SCM server
> at all times.

This is a feature for laptops indeed.

> ** It is easier to develop a hierarchy of repositories to implement a "web
> of trust" in an open source project.  (Leaders such as Linus only pull
> code from the trusted lieutenants immediately below him.)

Hm.... the invention of bureacracy as applied to version control. Hm.

-- 
Multiple parallel trunks seem problematic.
Stewart Stremler


-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to