Re: Making gettext CVS friendly

[Bruno Haible]

Pavel Roskin writes:

> Anyway, let's use GNU Midnight Commander.
> 
> $ cvs -d :pserver:address@hidden:2401/cvs/gnome co mc
> $ cd mc
> $ ./autogen.sh # this runs autopoint and configure among other things
> $ make
> 
> You see that mc.pot is generated and all *.po files are rebuilt.  Now 
> let's see if we have modified files:
> 
> $ cvs up
> M po/az.po
> M po/be.po
> ...
> 
> That's a problem.  If somebody modified po/az.po in the meantime, I would 
> have a conflict.

Indeed, and it takes an awful lot of time for cvs to compare these
files, thus it slows down "cvs update".

> I checked the rules, and it's clear that the reason for remaking of all 
> files is that mc.pot is newer than all of them:
> 
> $(POFILES): $(srcdir)/$(DOMAIN).pot

That by itself shouldn't be a problem, _if_ the resulting mc.pot file
would be identical with the one that was used to update the .po files,
including its POT-Creation-Date stamp. The problem is that the
xgettext invocation puts into the .pot file a timestamp which is
different from everyone else's timestamp.

> GNU Midnight Commander uses CVS is the way CVS authors intended it to be
> used - no dependent files under version control.  This means that
> po/mc.pot is not on CVS.

I and the other gettext guys will work on it. In the meantime, you can
get rid of the hassles by putting po/mc.pot under CVS, as the gettext
documentation suggests:

    ...the maintainer can omit from the CVS repository all the files
    that `gettextize' mentions as "copy".

> > You are the first to report a CVS conflict with PO files.
> 
> Sometimes I get bugreports for the bugs that existed for years.  Not
> everybody has time and desire to report problems, especially if they seem
> to be design limitations rather than simple bugs.

It is just as important to report design limitations as it is to
report simple bugs.

Bruno