Re: xsltwin32config.h and jhbuild

[James Henstridge <james jamesh id au>]

Daniel Veillard wrote:

>  libxml2/include/libxml/xmlwin32version.h[.in] contains the same
>kind of set of informations as the one on the libxslt side, is generated
>in the same way, and doesn't seems to break jhbuild.
>  Is there any special rule applied within jhbuild on one side and not
>another ? Couldn't that file be removed or ignored in case of CVS checkout
>conflicts ?
>  
>
jhbuild does not automatically delete conflicts, because they could be a
user's local modifications.  It doesn't have any way to differentiate
between conflicts caused by generated files in CVS changing and local
changes that the user would want to keep.

>From what I can tell, this particular problem occurs through the
following set of steps:

   1. Daniel commits some changes to libxslt in CVS, including an update
      to the ChangeLog.  He reran configure before the commit, which
      embedded the revision number of the last revision of ChangeLog
      into libxslt/xsltwin32config.h.
   2. Federico checks out libxslt and runs configure.  Since ChangeLog
      was updated by Daniel's commit, a different revision number gets
      written to libxslt/xsltwin32config.h.  The file now differs from CVS.
   3. Daniel makes a number of checkins to CVS, which results in
      libxslt/xsltwin32config.h containing a third revision number
   4. Federico updates his checkout.  A conflict occurs when performing
      the 3-way merge, since the same line of libxslt/xsltwin32config.h
      has been changed in different ways on the mainline and in
      Federico's local changes.

Storing this sort of file in CVS is going to cause very frequent
conflicts.  The only way to really fix this problem is one of:

    * remove the file from CVS, and only include it in the tarballs
    * don't store the ChangeLog revision number inside the file.


James.