Re: Best practises for Configuration Management before build

On Aug 31, 2009, at 8:23 PM, Arthur Barrett wrote:

> Paul,
>
>>> I do not want the benefits of continuous integration to act as a
>>> disincentive to commit early and often
>>
>> I have still a different stance:  Never, ever discourage
>> someone from checking in their code
>
> Erm... I thought that was *exactly* my point.

Having re-read your post, I agree!

>
>> One successful implementation of this has been discussed at some
>> length in this forum.  Search the archives for "submit/assemble".
>> That particular method provides a means to accumulate good changes
>> (and back out bad changes) in a way that's repeatable with
>> reproducible results.
>>
>> In my implementation, defect tracking was tightly integrated with
>> version control and the work flow.
>
> Tony and I and March Hare Software and lots of other people have put a
> lot of effort and time into extended CVS to do these extra things for
> people who need it.  Since 'traditional' users of CVS have no
> desire/need for the overhead of these extra 'features' it got put in a
> separate 'CVSNT' project.
>
> However recently I've been seeing anecdotal evidence that 1) many of  
> the
> people using CVSNT don't use or understand the extra capabilities, and
> 2) people who need/want those extra capabilities 're-invent the wheel'
> rather than use CVSNT.
>
> It does make me wonder how effective the free software movement is if
> noone looks for existing freely available source code before writing
> their own solutions.
>
> Can you offer any insight, from your own experience?

More than likely it's because:
- These tools are aimed at programmers who like to invent things that  
they understand rather than learn about things they don't.  Certain  
value-add features like flow control are easy to understand whereas  
core version control oftentimes is not.  Or they write "something  
simple" without thinking about it, and it grows organically.
- People will prefer tools that they know over tools they don't.  With  
regard to version control, the tool they used in their prior job is  
almost always better than the current one, unless they happen to be  
the same tool with minimal refinement.  This plays a role if there's a  
conversion.
- People will prefer tools they've heard of over tools that are new to  
them.  The FSF and Gnu project have enormous name recognition, so  
people will look there first.  Also, I can go to any non-technical  
bookstore here in Silicon Valley and find 2 titles about CVS, 2 about  
SVN, and none about CVSNT.  People looking for version control tools  
will find CVS first for this reason, and will refine it themselves  
rather than convert to something else later (assuming it falls in  
their lap).
- Even if people have heard of both CVS and CVSNT, the similarity of  
the names (and in CVSNT's case its similarity to a well-known  
operating system), people draw the wrong conclusions about CVSNT and  
don't look at it seriously.
- The value-add features people need don't yet exist in software  
distributions and find no compelling reason to change when they  
eventually appear and stabilize.  This is what happened with submit/ 
assemble:  Nothing in the open source world fulfilled that function  
when I invented it in 1992.
- Sometimes custom software that solves 100% of a problem is more  
compelling than an 80% solution that can be refined to a 95%  
solution.  Even if the 80% solution can be refined to be a 100%  
solution, the nature of the hooks may make a refinement more  
cumbersome or fragile than custom programming.