Re: building vanilla gnu.org-i18n

[Yavor Doganov]

Калоян Доганов wrote:
> 
> 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.

> 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; 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).

> But my technical intuition still tells me 

I guess I don't have technical intuition (at least not in the
programming field), but this was my feeling as well.  But I've been
thinking a lot about this.

Ah, see how Nic Ferrier does it in rss/Makefile:

# Options for CVS commands. Set to:
#  -n
# if you DO NOT want commits to be performed.
CVSOPTS=

# The command sequence we use to add non-existant files to CVS
define addfile
[ -f $@ ] || ( touch $@ ; cvs $(CVSOPTS) add $@ )
endef

# New language specific targets.
whatsnew.%.rss: ../server/whatsnew.%.txt
        $(addfile)

Exactly my idea!

> I still do not see how it will be more powerful.  Please explain.

I wrote in a separate message that I sent before receiving yours.

> 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).

> 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'.

> 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.

> Maybe I'm mistaking it with `svn status'

Yes, they are drastically different.