> > As I heard, we can make the revcheck.php script
> > run on every commit, so the table can be autogenerated
> > on every commit, and there would be no need to run
> > it manually in most of the cases.
>
> Otherwise a good idea, but that would be also forcing everyone to the new
> system... would it be OK if we just require the people using revision
> comments system to also run a script that updates Translators too and
> commit both ones?
We do not force anybody, if no revision comment is changed
with the commit, then the same revcheck.html will be
regenerated by the script, as was the last time, it
was running. With asking people to always run the script, and
commit both files, we loose one of the best things of Revision
comments, the "change only one file" philosophy.
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:
updating translations [WRC]
would mean, the script shoud run (With Revision
Comments = [WRC]), but
updating translations
woule mean that the script should not run, as there is
nothing to update. So the script can be programmed to
only run in commit cases where it is needed, flaging
the needed cases with a [WRC] substring.
> So, if we at some time in the future realize
> that over 90% commits are using revision tags, we can come to the
> conclusion that the revision comments system has won.
And if this will ever happen, we can drop off the [WRC] commit
message substring, and all commits will update the revcheck.html
files.
Goba
