Hmm, it also occured to me that there may be issues in big repositories (like project 'www'), in a commit that spans multiple directories. This will trigger new.py for each repository, spawing several concurrent checkout. I'll have to rely on commit_prep for this job before to activate it. I'll also add a background 'sleep' before to call new.py, that will give CVS the time to clean-up the locks.
Once that's done, and if the following sounds good to you, I plan to activate the hook. -- Sylvain On Tue, Dec 20, 2005 at 02:04:11AM +0100, Sylvain Beucler wrote: > Hi, > > 1) I'm ready to start calling new.py on each new commit in /web > repositories (sync-on-commit). > > Technically, I think you could desactivate the hourly cron job. > > Also, maybe new.py can conflict with the hourly cron job, if both are > activated at the same time. > > Any comment on this? > > > Info: > > The loginfo line is like: > ALL /usr/bin/curl http://...../...../new.py -s -F type=non-gnu -F > project=testyeight > > I have a script in /subsystems/cvs/root/generate_log_accum.pl that > recreates all CVSROOT hooks. > > > This just takes care of the delay issue. Complete interaction would > namely include project relocation on group type change (non-GNU -> > GNU...). > > > Questions on future design: > > 2) Requests like > https://savannah.gnu.org/task/index.php?func=detailitem&item_id=3580 > would imply performing changes on the checked out working copy (in > this case, running texi2html on the texi file). > - would that be possible at www.gnu.org, after the cvs update? > - would it be acceptable to do so at Savannah, then have nadesico > rsync the directory (instead of cvs update) > > > 3) If I say: let's support GNU Arch instead of CVS > for web repositories. > > Or even: let's support direct (non-SCM) access to the web pages. > > Does that sounds acceptable to you? Both kind of access were requested > by users.
