Discussion:
tree checksum does not match
(too old to reply)
Michael
2009-12-15 22:19:34 UTC
Permalink
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
$

and the commit fails. The upside is, I did not have to type
in my commit message when I tried again :).

Suggestions, please.

~Michael
D. Richard Hipp
2009-12-15 23:25:29 UTC
Permalink
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
> $

Do you happen to have files named "manifest" or "manifest.uuid" as
part of your check-in?

After the commit occurs, but before the checksum verification, fossil
overwrites those files with the versions that it generates itself.
This can cause the checksum to be off. I should probably fix this so
that if "manifest" or "manifest.uuid" are files that you have "add"-ed
to the repository, those files are not automatically generated.


>
> and the commit fails. The upside is, I did not have to type
> in my commit message when I tried again :).
>
> Suggestions, please.
>
> ~Michael
>
> _______________________________________________
> fossil-users mailing list
> fossil-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

D. Richard Hipp
***@hwaci.com
Michael
2009-12-15 23:29:04 UTC
Permalink
On Tue, Dec 15, 2009 at 06:25:29PM -0500, 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
> > $
>
> Do you happen to have files named "manifest" or "manifest.uuid" as
> part of your check-in?
>
> After the commit occurs, but before the checksum verification, fossil
> overwrites those files with the versions that it generates itself.
> This can cause the checksum to be off. I should probably fix this so
> that if "manifest" or "manifest.uuid" are files that you have "add"-ed
> to the repository, those files are not automatically generated.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

no manifest files added to repository,
the following returns nothing ..

$ fossil ls | egrep -i mani
$
$ fossil changes | egrep -i mani
$

~Michael

>
>
> >
> > and the commit fails. The upside is, I did not have to type
> > in my commit message when I tried again :).
> >
> > Suggestions, please.
> >
> > ~Michael
> >
> > _______________________________________________
>
> D. Richard Hipp
> ***@hwaci.com
>
>
>
a***@mail.com
2009-12-17 04:43:57 UTC
Permalink
Hi DRH, is there any reason content of these files can't be stored in _FOSSIL_ database itself?



-----Original Message-----
From: D. Richard Hipp <***@hwaci.com>
To: fossil-***@lists.fossil-scm.org
Sent: Wed, Dec 16, 2009 4:55 am
Subject: 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> $Do you happen to have files named "manifest" or "manifest.uuid" as part of your check-in?After the commit occurs, but before the checksum verification, fossil overwrites those files with the versions that it generates itself. This can cause the checksum to be off. I should probably fix this so that if "manifest" or "manifest.uuid" are files that you have "add"-ed to the repository, those files are not automatically generated.>> and the commit fails. The upside is, I did not have to type> in my commit message when I tried again :).>> Suggestions, please.>> ~Michael>> _______________________________________________> fossil-users mailing list> fossil-***@lists.fossil-scm.org> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-usersD. Richard ***@hwaci.com_______________________________________________fossil-users mailing listfossil-***@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
D. Richard Hipp
2009-12-17 13:25:04 UTC
Permalink
On Dec 16, 2009, at 11:43 PM, ***@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.html

The 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
a***@mail.com
2009-12-18 03:38:04 UTC
Permalink
Thanks.


BTW, I saw many good changes in fossil last night. I'm pleased :)



-----Original Message-----
From: D. Richard Hipp <***@hwaci.com>
To: fossil-***@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, ***@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 ***@hwaci.com_______________________________________________fossil-users mailing listfossil-***@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
D. Richard Hipp
2009-12-15 23:42:21 UTC
Permalink
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
***@hwaci.com
D. Richard Hipp
2009-12-15 23:48:37 UTC
Permalink
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
***@hwaci.com
Michael McDaniel
2009-12-15 23:54:29 UTC
Permalink
On Tue, Dec 15, 2009 at 06:48:37PM -0500, D. Richard Hipp wrote:
>
> 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
> ***@hwaci.com
>
_____________________________________________________________

I had clicked send before I saw this message. A 1.3MB
typescript file (output of strace fossil commit) is attached
and message is being held, not posted to list, "until moderator
can review it".

~Michael
D. Richard Hipp
2009-12-15 23:58:02 UTC
Permalink
What does "fossil status" show you?

