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

["Stephen J. Turnbull" <stephen@example.com>]

Curt Sampson writes:

 > >  > 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.

But that's a feature of the *workflow*, not of the *VCS*!  I told you
you were confusing them. ;-)

 > > 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.

Of course there aren't, because the VCS in use is CVS.  It wouldn't be
any better with Subversion, I'm sure.  (You could argue that this,
too, is more a consequence of the workflow than of the VCS, but I
doubt that you will get any takers among those with experience of
DVCSes or work in a large FLOSS community: the difference in cost of
branching is overwhelming, and there are always ideas that are too
radical to go in to the mainline immediately, even in the authors'
eyes, that deserve a home on the same block.)

 > 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....

Hey, you just told me not to take cheap shots at the problems of an
immature version!  Subversion's model is over 20 years old, you would
hope it would grow up a little bit by the time it gets the right to
drink and vote!  [On second thought, I guess that's how Aso got in
... hm, need to think about this ....]  But there you go yourself.

Not to mention that this problem has already been solved, cheaply in
gitweb (which will happily publish all the repos under a given
directory, as well as allowing you to list the repos individually if
you need finer access control) and more beautifully on github.com.

 > > ... 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

*WARNING: CHEAP SHOT COMING.*

No, you can't stop it, but you can sure as shooting slow it
dramatically.  Just use Subversion (or better yet, CVS).  But hey,
that's not (usually) considered a good thing in FLOSS.

 > 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.

Sure, but you are still enforcing "public" == "official".  It's not
necessary to do that to get a single toplevel URL from which you can
easily find the core developers' current (or historical, for that
matter) work.  And I find Firefox or w3m quite satisfactory for
browsing git.kernel.org, no need for a special tool embedded in git at
that level.

And now, with github, we're seeing development of a community based on
distributed development and administration in a common URI namespace.
That this didn't happen with Subversion as the vehicle is no accident.