begin quoting Christian Seberino as of Fri, Aug 17, 2007 at 10:15:30PM -0700: > > On Fri, August 17, 2007 1:27 pm, Stewart Stremler wrote: > > > Um... you still need a definitive release authority. > > > But once you get more than one person acting as the release authority, > > you'd be back where you started, no? > > The Linus networking subgroup leader has authority over their local trunk. > The ARM subgroup likewise and on and on. Up the chain of command people > pull from the trunks below them. Linus has release authority. Git > doesn't change that. It just avoids the problem of Linus and others > having to grant and decide access for certain people.
Um, no. If I'm the designated "release authority", and the workload gets to be too much for just me, and I need to bring a couple of people in to help me, I have to expand who has commit access. Which is where we started. Building up a hierarchy helps -- quite a lot, I'd imagine -- but you still have the political problem of "who gets commit access" if the workload is more than what one person can handle. All those separate repositories are, in effect, branches, but with better access control than you normally get in a centralized VCS. > > A remote repository is a *good* thing. > > If your remote Subversion server crashes, all you got left is your latest > checkout without the full history unless you rsync'd a copy of the server > repository to your laptop. Git combines both of these errands into one. > Less work. B. A. C. K. U. P. S. Centralized repositories can be regularly backed up, saving everyone's changes, with is rather less work than everyone having to manage their own backup system. Now, in the haphazard and casual world of open-source, that's not really a common feature. Having everyone have a replica, more or less, of everyone else's repository accomplishes a sort of distributed backup system. . . so long as everyone shares their repository. Now, a centralized repository *can* be used with a distributed VCS. But it'll take some developer discipline to make it work, and if it works, you may end up with the best of both worlds. Distributed repositories are, in effect, a development branch for each developer. Been there more than once, with more than one VCS, and it's not as useful as it might seem, although it's necessary when you have untrustworthy (comptetence-wise) developers on the team. > > Multiple parallel trunks seem problematic. > > I wonder if this is mainly because our brains have been doing centralized > SCM for so long. Hey I'm skeptical too but Linus says it "just works". For what Linus does, it probably does work. Linus is, however, in a pretty unique position -- he's at the apex of a pyramid, and doesn't *have* to accept changes from anyone. Any trunk that deviates too far has their changes rejected until /they/ come into compliance. It doesn't always work that way. -- There's an assertion that sufficient evolution leads to speciation. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
