Due to time constraints, I made very simple changes to achieve what I needed. I did not make it very generic, but I think what I have might be useful to others.
I modified sv_aliases.pl, Groups.pm, and Cvs.pm. In sv_aliases.pl, I added a call to PrintGroupAliasesList(), which is a function I added to Groups.pm. This function adds aliases to the /etc/mail/aliases file for each project group, where the group name is the alias for all the member emails. In Cvs.pm, I modified the CvsMakeArea() function to do 2 things: 1) symlink to $dir_cvs/../OMMON-SCRIPTS/log 2) append a line to the project's cvs loginfo file for using the 'log' script. I spent a lot of time playing with log_accum, but couldn't get it to work for me. So I gave up on it. I will post these patches up on the Savane Bug tracker, and hopefully you find them useful. Armando Sylvain Beucler wrote: > On Tue, May 23, 2006 at 12:08:07PM -0400, Armando L. Caro, Jr. wrote: >> Sylvain Beucler wrote: >> >>> I'm currently using this script: >>> http://arch.savannah.gnu.org/head/administration/infra/main/0/cvs/generate_log_accum.pl >>> to configure all CVS commits notifications site-wide. >>> >>> However, I need to work on it to support the new version of log_accum >>> (Derek R. Price and I merged Savannah version with the one in CVS' >>> contrib), and more importantly I'd like to integrate it in the Savane >>> web interface. >>> >>> Since you plan to develop a script, would be be interested in helping? >> Well, I could help somewhat. I'm working on back end support, but I >> don't think I want to spend time on front end support (ie, web >> interface). If someone else wants to work on that, that would be helpful >> and useful. When I'm done, I'll contribute what I have. > > Ok, I could deal with the web interface. > > Here're my suggestions about the backend: > > - the code could go in sv_groups, because it already cycles through > all projects with CVS activated. Instead of calling > Cvs::CvsMakeArea, it would call Cvs::UpdateLogAccum or something > like that. The other option would be to create a separate cron job > script, but that sounds like rewriting lots of existing code. > > - you can base your code on mine above, unless you already have one > working. I planned a few improvements on it: > > 1) support the new version of log_accum at > http://cvs.sv.gnu.org/viewcvs/ccvs/contrib/?root=cvs which should > be working now (I'm about to switch to it, since the merge with > savannah's version is finished). It's just about using slightly > different command-line options. > > 2) in order to support project-specific CVSROOT/loginfo lines, I > think the script should only replace a section between #<savane> > and #</savane> (like sv_aliases) instead of overwriting the whole > loginfo/commitinfo. I have some projects that need special > actions, not managed through Savane, and it's a pain when those > are overwritten by my cron script :) > > 3) there's a couple input validation to implement (documented with > "TODO"), eg. so that users cannot use a weird module regexp to > trick the system into executing arbitrary commands. > > - we need a new database to store the log_accum parameters. I think it > should match what I'm using in the log_sources.txt / log_web.txt > that I'm using, which means the database should be pretty simple. We > need to attach a log_accum configuration to a _type_ of cvs > repository, though, because you can can create a lot of different > cvs repositories with Savane (scm-cvs, web, download, etc.). One > additional field should be enough to deal with this, but I haven't > checked. > > - think of a generic way to do this, allowing to easily add support > for other scripts later on (CIA, other notification mailers such as > cvsreport which is used by Gna!, webpages sync-on-commit, cvs_acls, > etc). > > Maybe Mathieu has some suggestions as well on the best way to add this > new backend action. > > Feel free to discuss it :) > > >> I'll ping you if I have trouble using/configuring log_accum. > > Ok. Just use the HEAD version :) > > > As for the frontend, I think that: > > - loginfo/commitinfo update will be activated unconditionnaly if cvs > is activated > > - the user will not be able to enter a full regexp, but only either of: > * a list of directories > * DEFAULT > * ALL > > - the user will be given a set of options to define, including diff > options, mail to send notification to, mail to send diffs to, > activate diffs or not, etc. > > - you tell me if you think of something :) > -- Armando _______________________________________________ Savane-dev mailing list [email protected] https://mail.gna.org/listinfo/savane-dev
