On Tue, Jul 12, 2011 at 3:11 PM, Mike Meyer <m...@mired.org> wrote: > On Mon, 11 Jul 2011 21:12:20 -0400 > Ken Wesson <kwess...@gmail.com> wrote: >> 2. Many developers, one computer. No "remote storage" and if the >> developers are co-located no server; otherwise a terminal server. The >> former is obviously not parallelizable (though edit conflicts are thus >> a non-issue -- single global lock FTW!!!1!1) and the latter is a >> throwback to the 1980s or earlier. :) > > Most systems that support such a model - and yes, they're still being > both developed and used - are well enough written to avoid a single > global lock.
Another misunderstanding. Many developers working at one physical, co-located computer has the keyboard and monitor as "a single global lock". In the terminal server case there could be a finer locking granularity. As for "still developed and used", what for? Perhaps top-secret stuff where they really want to guard against the code leaking? I guess they might use this model to develop the code that runs on Predator drones, or something, not because more modern methods don't exist but because more secure methods don't exist; the code never leaves the one server and really robust credentials can be checked before someone can log in to even view it there, AND they get a log of the IP address of everyone who does see it. Trying to leak it would be a pain involving copying one screenful, pasting it, scrolling, etc. And access could be further limited to a LAN inside a high security facility with armed guards and code-locked physical doors. However, another outlier exception rather than example of typical software development and repository use. :) >> 4. An ad hoc, peer-to-peer system with many evolving versions of the >> codebase and patches swapped back and forth > > This is the model used by the Linux kernel, among others. You might > argue that one of Linus's repositories is a "master" copy, as that's > the one that Linux kernel releases are cut from, but that's really the > only thing that distinguishes it from any of the others. Each > developer gets to decide where they want to take patches from and > which patches they're actually going to use in any given build, but > most can't put code in the so-called "master" repository. Which means it's not really case 4 at all. ANY open source project potentially has "eccentric patches" circulate among techie users and developers that don't appear in the master branch -- at the very least if they want to give a patch extensive testing before committing it to master, then several developers might apply it to their local versions for a while and see how things go. >> So, unless 4 can be made workable, > > I'd say a project with 14 million LOC and thousands of developers > using it for five years demonstrates that it's both workable and > scalable. Except that it has an official build repository with more stringent criteria for what gets in there, so not really. -- Protege: What is this seething mass of parentheses?! Master: Your father's Lisp REPL. This is the language of a true hacker. Not as clumsy or random as C++; a language for a more civilized age. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
