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
> > > ***@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