trans-coord-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: building vanilla gnu.org-i18n


From: Kaloian Doganov
Subject: Re: building vanilla gnu.org-i18n
Date: Thu, 27 Dec 2007 19:56:49 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.50 (gNewSense gnu/linux)

Yavor Doganov <address@hidden> writes:

    Nothing could be simpler than a make recipe that adds *exactly* the
    same file it operates with.

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

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.

But my technical intuition still tells me that the whole system will be
more manageable and debuggable if we separate the rebuilding of
translations from cvs operations as two distinct stages, glued together
by the cronjob script which executes them sequentially.

    This is not just a whim -- the whole system would be much more
    powerful if we extend it taking this road.

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

    > We do not need any hostname checks

    This is just to prevent a translator (or a webmaster) of actually
    modifying the repository (OK, provided that we don't add
    directories, there's no way to modify the repository except "cvs
    commit" where everyone with write access should check what she is
    checking in...)

    The conditional variable that I'm talking about should be enough for
    this purpose.

My point was that this machinery is uneeded if the add/commit job is
performed by the cronjob script.  E.g. translator (or a webmaster) that
does not run this script intentionally, can not modify the repository by
accident.

    >     3. Examine working copy and collect new filenames that should
    >     be put under control (possibly grepping through `cvs status').

    On a 300 MB repository with lots of files that is a horrible thing.  We
    know what should be under CVS control at build time, so we'd better do
    it then.

Is `cvs status' so horribly expensive?  Maybe I'm mistaking it with `svn
status', which is very lightweight.  If running `cvs status' for the
whole working copy is so expensive, then I agree with you – we should
avoid it.  And introducing conditional variable will be reasonable
approach.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]