Re: [HACKERS] missing mugshots
От | wieck@debis.com (Jan Wieck) |
---|---|
Тема | Re: [HACKERS] missing mugshots |
Дата | |
Msg-id | m11hjGv-0003kLC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] missing mugshots (wieck@debis.com (Jan Wieck)) |
Список | pgsql-hackers |
> I'll play around a little with CVS rules (don't know exactly > how to set them up but I know that they exist). Will tell you > later if this is something worth to try. Whow, never thought it would be that easy! If we place a tiny little script #!/bin/sh cd /home/projects/pgsql/ftp/www cvs update </dev/null >/dev/null 2>&1 & echo "" echo "Main WEBsite will be updated automatically." echo "The appropriate 'cvs update' is already waiting" echo "in background for your locks to be released." echo "" into the same directory it cd's to, we only need to add the line www -i /home/projects/pgsql/ftp/www/<script> www to the modules file in the CVSROOT and anyone with a local checkout must do a new checkout. Also we checkout the actual working directory of the real site again and voila, anytime someone does a commit a 'cvs update' is automatically started in the web sites root directory. It must run in background to avoid a deadlock, so be it. The echo messages are visible to the one doing the commit, so it's just to remind that he's doing something visible to the world. As said, anybody should WORK in his private checked out working directory at home. This would prevent side effects if multiple maintainers work on the real files. But for very small changes, it would be O.K. to do it on the main site and commit them there, because the cvs update started in background would be a noop in fact. Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #========================================= wieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: