Hi Benno,
> > Ah, you were assuming that the POT file is stored in the version control
> > system?
> > This is a practice that produces problems,
>
> What problems does this produce?
<BEGIN NEW DOC>
There are basically three ways to deal with generated files in the context
of a version controlled repository, such as ‘configure’ generated from
‘configure.ac’, parser.c generated from parser.y, or po/Makefile.in.in
autoinstalled by gettextize or autopoint.
“Never”
Generated files are never committed into the repository.
“Occasionally”
All generated files are committed into the repository occasionally, for
example each time a release is made.
“Always”
All generated files are always committed into the repository.
Each of these three approaches has different advantages and drawbacks.
“Never”
The advantage is less work for the maintainers. In particular, the
handling of branches becomes much easier, both for release branches
and “topic branches” as in Git. The drawback is that anyone who checks
out the source not only needs tools like GNU automake, GNU autoconf,
GNU m4 installed in his PATH, but also that he needs to perform a
package specific pre-build step before being able to "./configure; make".
“Occasionally”
The advantage is that anyone can check out the source, and the usual
"./configure; make" will work. The drawbacks are: 1. The one who checks
out the repository needs tools like GNU automake, GNU autoconf, GNU m4
installed in his PATH; sometimes he even needs particular versions of
them. 2. When a release is made and a commit is made on the generated
files, the other developers get conflicts on the generated files when
merging the local work back to the repository. Although these conflicts
are easy to resolve, they are annoying. 3. Copying a change to a branch
is not easy, because it involves separating the patch into a hand-made
part, to be applied literally, and a set of commands or Makefile targets
which will produce the other part. 4. Working with branches is time-
consuming and error-prone.
“Always”
The advantage is that anyone can check out the source at any moment and
gets a working build. The drawbacks are: 1. It requires some frequent
"push" actions by the maintainers. 2. The repository grows in size quite
fast. 3. and 4. as for “Occasionally”.
The “Never” approach is the predominant one nowadays, especially in projects
that use branches like in Git.
<END NEW DOC>
> (Probably this was discussed earlier
> and elsewhere? Maybe have a URL of an archived message?)
It will be documented in the next release of the GNU gettext manual.
Bruno
