Re: building vanilla gnu.org-i18n

[Kaloian Doganov]

Yavor Doganov <address@hidden> writes:

    > But how the make recipe will avoid readding those files that are
    > already under version control?

    Simple: Just like we currently do for genreic.xx.html files.  In the
    .pot targets, we first check if the target exists (that's a very
    cheap check) and cvs add it if not.  Alternatively, we always cvs
    add it (with `cvs -n' by default) but this approach is bad because
    if the file is already added, cvs will exit with code 1.

Having the file in the filesystem does not necessarily mean that the
object is already under a version control.  For example, one could run
the rebuild target without CVS_ADD option just to check the results, so
new html files are generated and are fine.  Then running the same target
with CVS_ADD would not cvs add the apropriate files, because they will
be present in the filesystem already.  The following commit will be
performed without errors and we'll end with incomplete commit.  On
subsequent runs this confusion will continue until someone notices that
those html files are missing from the repository.

Relying on such fragile assumption (having an object on the filesystem
in the working copy means it is under version control) is not good, but
using the `cvs status' method on the whole working copy is even worse
(as explained below), so I agree we should do it the way you suggest.

    > The same statement can be expressed about `cvs commit' too:
    > 
    >     Nothing could be simpler than a make recipe that commits *exactly*
    >     the same file it operates with.

    Precisely, but we don't do this because 1) it will generate many
    messages to www-commits;

Right.  This illustrates that using "global variables that override the
default behaviour" does not make the system inherently flexible.  There
are features that can be implemented reasonably only by executing
another "stage" or "phase" in the computation chain.

Anyway, I agree that `cvs add' is not of this kind.  It can be
implemented by either approach.

    2) `cvs commit' is reliable enough to do a recursive check and
    decide what needs to be checked in.  No grepping, no parsing, no
    error-prone operations (modulo CVS' known and unknown bugs in its
    internal implementation, which nevertheless is far more efficient
    than your suggestion).

I didn't suggested to replace `cvs commit' with something else.  The two
discussed options didn't differ in this part.  Raising arguments on this
issue does not add to the discussion.

    > My point was that this machinery is uneeded if the add/commit job
    > is performed by the cronjob script.

    Not always.  Sometimes we may need to switch off the cron job, for
    example when we add new functionality or when the web designers go
    crazy.  Running the build manually should always be possible (and
    easy).

Cronjob could be turned off and running the the build manually is
possible in either case, so I don't see difference here.

    > E.g. translator (or a webmaster) that does not run this script
    > intentionally, can not modify the repository by accident.

    She will not after I implement my idea.  It is like if the package
    has an optional testsuite -- you won't run it until you do `make
    check'.

Again - no difference.

    > Is `cvs status' so horribly expensive?

    To the extent that I never use it without a file as an argument.
    Just try it.  It recursively checks the status of every file, file
    by file.

You're right.  I've played with it a little bit and now I'm sure we
should to stay away from it if we can.  Not only it is slow, but it's
output is not suitable for parsing.  In Subversion, the `status' command
is fast, does not require network activity, and parsing it's output is
straightforward:

   svn status | grep ^? | cut -c 8-

Returns instantly and lists the filenames that are not under version
control.  That's why I've thought it would be a good idea in the first
place.

Switching to Subversion is out of question, of course.  So, I am
convinced that it is better to implement your suggestion.