Re: Continuous Integration and CVS

[Paul Sander]

On Apr 26, 2006, at 9:16 AM, Jim Hyslop wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Arthur Barrett wrote:
> > Ben Rady,
> > > Therefore, if Anthill creates a tag from it's
> > > working directory using 'cvs tag', the build
> > > artifacts created from the build can be perfectly
> > > reproduced by checking out that tag.
> >
> >
> > Yes - in fact I avoid rtag because unless you can lock all the users 
> > out
> > of the server there is potential to rtag a version you didn't intend 
> > to
> > (because someone has committed a change).
>
> I concur, Arthur. The safest way to mark a snapshot as "correct"
> is to do a fresh checkout and 'cvs tag'.
>
> > 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.

--
Paul Sander       | "To do two things at once is to do neither"
address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.