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 [EMAIL PROTECTED] 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:[EMAIL PROTECTED] http://www.freepository.com _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
