[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Best practises for Configuration Management before build

From: Paul Sander
Subject: Re: Best practises for Configuration Management before build
Date: Mon, 31 Aug 2009 22:37:06 -0700

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


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]