info-cvs
[Top][All Lists]
Advanced

[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)




reply via email to

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