(gettext) Distributed CVS

Info Catalog (gettext) CVS Issues (gettext) CVS Issues (gettext) Files under CVS
 13.6.1 Avoiding version mismatch in distributed development
 In a project development with multiple developers, using CVS, there
 should be a single developer who occasionally - when there is desire to
 upgrade to a new `gettext' version - runs `gettextize' and performs the
 changes listed in  Adjusting Files, and then commits his changes
 to the CVS.
    It is highly recommended that all developers on a project use the
 same version of GNU `gettext' in the package.  In other words, if a
 developer runs `gettextize', he should go the whole way, make the
 necessary remaining changes and commit his changes to the CVS.
 Otherwise the following damages will likely occur:
    * Apparent version mismatch between developers.  Since some `gettext'
      specific portions in `', `' and
      `', `' files depend on the `gettext'
      version, the use of infrastructure files belonging to different
      `gettext' versions can easily lead to build errors.
    * Hidden version mismatch.  Such version mismatch can also lead to
      malfunctioning of the package, that may be undiscovered by the
      developers.  The worst case of hidden version mismatch is that
      internationalization of the package doesn't work at all.
    * Release risks.  All developers implicitly perform constant testing
      on a package.  This is important in the days and weeks before a
      release.  If the guy who makes the release tar files uses a
      different version of GNU `gettext' than the other developers, the
      distribution will be less well tested than if all had been using
      the same `gettext' version.  For example, it is possible that a
      platform specific bug goes undiscovered due to this constellation.
Info Catalog (gettext) CVS Issues (gettext) CVS Issues (gettext) Files under CVS
automatically generated byinfo2html