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.
