[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Continuous Integration and CVS
From: |
Doug Lee |
Subject: |
Re: Continuous Integration and CVS |
Date: |
Wed, 26 Apr 2006 19:58:58 -0400 |
User-agent: |
Mutt/1.5.9i |
> >>My own preference is to use a build system that is driven from the CM
> >>system (ie: build when changes are merged onto the build branch).
> >I sometimes wonder whether my style of working would screw this up :=)
> >When I check in changes, sometimes I separate the commits into several
> >commits, based on the specific changes made (all changes are usually
> >related in some way). If the automated system kicked in after the first
> >commit, the build may fail. Do you include some kind of delay to see if
> >there's another checkin within, say, two minutes of the first?
>
> This is one of the reasons why the submit/assemble method (discussed
> many times in this forum) is successful. It doesn't constrain the
> developers' commits, and it requires the developer to declare that code
> really is ready for prime time. Submitting is quick, and once done
> there's a queue of changes waiting for integration.
>
> The mechanism can be easily built with atomic transactions, thus
> eliminating the sort of race condition that Jim describes. 'Course,
> there's still the issue that the developers must make complete
> submissions, but there are ways to assure that.
>
> It also has the benefit that submissions can be backed out in the event
> of a mistake. So depending on the goal of the subsequent integration
> (compilation vs. compilation without errors, for example), it's
> possible to automate a solution that can guarantee a high quality
> output.
I suppose my solution is odd, but just for a data point:
I have a situation in which I'm the only developer but there are
several people that might check out sandboxes just to build from. My
implementation involves two repositories and rsync: I update the
master repo at will, which allows well-documented and sometimes
split-up commits. I rsync from that repo to the checkout repo when I
have a stable product update to offer, simultaneous with an
announcement of changes included. Of course, this strategy doesn't
work so well in the multi-developer environment for which CVS was
initially designed, unless there is very good internal communication
among committers to the master repo; but it occurs to me that my
approach could be used effectively to handle a number of security
concerns I've seen raised here, by separating readers from writers.
One could, for example, put up a public CVS server that is updated via
rsync periodically from a more private writeable CVS server, so any
hacking against the public server can't destroy the actual content.
--
Doug Lee address@hidden
SSB + BART Group address@hidden http://www.ssbbartgroup.com
"All these years, the people said, 'He's acting like a kid.'
He did not know he could not fly, so he did."
--Guy Clark, "The Cape" (Dublin Blues)