Re: CVS & Gettext

[Bruno Haible]

Paul D. Smith writes:

> The overhead of updating these files and keeping them correct is more
> than the overhead of keeping the tools synced between multiple
> developers, because there is zero cost associated with the latter.
> ...
>   bh> 1) It copes well with incompatible changes between gettext releases,
>   bh> whether intentional or accidental. It doesn't put a burden on the n-1
>   bh> developers that didn't do the upgrade.
> 
> In the case above, n=1 so n-1=0.

You have a point.

Paul Eggert writes:

> So I'm afraid that in practice (c) encourages maintainers to avoid
> upgrading their software distributions to use the latest gettext
> release.

Good point as well.

You will find your suggestions addressed in gettext-0.11.3.

>  4) (optional) Perform error _checking_ and generate warnings for
>     incompatibilities that are so detected

A script cannot check for incompatibilities between the current and
future, not yet released versions. Therefore the solution is to
maintain enough version numbers here and there, and allow only files
belonging to the same gettext version to operate together, so that
incompatibilities are avoided a priori.

>     but do not take any action
>     to resolve these problems.  This could simply be another mode to
>     whatever "fix-up" code exists in gettextize, which prints a message
>     instead of trying to actually fix things.

I disagree, If one designs a tool to be automatic, then it must be
reliable and cannot leave around files in a wrong state. Only for an
interactive tool this is an option. gettextize is an interactive tool,
but the one you are asking for is an automatic one.

>   bh> 2) When it comes to making a release, it is more reliable. ...
> 
> In the case above, and I believe on many other projects, testing is done
> is on the released package tarball.  No one ever tests out of the CVS
> tree.

I fear you are mistaken here. In all multi-developer projects I know
of, testing is done directly off the CVS contents. Take for example
the daily GCC tests: http://gcc.gnu.org/benchmarks/

> I hope you will reconsider allowing development teams to make their own
> choices about whether approach (b) is right for them or not.  Some of us
> have been doing this a very long time and are fully capable of
> understanding the issues involved and making our own choices.

As you like. But I will document the dangers of approach b) !

Bruno