On Tue, Jul 12, 2011 at 3:52 AM, Michael Wood <esiot...@gmail.com> wrote: > Hi Ken > On 12 July 2011 03:12, Ken Wesson <kwess...@gmail.com> wrote: >> On Mon, Jul 11, 2011 at 7:51 PM, Mike Meyer <m...@mired.org> wrote: >>> I was with you until you said "stored remotely". >> >> Well, the source code is being worked on collaboratively by >> geographically separated people in many cases, and from multiple >> office cubicle computers in the most geographically-concentrated case. >> The canonical master version of the source code must reside in some >> single place, which can be at most one of those developers' computers; >> so for the rest of them, it's stored remotely. > > This may be the case, but a "repository" in no way implies that there > are multiple developers involved.
No, simple statistics suffices for that. When a project is big enough to use a repository and not simply a source tree on one guy's computer, it's generally got multiple developers. > Also, even if there is some central, authoritative repository, the > individual developers may (e.g. in the case of Git or Mercurial) still > have local repositories that are not inextricably linked to the > central repository. Except that to make any change "official" it must be pulled/pushed into that central repository -- which requires a client/server protocol in the general case. > The conflict resolution in CVS or Subversion or Mercurial or Git all > happens locally. Not in some central server or repository. Perhaps, but detection has to happen centrally, wherever resolution is handled. > Some crude form of conflict detection might happen in the central > repository, but so what? "So what?" So, without conflict detection you have anarchy and with it you have a server. Take your pick. :) > If there is a central repository then yes, changes need to be pushed > to it or pulled into it from elsewhere. But the existence of a > networked repository or a repository shared on a multi-user machine > with no networking involved does not preclude the existence of > non-networked, single-user repositories. What (other than satisfying Maven's peculiar, autistic needs from its world) is the use case, precisely, for such repositories? >> 1. One developer, one computer. Version control may be overkill in >> such a case anyway and it's not how big, major projects are developed. > > I'd disagree that version control is overkill, but that has is > irrelevant. Obviously not, since it cuts to the heart of whether *in practice* the typical repository will be networked or not. Version control is overkill unless the project has gotten above a threshold in terms of sheer size of code body. Though we might disagree on the exact positioning of that threshold, the likelihood is overwhelming that by the time it's even approached a project has accreted multiple developers -- for one thing, it's hard for a single developer to keep that much code straight in his head, unless it's so modularized that the components are essentially separate projects with fairly stable APIs and each below the threshold for version control being a big win. For another that would have to be one heckuva prolific single developer; for a code base to get really huge usually requires it to have many people adding to it. -- 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
