Re: [tlug] "Centralized" vs, "distributed" VCSs

[Curt Sampson <cjs@example.com>]

I'll deal with just this one, first.

On 2009-02-21 14:57 +0900 (Sat), Stephen J. Turnbull wrote:

>  > > And of those several dozen, how many have an URL to their current
>  > > active repo that you can post so that I can pull from it?
>  > 
>  > All of them: anoncvs.netbsd.org. You don't even need to know who they
>  > are; it's all in one convenient place.
> 
> *All* of the several dozen?

Yes. And new ones as they appear. You need not even think about it; just
check out the trunk and all of those other developers will merge their
changes into it for you.

> And what's convenient about it? It doesn't serve HTTP (even
> cvs.xemacs.org does that!), and I don't know the CVSROOT so I can't
> even use checkout -c to get a list of modules.

None of the complaints above would apply to subversion, and thus none
of these are complaints about the CVCS model; they are (very well
justified) complaints about CVS.

> I bet few of those several dozen have listed CVS modules with a brief
> homepage[2] explaining the content of their private branches ...

There aren't so many private branches as you'd think. However, for those
that are there, assuming you can find the branch name, it's going to
contain the commiter's login, so just drop a note to whomever@example.com
and you can find out all you want about his branch, assuming he's
willing to tell you. Even if he isn't, you can check it out and easily
examine the changes for yourself.

Again, this is much easier in subversion than CVS, where we have to keep
a central file we manually update with all branch names. Oh, wait, in a
DVCS we also need to keep some sort of central manually updated file for
the branch URLs....

> ... oh, of course what you mean is that those private branches really
> *are* private, I can't get access to their in-development trees....

Those can be created, too, of course; there's no way to stop that (and
one wouldn't want to). But for major new pieces of work that require
a branch, or branches for release versions and the like, they're all
public and it's pretty obvious what they are.

The wonderful thing about something like subversion is that, unless
people are intentionally trying to obfuscate things, once you've got
the main repo URL, you've got the ability to find everything else
that's public; all it takes is using 'svn ls' or, even better, a visual
repository browser.

Most DVCSs throw you back to doing manual tracking of your branches. You
can use naming conventions to help, of course, but that doesn't give you
an automatic list. If you've got something served via straight HTTP,
such as darcs, the slowness of that can at least be made up for by the
ability to put everthing under one directory on an HTTP server, which
gets you back that automation for the most part.

cjs
-- 
Curt Sampson       <cjs@example.com>        +81 90 7737 2974
           Functional programming in all senses of the word:
                   http://www.starling-software.com