Re: Intelligent CVS trigger?

[Todd Denniston]

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