> > If you think there will be too much extra processor time,
> > the script will take on the server, doing nothing, because
> > the commit changes no Revision number, we can introduce
> > a flag in CVS commit messages, so eg:
>
> No, I was just thinking about a scenario where someone who doesn't use
> revision comments commits both a new version of a file and updates
> Translators too (we should keep that one too, it too has useful purpose),
We can make the script update the Translators file automatically.
This proves best that the Translators file is just a copy
of the file's Revision comments. :))))
> and somehow through a strange interaction of running scripts on the server
> and the order of files committed, Translators gets changed back or there
> comes CVS conflicts with files that are edited both manually and by a
> script, or something.
I dont' think that running an automatic script on CVS commits
are a thing that is mistified :) The script mailing the commit
message and diff is just an example of this. Although changing
the Translators file with the script can raise some problems,
as a script is a CVS client in this case, hmmm...
> But I really didn't think about it more than 5
> seconds, so there's a very strong possibility that what I'm saying is just
> pure bullshit and doesn't need any more discussion, at least for now.
The biggest problem is how a php script can update a file
as a regular CVS user and make a new revision of it. This
can be the case for the script automatically updating
Translators or some "Revisions.html" file in the same dir
as Translators with the HTML tables generated by the script.
> Anyway, a flag in commit messages would be a working solution to a
> problem that I'm not sure even exists :)
The revision checking script can run with every commit, check
what languages files are affected, and update the corresponding
files, or run only when there is a [WRC] flag in the commit
message, reducing the useless script runtimes with the flag.
Goba
