Re: CVS export

[John Minnihan]

Why use export?  Overnite builds are very common and needn't cause you 
any undue pain.  Use a disposable build tag (aka release tag), such as 
"Application__Overnite__12345", where the digits are an incrementing 
build number that is guaranteed to be unique.  Then simply 'cvs co -r 
Application__Overnite__12345' to get the sources for your build.  This 
is straightforward to automate and creates a visually informative trail 
in the logs.  Tags are cheap - tag early, tag often.

If you are trying to avoid the CVS admin directories with export, I 
would again ask *why?*  Your build system should ignore those 
directories as it traverses through the working directory processing 
targets.

If you don't already use ant, consider it.  I've used make, nmake, and 
all manner of convulated invocations of cc, gcc, javac and jikes.  Ant 
reduces all that nonsense to a fairly easy-to-grok model.  It is 
especially good at dependency analysis.

An example of this using classic make is availble here:
http://jbminn.com/misc/build.pl.txt

The BuldEnv.pm used above is here:
http://jbminn.com/misc/BuildEnv.pm.txt

address@hidden wrote:

> Hi,
>     I'm trying to use cvs export to do a "nightly build" sort of thing.
> I'm trying to get the current versions of the main trunk exported to a
> set of directories that I'll use to perform a build.  I've tried using
> "-D " and today's date, but cvs misses some files that way.  Do I have
> to go through my modules and create a "fake" tag for each of them before
> I export, or should I just use "checkout"?  Any suggestions?
>
> --
>      -Thanks,
>       Tom Sanidas,


--
John Minnihan
mailto:address@hidden
http://www.freepository.com