[Top][All Lists]

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

Re: Intelligent CVS trigger?

From: Todd Denniston
Subject: Re: Intelligent CVS trigger?
Date: Wed, 21 Mar 2007 11:37:29 -0500
User-agent: Thunderbird (X11/20060909)

Hans Schwaebli wrote:
For our daily and nightly builds it would be good to use CVS trigger which touches a file after a commit. Then only this file would be checked to determine if a build is needed. But this trigger would need to be intelligent. It must only touch the file if files with certain extensions have been committed. For example a new build is not necessary if someone checks in a Word document. Furthermore we need two such touched files, one for the HEAD and one for the release line branch. If someone checks into the release line branch, the trigger must not touch the file which represents modifications on the HEAD. It must instead only touch the file which represents modifications on the release line branch. Please consider that I am a windows guy and that our CVS server is a Linux machine. So it would be nice if you can tell me a example script or something which makes it easy to implement this. Thank you very much.

suggestion look at the commitinfo trigger script commit_prep and the loginfo script log_accum, they come with cvs in the contrib directory. you might be able to find them by doing `locate commit_prep` on the server machine as some distros include a copy of the contrib directory some where in the install.

you can probably modify one or both of them to do the `touch rebuildindicator` at the appropriate time.

We have to do the whole thing because CVS needs a lot of time to determine whether modifications occured.
It takes at least 15 Minutes.
By just checking one file for its touch date,
this can be speeded very much.

how many hundreds of Mega Bytes of binary (archives, compiler output, word docs) files do you have in your SOURCE tree???? Or are you doing your update across a modem line?

I can understand having word docs in the tree, but it would seem a good idea to have them in a "Documentation" subdirectory which is separate from the "Source" directory, so that A) you don't have to check them out if all you ever work on is source, B) they don't trip up scripts that rebuild the tree when some source file changes.

if you HAVE to have archives (tar, zip, jar) it is usually a good idea to have them in a third subdirectory tree like "ThirdPartyBinarys", or the better idea is usually to have them in a network readable directory structure and have the make/ant/build_script pull them from there (with the possibility of a local store for developer built ones) ... archives used to build your programs should not change often.

Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter

reply via email to

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