Stewart Stremler wrote:
Um... you still need a definitive release authority.
True.
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".
Sorta.
The big thing you missed is the fact that the branches can *also* pull
from the release authority even after it moves forward.
This is the big thing about DVCS systems. You can merge in changes from
past branches into future copies of different branches. In addition,
you don't lose the history of those branches, either.
So, if RedHat branches from Linus, Linus should be more easily able to
reintegrate changes that RedHat makes and RedHat should be more easily
able to reintegrate changes that Linus makes.
** 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.
That's not the (possibly unclear) point.
The advantage is that I can share my *repository* (not just patches)
without needing to have a central point that we can both log into.
Now, to be fair, I think subversion can do this if we both have clones
of the original repository.
** 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.
Yeah, but it only loses your local repository. You could then check it
back out from, say, Sourceforge.
Before, however, if Sourceforge had a disk crash, you were completely
hosed. With a DVCS, if SF has a disk crash, you can just re-push your
local repository and it's back to normal.
Or, if someone hacks the main repository to inject malicious code, the
client repositories are going to complain that there are mismatches in
the history.
A remote repository is a *good* thing.
Yeah, that's something I'm pretty religious about. If the code has any
longevity, it goes up to a repository on a server somewhere.
** 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.
I don't buy that this is always a win. It's only a win because of
Linus' particular quirks. In particular, his lack of testing
infrastructure. He relies on his lieutenants to be the "unit tests".
If Linux actually had unit tests, you would find that the ABI would
change far less than it does because an ABI change would require redoing
all the unit tests.
-a
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
