Re: [Savannah-hackers-public] sync-on-commit

[Sylvain Beucler]

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.