[Dev] Source Code Revision Control Infrastructure

[Michael R. Bernstein]

On Sun, 2002-11-10 at 12:53, Wes Felter wrote:
> on 11/10/02 1:15 AM, Michael R. Bernstein at webmaven@lvcm.com wrote:
> 
> > Source Code Revision Control
> > ----------------------------
> > 
> > I'll let others more qualified than myself discuss their relative
> > merits, but there seem to be three contenders for this piece of
> > infrastructure: 
> > 
> > * CVS - http://www.cvshome.org/
> > 
> > * Subversion - http://subversion.tigris.org/
> > 
> > * arch - http://www.fifthvision.net/open/bin/view/Arch/WebHome
> 
> You omitted the most powerful choice, BitKeeper. Although its licensing is a
> bit complex, I think it's at least worth evaluating.
> 
> http://www.bitkeeper.com/

Here is a (not especially informative) arch vs. BitKeeper comparison:
http://www.fifthvision.net/open/bin/view/Arch/BitKeeper

I don't think that BitKeeper is suitable for use by the OSAF for two
reasons, neither of them technical: the current licensing, and potential
future licensing changes.

The current licensing
---------------------
BitKeeper is free (gratis) only to developers who publish all the source
code changes to the source being managed. While this isn't a barrier to
use for the OSAF or the surrounding community, it does mean that
proprietary developers licensing Chandler from the OSAF will be required
to purchase a professional BK license in order to keep their changes
private, or else they will have to mainatin their changes in an
incompatible SCM solution.

Imposing an additional burden on proprietary developers who wish to
license Chandler's source code would seem to be incompatible with the
OSAFs plans.

Furthermore, BK's license precludes users from working on competing SCM
systems. This seems excessive and worrisome, especially as I can imagine
someone wanting to integrate a GUI SCM browser into Chandler.


Potential future licensing changes
----------------------------------
The restriction against BK users working on any other SCM solution is a
relatively recent change. There are no assurances that some future
licensing change won't be even more burdensome. For this reason, I would
be very reluctant to propose that we use any proprietary software in an
infrastructure capacity, regardless of it's technical merits.

Sincerely,

Michael Bernstein.