info-cvs
[Top][All Lists]
Advanced

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

RE: Build environments using CVS


From: Paul Sander
Subject: RE: Build environments using CVS
Date: Thu, 21 Oct 2004 02:11:12 -0700

>--- Forwarded mail from address@hidden

>Brian Blignaut wrote:
>> Firstly let me say that if this is not the appropriate place 
>> to ask this question I apologize, I am just not sure where 
>> else to post.
>Yes, this is the appropriate place to ask.

>> I am trying to setup a build process that works 
>> with CVS tags and am having a bit of a problem.
>> 
>> The Build Environment
>> 
>> 
>> 1. Development - developer's adding/changing/fixing code
>> 2. Testing - with software testers, and test data - TEST tag
>> 3. Release - Software built for release to client - LIVE tag
>> 
>> 
>> The Problem
>> Deleting files from CVS retains the TEST, LIVE tags.  As a 
>> result the files that not meant to be built are being 
>> included in TEST, LIVE builds.

>It sounds to me like you are re-using the tags "TEST" and "LIVE". I'd
>recommend using unique tags instead, e.g. proj-rev-x-y-build-z

>If you really want to re-use TEST and LIVE tags, then you should use these
>in conjunction with the unique tags. You will have to manually delete the
>TEST and LIVE tags before you remove the file. You might want to write a
>small script to do this, and encourage everyone to use the script rather
>than directly issuing the command 'cvs remove'.

>Actually, you can probably enforce this using the commitinfo script - if a
>file is being removed, and it has a TEST or LIVE tag, the commitinfo script
>can abort the commit with an error message telling the user to remove the
>tags first.

You might also consider using a change control method that's not based
on tags.  Search the info-cvs archives for "submit/assemble" for discussions
on a handoff and integration method that can handle the addition and
removal of files, and also collects changes in a way such that they can
be reversed.  This method has been used with great success on a number
of projects of varying size.

>--- End of forwarded message from address@hidden





reply via email to

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