> > The way we have to update the www.gnu.org and www.nongnu.org webpages > > is to call a CGI script using curl that will trigger a checkout and > > update/create the remote webpages. They will then be updated by a > > cronjob at www.nongnu.org. So, if the CGI script is called during > > creation *and* each time sv_groups is launched at Savannah, it is not > > good for us. Above all, we do not know whether the webpages are > > already created or not, so we cannot stop calling the CGI scripts > > during later sv_groups executions. > > This shows that this approach of cgi is a bit crappy, and that's > probably what should be fixed first. > But I'm pretty sure it's not up to you to change that. Funny to see > some project that got at most 4 servers to manage and that behave like > administrations that have 2000 servers to handle. > > > But, what I am wondering is why calling CvsMakeArea & co at each > >sv_groups call. I considered those are useful only at project > >creation. > > Simple example: project A is created and deactivate download > area. Download area is not created by sv_groups. At some point, > project A decide to use it. sv_groups create it. Project A estimate > his CVS tree content is fucked up and want to restart it from > scratch. An admin erase the cvs directory and sv_groups will recreate > it as it creates any other project CVS. > This way, you never enter case where you are forced to run manually > some commands to get the directories created. > And how the hell could it be a problem that each time sv_groups does a > check `unless -e $cvs_dir`? > sv_groups, when it was firstly installed on savannah.gnu.org, the > bi-PIII owned by FSF France, in the old days, was running in less than > 6 minutes -- acceptable time for such cronjob. > Having a "clever" script that do trivial checks to make sure > everything is in order seems a good thing to me, especially when it > does not seems to clutter up the server. > > Now, your problem is the fact that backend is itself a frontend for > another backend, and this late backend you have no control on, at all > -- you cannot even now if an action was succesful or not. In my > opinion, this is really a broken thing. > But I assume you cannot change that. So, to deal with this situation > far from the ideal one, I would that that you need a specific > CvsMakeArea, like CvsMakeAreaAttic. > > CvsMakeAreaAttic is used at Gna! (the strange name of this sub is a > residual from the very start of Gna when the name was still undecided) > run CvsMakeArea and do extra commands. > > Yours can run CvsMakeArea but call this only CGI only in some specific > cases. For instance, CvsMakeAreaAttic run gna specific stuff > (automatic configuration of mail notifications) only if CvsMakeArea > returned something true. But CvsMakeArea with return false if the CVS > directory was already existing. > I guess your CVS have to be called only at creation. So only if > CvsMakeArea return something true.
I guess that's what I'll do :) Incidentally, the CGI approach might be useful actually. Let's say that a mailing list provider (eGroups, Google Groups...) offers a SOAP way to create mailing-list. You could decide to move all your mailing lists there and keep your resources for version control (for example). In that case, you wouldn't run the backend at your MLSP (mailing list service provider), but still you would need to create them via SOAP. > >> > Incidentally, this behavior also led my test install to reuse the > >> > existing "gnats" group from Debian, while not creating the associated > >> > "webgnats" one and ruining the 'gnats' project installation. > >> > >> The current CVS no longer mess with existing groups. > > > > I use the current CVS. Do you mean the current CERN branch? > > No, I really mean the current CVS. But in fact, it does not mess with > users not created by Savane. But for groups, it can still actually > modify existing groups. > > I have no clear thought about this. It is easy to determine whether a > user was creating by Savane. Not for groups. As I said in the other mail I would be happy to work on the way groups are managed... later :) Nevertheless, one way to handle this issue would be to create a 'savanenobody' user that would be added to all Savane-generated groups. Plus a Perl script in 'update/1.0.x' to add this user to all groups present in the database and the system. That doesn't hurry, though. -- Sylvain _______________________________________________ Savane-dev mailing list [EMAIL PROTECTED] https://mail.gna.org/listinfo/savane-dev
