Re: xsltwin32config.h and jhbuild

[Daniel Veillard <veillard redhat com>]

On Sun, Jul 03, 2005 at 09:55:56AM +0800, James Henstridge wrote:
> 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.

  now s/xslt/xml/g there is the exact same mechanism for libxml2, and 
it never breaks, though libxml2 module ChangeLog is updated way more frequently
than libxslt one, why ? I undestand your analysis, but I don't understand
why libxml2 doesn't break too.

> The only way to really fix this problem is one of:
> 
>     * remove the file from CVS, and only include it in the tarballs
 
    which mean I can't get Windows testers using CVS

>     * don't store the ChangeLog revision number inside the file.

    annoying but I could do that to the windows specific version, not a big deal

also 

      * modify jhbuild to have a specific rule about that file.

Daniel

-- 
Daniel Veillard      | Red Hat Desktop team http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/