(gettext.info)Files under Version Control

---

Next: Translations under Version Control Prev: Distributed Development Up: Version Control Issues

---

Enter node , (file) or (file)node

13.6.2 Files to put under version control
-----------------------------------------

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

  1. All generated files are always committed into the repository.

  2. All generated files are committed into the repository occasionally,
     for example each time a release is made.

  3. Generated files are never committed into the repository.

   Each of these three approaches has different advantages and
drawbacks.

  1. The advantage is that anyone can check out the source at any moment
     and gets a working build.  The drawbacks are: 1a.  It requires some
     frequent "push" actions by the maintainers.  1b.  The repository
     grows in size quite fast.

  2. The advantage is that anyone can check out the source, and the
     usual "./configure; make" will work.  The drawbacks are: 2a.  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.  2b.  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. The advantage is less work for the maintainers.  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".

   For the first and second approach, all files modified or brought in
by the occasional ‘gettextize’ invocation and update should be committed
into the repository.

   For the third approach, the maintainer can omit from the repository
all the files that ‘gettextize’ mentions as "copy".  Instead, he adds to
the ‘configure.ac’ or ‘configure.in’ a line of the form

     AM_GNU_GETTEXT_VERSION(0.19.8)

and adds to the package’s pre-build script an invocation of ‘autopoint’.
For everyone who checks out the source, this ‘autopoint’ invocation will
copy into the right place the ‘gettext’ infrastructure files that have
been omitted from the repository.

   The version number used as argument to ‘AM_GNU_GETTEXT_VERSION’ is
the version of the ‘gettext’ infrastructure that the package wants to
use.  It is also the minimum version number of the ‘autopoint’ program.
So, if you write ‘AM_GNU_GETTEXT_VERSION(0.11.5)’ then the developers
can have any version >= 0.11.5 installed; the package will work with the
0.11.5 infrastructure in all developers’ builds.  When the maintainer
then runs gettextize from, say, version 0.12.1 on the package, the
occurrence of ‘AM_GNU_GETTEXT_VERSION(0.11.5)’ will be changed into
‘AM_GNU_GETTEXT_VERSION(0.12.1)’, and all other developers that use the
CVS will henceforth need to have GNU ‘gettext’ 0.12.1 or newer
installed.