[Asterisk-Dev] Source Code Management

David Woodhouse dwmw2 at infradead.org
Wed Apr 13 14:48:28 MST 2005


On Wed, 2005-04-13 at 14:46 -0500, Jeffrey C. Ollie wrote:
> I think that the key question that isn't on the wiki is: do we want a
> centralized or a distributed development model?  There are pros and
> cons to each, and I haven't really made up my mind as to which I would
> prefer.

To be honest, given the pace of development and the desire for
disclaimers I don't really see any benefit in a non-centralised model.
Better rename support is a cute toy, perhaps, but in practice in a
project the size of Asterisk it's just that -- a toy. Seriously, how
many times in recent history have we _cared_ that CVS sucks a little bit
at renames? 

While I see the point in it for the kernel, I really don't see any real
reason to switch projects like Asterisk off CVS.

Let's go through the wiki...

	Needs
   * Good user permission/separations per branch

Everything has this -- CVS can do it well enough too.

   * Atomic commits

Really? The pace of development is such that there are conflicts between
commits? You surprise me. It sounds like theoretical masturbation rather
than a real requirement.

	Wants
   * Easier maintenance of private change sets

This isn't necessarily a good thing. Don't make it _easy_ for people to
keep private change sets -- make the buggers fix them up so they're
acceptable for merging, and get them _merged_.

   * Availability to the Mac, *BSD, and Windows groups without too many
     hoops.

That goes for CVS, certainly -- and probably most other alternatives.
Users of non-Linux systems have enough pain with obtaining software
anyway; I don't think we have to worry too much about them from this
POV. Besides, CVS is fairly much ubiquitous, which is more than can be
said for the alternatives.

    * Good binary file handling (for handling sounds, iaxy firmware)

Define 'good'. CVS doesn't handle deltas between binary files well, but
that doesn't matter much for sounds where it's going to be fairly much a
complete replacement anyway. For firmware perhaps this requirement does
make a small amount of sense though.

   * Tagging & branching that can be understood by non-CVS gurus

Very strange requirement. Why not "Tagging and branching that can be
understood by non-SVN gurus" or "by non-arch gurus"? Branching and
tagging in CVS isn't any harder to understand than in anything else,
surely? 

   * Proper rename/remove support

Theoretically, maybe. In practice you'll almost never need it in a
project of this size.

   * Good merge support

I've used BitKeeper's much-hyped merge support, and I've used what CVS
does. To be honest, I prefer the latter. And again, in a project of this
size it's _more_ than sufficient.

   * Web interface for browsing source code repository
   * Documentation (esp. a "new-cool-scm-tool for CVS converts" document)
   * Emailed commit logs
   * Interface to mantis bug tracker

All these can be provided by anything.

-- 
dwmw2





More information about the asterisk-dev mailing list