[geeklog-devel] Upgrade CVS to a distributed repository

[Nick Andrew]

On Tue, Apr 15, 2008 at 08:06:45AM -0400, Randy Kolenko wrote:
> Hmm.  Just thinking out loud here:  By switching to any other SCM,
> aren't you just trading one set of politics for another?

The tool doesn't dictate the politics, but more the other way around.
I think of it as openness toward contributions and customisation.

Closed source software may distribute as binaries only; they're actively
discouraging changes and contributions. Distribution in tarfiles provides
people with the source code but there's no support for upgrading (each
release tarfile is distinct) and no structure within which people can
contribute.

Exposing a CVS or SVN repository gives people read-only access to the
code as it is being developed. It's a step forward; somebody can stick
to released versions or upgrade to the latest HEAD frequently. However
there's still no support in the tool for a person's local changes.
With SVN and CVS you can make local changes and when you do an "update"
the tool will merge the repository changes with your uncommitted
changes (and you get to resolve conflicts). But there's no support for
change control on a person's own commits.

When I make local changes to some open source project I like my
changes to be under change control as well. I want to be able to
merge in updates from the source without the chance of blowing my
own changes away. If the project itself uses a distributed SCM
then that problem is solved. And if I want to contribute to the
project then the distributed SCM gives me a framework in which to
do so.

> Git would surely distribute the ability to code across many people -
> however the maintainer of the official code base will still pull from
> only those who he/she trusts.  

If you are talking about bulk changes then yes, trust is important if
you're not going to review the changes individually. It's all about
review; for individual one-off patches what's important is that the
patch should work and it should advance the state of the code base
in the direction you want it to go.

> People *COULD* pull from a Groklaw Git node, but that would not be an
> official codebase for Geeklog.

It would be an official codebase for Groklaw though, and the
people who would be using it would be primarily assisting Groklaw,
however due to the magic of DSCMs, any changes which are applicable
to Geeklog can be picked out and integrated upstream.

> There would be cries of "FOUL!" when the maintainers don't pull patches
> from some good soldier's Git repository -- same thing already happens
> today with Geeklog + CVS (The cries of "But I posted patch XYZ and it
> didn't make it in the final release").

You see, the politics is more inherent to the project than the tool.
The distributed SCMs provide a framework to deal with that kind of
issue. The maintainers might say "Patch XYZ isn't suitable as it stands,
but if you fix this and refactor that, we'll reconsider" and the person
who writes the patch can easily modify it and send out another revision
(as a single patch, as opposed to sending a bad patch and then a fixup
patch for the bad one).

> However CVS is just plain terrible for merging of code.  So even
> "upgrading" to SVN would be better.

SVN isn't all that crash hot with merging either :-(

Nick.
-- 
PGP Key ID = 0x418487E7                      http://www.nick-andrew.net/
PGP Key fingerprint = B3ED 6894 8E49 1770 C24A  67E3 6266 6EB9 4184 87E7