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/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list