On Tue, 12 Jul 2011 18:20:38 -0400
Ken Wesson <kwess...@gmail.com> wrote:
> 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?
What makes you think a computer can have only a single
keyboard/monitor? After all, what is a terminal server but a computer
with lots of keyboard/monitors that routes the terminals out to
network servers of some kind? But this is all irrelevant - from the
point of view of an application, it doesn't make any difference if
someone is issuing commands from a device directly connected to the
hardware, from a device connected to a terminal server, or sitting at
a second computer and connected back to the single computer where the
work is being done.
Which is why such things are still being developed. There's
fundamentally no difference between many developers running commands
on the single computer to manipulate the data and many developers
running clients that talk to apache running on that single computer
and causing it to issue those commands. This lets a developer leverage
the apache networking code to create a client/server model, and most
modern SCMs can be run that way.
> >> 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.
Well, it's very clearly not cases 1, 2 or 3. There are many developers
and many computers, and case 4 is the only one that allows for
that. So this is either case 4, or you need to provide another case
for it.
> >> 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.
Half right. As I said, it's got one repository that the official
builds come from. Other people are free use builds from their own
repositories, and often do - I don't think any of the GNU/Linux
distributions actually use binaries built by Linus. Instead, they each
have their own "master" repository from which they do their "official"
builds.
However, the criteria for what gets into that so-called "master"
repository are no more stringent than for any other repository in the
project: only patches the owner wants get in.
<mike
--
Mike Meyer <m...@mired.org> http://www.mired.org/
Independent Software developer/SCM consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
--
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
