Re: [fossil-users] How to merge a fork with binary files?
Hi, It seems there is something broken in fossil. I'm always getting this error when I try to make a 'fossil update': $ fossil update Assertion failed: (pBlob)-xRealloc==blobReallocMalloc || (pBlob)-xRealloc==blobReallocStatic, file blob_.c, line 170 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information $ fossil version This is fossil version [2bb1d6469f] 2009-12-09 14:39:20 UTC I do have binary files (icons, gifs, jpg) in my project. I think some of these binary files were changed by me and somebody else. Now I cannot make an update to get the latest changes from the repository. Any hint's how I can handle this Many Thanks Hein Wilson, Ronald schrieb: If we consider the nature of binary files for a moment we will see that it is not possible, in the generic case, to _merge_ binary files. Yes, diffs can be created and applied, but two versions cannot be merged. Consider two ZIP files (or .jar files - the same thing). If you merge any given bytes, you invalidate some data which a ZIP tool is going to rely on. You will either corrupt a header or the content of a zipped file or something simlar. You have to either take ONE version OR the other, but they cannot, in the generic case, be merged. Features do exists which merge specific types of binary files (e.g. ODF, which are basically XML wrapped in a ZIP file), but no tools exist for generically merging binaries. i would assert that it _cannot_ be done generically because a merge requires some information about what is in the binary. -- - stephan beal http://wanderinghorse.net/home/stephan/ True. For example, I use Rational ClearCase at work and it generally just takes one over the other. Is it reasonable to have fossil do similar? RW Ron Wilson, Engineering Project Lead (o) 434.455.6453, (m) 434.851.1612, www.harris.com HARRIS CORPORATION | RF Communications Division assuredcommunications(tm) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Heinrich Huss PSH Consulting GmbH Am Gewerbepark 10 64823 Groß-Umstadt Phone+49 6078 931 6455 Fax +49 6078 96 9536 Mobile +49 171 43 46 773 e-mailheinrich.h...@psh-consulting.de *** PSH Consulting GmbH Legal Disclaimer *** Diese E-Mail einschließlich ihrer Anhänge ist vertraulich und ist allein für den Gebrauch durch den vorgesehenen Empfänger bestimmt. Dritten ist das Lesen, Verteilen oder Weiterleiten dieser E-Mail untersagt. Wir bitten, eine fehlgeleitete E-Mail unverzüglich vollständig zu löschen und uns eine Nachricht zukommen zu lassen. This email may contain material that is confidential and for the sole use of the intended recipient. Any review, distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. Hauptsitz: Magdeburger Strasse 1, D-64720 Michelstadt, USt-IdNr.: DE 21 117 1171 Kommunikation: Telefon +49 6078 931 6455, Telefax +49 6078 96 95 36, www.psh-consulting.de Handelsregister: Amtsgericht Darmstadt, HRB 71404 Geschäftsführer: Heinrich Huss, Thomas Riedl ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to merge a fork with binary files?
On Dec 15, 2009, at 3:30 PM, Heinrich Huss wrote: Hi, It seems there is something broken in fossil. I'm always getting this error when I try to make a 'fossil update': $ fossil update Assertion failed: (pBlob)-xRealloc==blobReallocMalloc || (pBlob)-xRealloc==blobReallocStatic, file blob_.c, line 170 Bummer. What does fossil status tell you? If you don't have any changes that you need to check-in, you can probably work around this problem by running fossil checkout instead of fossil update. But I'd still like to get to the bottom of the problem. Do you have a C- compiler and a debugger? Can you run fossil in the debugger and give me additional information about where it is failing, so that I can find and fix the problem? D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to merge a fork with binary files?
On Dec 15, 2009, at 3:53 PM, Stephan Beal wrote: On Tue, Dec 15, 2009 at 9:50 PM, Heinrich Huss heinrich.h...@psh-consulting.de wrote: I will try running this with an debugger later but I have to shift this to tomorrow. I will than give you an update. Have you tried doing a clean checkout to a different directory? You could then copy over your changes and continue work from there. That will probably fix Heinrich's problem, but it doesn't help me to fix the original problem in Fossil... D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to merge a fork with binary files?
On Tue, Dec 15, 2009 at 9:37 PM, D. Richard Hipp d...@hwaci.com wrote: On Dec 15, 2009, at 3:30 PM, Heinrich Huss wrote: Hi, It seems there is something broken in fossil. I'm always getting this error when I try to make a 'fossil update': $ fossil update Assertion failed: (pBlob)-xRealloc==blobReallocMalloc || (pBlob)-xRealloc==blobReallocStatic, file blob_.c, line 170 Bummer. What does fossil status tell you? If you don't have any changes that you need to check-in, you can probably work around this problem by running fossil checkout instead of fossil update. But I'd still like to get to the bottom of the problem. Do you have a C- compiler and a debugger? Can you run fossil in the debugger and give me additional information about where it is failing, so that I can find and fix the problem? D. Richard Hipp d...@hwaci.com I think that this problem is easy to reproduce. First check in a png image. Open second workspace and replace local copy of this image in this second workspace. In first workspace check in another png file as a new version. And in the second workspace update will trigger the assertion - as there is no way to merge binary files. For such a situation with failing update there is described workarounds. But when you acreate a fork with binary files I think it may be impossible to merge this fork. If my description is not precise enough I will create testcase script within a few days to show exactly my problem. Of cource if you don't put binary files in your repo probably you are not affected (thanks for advise on Visual Studio projects). But maybe I am missing something and if this is obvious for you please advice me how to proceed with merging forks with binary files. Tomasz Kosiak ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
On Dec 15, 2009, at 5:19 PM, Michael wrote: I did 'fossil rebuild --repository X' after I upgraded to $ fossil version This is fossil version [5bccc5a526] 2009-12-10 02:25:45 UTC $ fossil commit ... New_Version: 20e486405a4e5cbd5d1a65360b0a562e27e3ea1b fossil: tree checksum does not match repository after commit $ I'm looking at the code and it should have printed the two non- matching checksums after the word commit above. Did it not? Did it segfault? Are you able to run in a debugger to see what is going on? D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
On Dec 15, 2009, at 6:42 PM, D. Richard Hipp wrote: On Dec 15, 2009, at 5:19 PM, Michael wrote: I did 'fossil rebuild --repository X' after I upgraded to $ fossil version This is fossil version [5bccc5a526] 2009-12-10 02:25:45 UTC $ fossil commit ... New_Version: 20e486405a4e5cbd5d1a65360b0a562e27e3ea1b fossil: tree checksum does not match repository after commit $ I'm looking at the code and it should have printed the two non- matching checksums after the word commit above. Did it not? Did it segfault? Are you able to run in a debugger to see what is going on? I was looking at the wrong section of code. Sorry. I withdraw the question. D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
On Tue, Dec 15, 2009 at 04:02:57PM -0800, Michael McDaniel wrote: On Tue, Dec 15, 2009 at 06:58:02PM -0500, D. Richard Hipp wrote: What does fossil status show you? D. Richard Hipp d...@hwaci.com _ repository: /home/fossil/repositories/putitgetit.fossil.private local-root: /home/erl/putitgetit/ server-code: 0e50280d536c31b94362470841e606e9658d8797 checkout: e9aff5b32f740a0ee838a589803fa565fe164013 2009-12-15 02:19:03 UTC parent: da646056826e22ccab9a020ee5576f76267b4bc6 2009-12-14 00:41:04 UTC tags: trunk ... The ... is a list of 249 items, 236 DELETED, 14 EDITED. ~Michael _ I have some errands and plan to be back within 60 to 90 minutes. ~Michael ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
On Dec 15, 2009, at 7:02 PM, Michael McDaniel wrote: On Tue, Dec 15, 2009 at 06:58:02PM -0500, D. Richard Hipp wrote: What does fossil status show you? D. Richard Hipp d...@hwaci.com _ repository: /home/fossil/repositories/putitgetit.fossil.private local-root: /home/erl/putitgetit/ server-code: 0e50280d536c31b94362470841e606e9658d8797 checkout: e9aff5b32f740a0ee838a589803fa565fe164013 2009-12-15 02:19:03 UTC parent: da646056826e22ccab9a020ee5576f76267b4bc6 2009-12-14 00:41:04 UTC tags: trunk ... The ... is a list of 249 items, 236 DELETED, 14 EDITED. Can you send me your repository and a tarball of your checkout via private email so that I can try to reproduce the problem here? D. Richard Hipp d...@hwaci.com ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
On Tue, Dec 15, 2009 at 08:58:02PM -0500, D. Richard Hipp wrote: Tnx for sending your repository and check-out. There are a couple of problems. Both are things Fossil ought to be able to deal with - things I will fix presently. Both are easy to work around. First, when I run: fossil status | grep MISSING I see that there are a bunch of files that are missing from the repository. These files need to be either reverted or fossil rm- ed. I used this command: fossil status | grep MISSING | while read m name; do fossil revert $name; done (Third thing that needs to be fixed - there ought to be an easier way to revert many files. Or, maybe if files are missing they out to be automatically rm-ed. Or maybe that there is an option to automatically rm missing files. Thoughts? What do other DVCSes do?) The other problem is that you changes what used to be a file, webmachine/demo/webmachine, into a directory. Fossil was still trying to read it as a file, which was causing problem. I fixed this by running: fossil rm webmachine/demo/webmachine After making those two changes, the commit completed normally. Let me just take a moment here to point out that the error message that Michael has been getting is a result of one of the many self- checks that Fossil runs on every check-in and check-out. In a less careful implementation of a DVCS (one in which these massive MD5 checksum comparisons did not occur) these bugs would have been missed and the commit would have proceeded without error. That might have worked. Or it might have resulted in a corrupt repository. I'm not sure which. But in this case, the extra checking found the error and the repository database was rolled back before any harm could be done. And so we can continue to make the bold claim that nobody has ever lost work that was successfully checked into a Fossil repository due to a Fossil bug. The self-checks in Fossil continue to serve us well. More information at: http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki D. Richard Hipp d...@hwaci.com ^ Thank you for your prompt turnaround. Regarding the MISSING, I am mystified why you see that. When I do $ fossil status there are no MISSING files $ fossil status | egrep MISSING shows nothing. But there are the 236 DELETED files which I had already 'fossil rm'd via a similar command to your revert command above. Because I had rm'd them from the directories first, then from fossil. Should I go ahead and revert the DELETED files and try again ? Could autosync have anything to do with this inconsistency ? I have it turned on to a remote machine which I ssh port forward to 3150. That is why the remote-url looks 'funny'. ~Michael ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
On Dec 15, 2009, at 5:58 PM, D. Richard Hipp wrote: (Third thing that needs to be fixed - there ought to be an easier way to revert many files. Or, maybe if files are missing they out to be automatically rm-ed. Or maybe that there is an option to automatically rm missing files. Thoughts? What do other DVCSes do?) Richard, What I'd expect if I had deleted a file from the file system without doing a fossil rm is that a fossil update would simply assuming that it was missing and restore it. This is what CVS and SVN do, and I can't see any reason why a DVCS should be different in this regard. (I'm quite willing to be enlightened if anyone can provide with one. :-) Will -- will -at- wjduquette.com | Catch our weblog, http://foothills.wjduquette.com/blog | The View from the Foothills ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
Will Duquette w...@wjduquette.com wrote: On Dec 15, 2009, at 5:58 PM, D. Richard Hipp wrote: (Third thing that needs to be fixed - there ought to be an easier way to revert many files. Or, maybe if files are missing they out to be automatically rm-ed. Or maybe that there is an option to automatically rm missing files. Thoughts? What do other DVCSes do?) Richard, What I'd expect if I had deleted a file from the file system without doing a fossil rm is that a fossil update would simply assuming that it was missing and restore it. This is what CVS and SVN do, and I can't see any reason why a DVCS should be different in this regard. (I'm quite willing to be enlightened if anyone can provide with one. :-) I wonder if revert wouldn't be better. What I am thinking is that I may not want to update my source tree right now. Maybe I am in the middle of some big changes, autosync is on, etc... Just as if I were to edit abc.txt and blank the content, I could do a fossil revert to get the content back. If I accidentally removed a file, revert it. That will allow me to get it back without fancy trickery (autosync off, or update to my given version). Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
On Tue, Dec 15, 2009 at 06:24:02PM -0800, Michael McDaniel wrote: On Tue, Dec 15, 2009 at 08:58:02PM -0500, D. Richard Hipp wrote: Tnx for sending your repository and check-out. There are a couple of problems. Both are things Fossil ought to be able to deal with - things I will fix presently. Both are easy to work around. First, when I run: fossil status | grep MISSING I see that there are a bunch of files that are missing from the repository. These files need to be either reverted or fossil rm- ed. I used this command: fossil status | grep MISSING | while read m name; do fossil revert $name; done (Third thing that needs to be fixed - there ought to be an easier way to revert many files. Or, maybe if files are missing they out to be automatically rm-ed. Or maybe that there is an option to automatically rm missing files. Thoughts? What do other DVCSes do?) The other problem is that you changes what used to be a file, webmachine/demo/webmachine, into a directory. Fossil was still trying to read it as a file, which was causing problem. I fixed this by running: fossil rm webmachine/demo/webmachine After making those two changes, the commit completed normally. Let me just take a moment here to point out that the error message that Michael has been getting is a result of one of the many self- checks that Fossil runs on every check-in and check-out. In a less careful implementation of a DVCS (one in which these massive MD5 checksum comparisons did not occur) these bugs would have been missed and the commit would have proceeded without error. That might have worked. Or it might have resulted in a corrupt repository. I'm not sure which. But in this case, the extra checking found the error and the repository database was rolled back before any harm could be done. And so we can continue to make the bold claim that nobody has ever lost work that was successfully checked into a Fossil repository due to a Fossil bug. The self-checks in Fossil continue to serve us well. More information at: http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki D. Richard Hipp d...@hwaci.com ^ Thank you for your prompt turnaround. Regarding the MISSING, I am mystified why you see that. When I do $ fossil status there are no MISSING files $ fossil status | egrep MISSING shows nothing. But there are the 236 DELETED files which I had already 'fossil rm'd via a similar command to your revert command above. Because I had rm'd them from the directories first, then from fossil. Should I go ahead and revert the DELETED files and try again ? Could autosync have anything to do with this inconsistency ? I have it turned on to a remote machine which I ssh port forward to 3150. That is why the remote-url looks 'funny'. ~Michael _ I turned autosync off and same behaviour. $ fossil settings autosync 0 $ fossil commit -m checkin comment ... New_Version: 193b3b45d0878d336e30cf8e18c7fb474b0a1e02 fossil: tree checksum does not match repository after commit ~Michael ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] tree checksum does not match
From: Will Duquette w...@wjduquette.com Date: Wed, December 16, 2009 3:15 am On Dec 15, 2009, at 5:58 PM, D. Richard Hipp wrote: (Third thing that needs to be fixed - there ought to be an easier way to revert many files. Or, maybe if files are missing they out to be automatically rm-ed. Or maybe that there is an option to automatically rm missing files. Thoughts? What do other DVCSes do?) Richard, What I'd expect if I had deleted a file from the file system without doing a fossil rm is that a fossil update would simply assuming that it was missing and restore it. This is what CVS and SVN do, and I can't see any reason why a DVCS should be different in this regard. (I'm quite willing to be enlightened if anyone can provide with one. :-) Will What should happen if you had removed the file on purpose? In any case, it is a merge of the file from the repository with the no-file in the checkout, so if it is restored fossil should report it as it does for a conventional merge. Eric ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