D. Richard Hipp
***@hwaci.com
Michael McDaniel
2009-12-16 00:02:57 UTC
Permalink
On Tue, Dec 15, 2009 at 06:58:02PM -0500, D. Richard Hipp wrote:
> What does "fossil status" show you?
>
> D. Richard Hipp
> ***@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
Michael McDaniel
2009-12-16 00:05:56 UTC
Permalink
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
> > ***@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
D. Richard Hipp
2009-12-16 01:58:02 UTC
Permalink
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
Michael McDaniel
2009-12-16 02:24:02 UTC
Permalink
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
Michael McDaniel
2009-12-16 04:11:00 UTC
Permalink
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
Michael
2009-12-17 16:15:23 UTC
Permalink
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
D. Richard Hipp
2009-12-17 16:19:26 UTC
Permalink
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-***@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

D. Richard Hipp
***@hwaci.com
Michael
2009-12-17 16:26:06 UTC
Permalink
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 > >
Michael
2009-12-18 00:01:52 UTC
Permalink
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
Will Duquette
2009-12-16 03:15:49 UTC
Permalink
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
Jeremy Cowgar
2009-12-16 03:37:37 UTC
Permalink
Will Duquette <***@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
Eric
2009-12-16 07:55:43 UTC
Permalink
From: "Will Duquette" <***@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
Jeremy Cowgar
2009-12-16 13:56:00 UTC
Permalink
"Eric" <***@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
a***@mail.com
2009-12-17 04:52:19 UTC
Permalink
Very much agree.



-----Original Message-----
From: Jeremy Cowgar <***@cowgar.com>
To: ***@deptj.eu; fossil-***@lists.fossil-scm.org
Sent: Wed, Dec 16, 2009 7:26 pm
Subject: Re: [fossil-users] tree checksum does not match


"Eric" <***@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.defJeremy_______________________________________________fossil-users mailing listfossil-***@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
a***@mail.com
2009-12-17 04:51:14 UTC
Permalink
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 <***@cowgar.com>
To: fossil-***@lists.fossil-scm.org
Sent: Wed, Dec 16, 2009 9:07 am
Subject: Re: [fossil-users] tree checksum does not match


Will Duquette <***@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 listfossil-***@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Jeremy Cowgar
2009-12-17 12:09:21 UTC
Permalink
***@mail.com wrote:
> Well, revert could still be used for reverting selected files but update should also revert any missing files - that's how SCMs have worked.
>
>

Yes, that makes sense, but we should have a way of getting the file back w/o updating, thus I think revert is a good option, but yes, update should add any files that should but doesn't exist.

Jeremy
D. Richard Hipp
2009-12-16 00:06:38 UTC
Permalink
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
>> ***@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
***@hwaci.com
chi
2009-12-16 01:08:13 UTC
Permalink
D. Richard Hipp wrote:

(...)

> 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?
>

By looking at the typescript, I would guess, that the file

"/home/erl/putitgetit/manifest" could be the culprit. If his directory contains an own file "manifest" this will conflict with the one by Fossil!

In the past I had the same error, that if I have a file "manifest" (or "Manifest" on e.g. MacOS/X) Fossil will recognize and remember my file, overwrite it with its own "manifest" and then complain about checksum mismatch ...


Ciao,
chi.
Michael
2009-12-15 23:51:03 UTC
Permalink
On Tue, Dec 15, 2009 at 06:42:21PM -0500, 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?
>
>
> D. Richard Hipp
> ***@hwaci.com
>
>
>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

$ fossil commit -m "checkin comment"
Autosync: http://localhost:3150/cgi/putitgetit.cgi
Bytes Cards Artifacts Deltas
Send: 130 1 0 0
Received: 4002 87 0 0
Total network traffic: 330 bytes sent, 2380 bytes received

You need a passphrase to unlock the secret key for
user: "Michael McDaniel <***@autosys.us>"
1024-bit DSA key, ID ********, created ****-12-18

New_Version: 7fd97c5cbd5489239980a864d35f78173f378488
fossil: tree checksum does not match repository after commit
$


That's it - I enter my passphrase, it churns, clears the
passphrase line, and returns the New_Version and fossil: lines
only, then back to the prompt.

I have attached the results of strace on the command, captured
via 'script'

~M
Continue reading on narkive:
Loading...