[Asterisk-Dev] Source Code Management

[Steven Critchfield]

On Wed, 2005-04-13 at 22:48 +0100, David Woodhouse wrote:
> 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.

> Let's go through the wiki...
> 
> 	Needs
>    * Good user permission/separations per branch
> 
> Everything has this -- CVS can do it well enough too.

Yes, but what level of crap does the administrator have to go through to
achieve it and maintain it. Lets not create new, non revenue work for
Digium. 

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

Pace isn't the problem. There seems to be a desire to get more people
into the fold that can commit. Few people committing like mad won't
conflict with each other often, but many people committing semi
regularly are more than likely going to have worked on the same files
and potentially have troubles. 

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

This is a mixed need. There are patches that have been deemed not worthy
for inclusion, yet people want to maintain them. No cleaning up will fix
that problem. 

Specifically there is a group of people who seem to want XML in the core
of asterisk. Some of us don't want it there. There is a potential for a
fork to satisfy needs. If those who would like it added only need to
branch and apply their patches on top of the primary repository, we only
have a splinter not a fork. 

>    * 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? 

I'll agree that it wasn't worded well. I'll add that whatever system
that is used, then begs the question of how much of the development work
is easily available to the general users. If we keep most of the
branches as "experimental" and you have to know how to use the tools to
get them, then it isn't that bad. But if we are implementing features
that we need pushed out to the users, we will either need easy tools for
them to access those feature sets, or release tarballs more often of the
snapshots of development.

>    * Proper rename/remove support
> 
> Theoretically, maybe. In practice you'll almost never need it in a
> project of this size.

We don't see renames all that often, but removes happen. Think recently
back at the change of AGI from an app to a resource. Unlikely you would
rename/move the source from one place to the other, but it is possible.
It is more likely to remove the original file and the newer version
appear at the new location.

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

But as my response is my opinion, and yours has been expressed here as
well, we need to come to a consensus of what is desired and what is
needed. Then make a educated decision on what will best fulfill the
needs and desires. I know we are likely to walk a fine line on the edge
of a religious war, but it occasionally has to be done as new ways of
developing software become available. 
-- 
Steven Critchfield <critch at basesys.com>