Re: [fossil-users] tree checksum does not match
On Tue, Dec 15, 2009 at 08:11:00PM -0800, Michael McDaniel wrote: 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 ___ Richard, were you able to reproduce the problem I described ? Do you have any idea(s) why you saw 'MISSING' and I saw 'DELETED' using the same packages ? (sha1sum (GNU coreutils) 6.10) sha1sum p*.fossil.private == d715284f35c6186827b8a5562acd3fe84d3c1d08 sha1sum tarball == 26078d9d35687f1635ee58da81481b70cb43d01f ~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 17, 2009, at 11:15 AM, Michael wrote: Richard, were you able to reproduce the problem I described ? Do you have any idea(s) why you saw 'MISSING' and I saw 'DELETED' using the same packages ? I have not tried to reproduce it. I think other issue are more pressing - such as dealing with files that have changed into directories and handling MISSING files on update. If this really is an issue, we'll get to it. But I'm willing to believe this was operator error on my part or something. (sha1sum (GNU coreutils) 6.10) sha1sum p*.fossil.private == d715284f35c6186827b8a5562acd3fe84d3c1d08 sha1sum tarball == 26078d9d35687f1635ee58da81481b70cb43d01f ~Michael ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 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 Thu, Dec 17, 2009 at 11:19:26AM -0500, D. Richard Hipp wrote: On Dec 17, 2009, at 11:15 AM, Michael wrote: Richard, were you able to reproduce the problem I described ? Do you have any idea(s) why you saw 'MISSING' and I saw 'DELETED' using the same packages ? I have not tried to reproduce it. I think other issue are more pressing - such as dealing with files that have changed into directories and handling MISSING files on update. If this really is an issue, we'll get to it. But I'm willing to believe this was operator error on my part or something. ^ Acknowledged - thanks - will wait for new fossil to test in my current environment. ~Michael znip ___ 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 Thu, Dec 17, 2009 at 08:26:06AM -0800, Michael wrote: On Thu, Dec 17, 2009 at 11:19:26AM -0500, D. Richard Hipp wrote: On Dec 17, 2009, at 11:15 AM, Michael wrote: Richard, were you able to reproduce the problem I described ? Do you have any idea(s) why you saw 'MISSING' and I saw 'DELETED' using the same packages ? I have not tried to reproduce it. I think other issue are more pressing - such as dealing with files that have changed into directories and handling MISSING files on update. If this really is an issue, we'll get to it. But I'm willing to believe this was operator error on my part or something. ^ Acknowledged - thanks - will wait for new fossil to test in my current environment. ~Michael znip ___ $ fossil version This is fossil version [2d996b080e] 2009-12-17 22:55:26 UTC This version worked for original problem [details in earlier mails]. With this version, 'fossil commit' complained about fossil: not a ordinary file: path/to/a/symlink I 'rm path/to/a/symlink' and then the commit occcured as expected. Note that path/to/a/symlink was not in the repository hence I did not do a 'fossil rm'. Thank you. ~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
Thanks. BTW, I saw many good changes in fossil last night. I'm pleased :) -Original Message- From: D. Richard Hipp d...@hwaci.com To: fossil-users@lists.fossil-scm.org Sent: Thu, Dec 17, 2009 6:55 pm Subject: Re: [fossil-users] tree checksum does not match On Dec 16, 2009, at 11:43 PM, altufa...@mail.com wrote: Hi DRH, is there any reason content of these files can't be stored in _FOSSIL_ database itself?The manifest and manifest.uuid files are not used by Fossil. Fossil makes those files available for the convenience of the application and the application's makefile. For example, the makefile for SQLite extracts information from its manifest and manifest.uuid in order to generate the sqlite3_sourceid() interface.http://www.sqlite.org/c3ref/libversion.htmlThe makefile for fossil itself also uses these files to construct the version information that is displayed when you type fossil version.If this information were in the _FOSSIL_ file or was only available using the fossil command, then you would not be able to build either SQLite or Fossil from the raw ZIP Archive download or without having a fossil executable on hand. Hence, it is important that the manifest and manifest.uuid files exist.D. Richard hipp...@hwaci.com___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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
Eric e...@deptj.eu wrote: 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. Then you should see that fossil thinks it's missing and do a fossil rm file.txt, to let fossil know you meant for it to be removed. Idealy, fossil rm file.txt should remove it from the repo and disk as discussed in another thread. Same for fossil mv file.abc file.def 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
Well, revert could still be used for reverting selected files but update should also revert any missing files - that's how SCMs have worked. -Original Message- From: Jeremy Cowgar jer...@cowgar.com To: fossil-users@lists.fossil-scm.org Sent: Wed, Dec 16, 2009 9:07 am Subject: 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 DVCSesdo?) 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 listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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
