Thanks Joerg. I'll re-sync shortly. Did you happen to test if it had any of
the 0 byte blobs I had before (and the 1 I still have)?
-bch
On Jun 23, 2015 2:43 AM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
On Mon, Jun 22, 2015 at 01:44:12PM -0700, bch wrote:
W/ latest fossil from tip of
On Tue, Jun 23, 2015 at 08:32:13AM -0700, bch wrote:
Thanks Joerg. I'll re-sync shortly. Did you happen to test if it had any of
the 0 byte blobs I had before (and the 1 I still have)?
Likely. As I said, I don't really know why it sometimes creates those :(
Joerg
Still no dice:
kamloops$ fossil pull --verbose
Pull from http://netbsd.sonnenberger.org
Bytes Cards Artifacts Deltas
Sent:9546202 0 0
Received: 78 2 0 0
Pull done, sent: 5082 received: 333 ip:
Good idea (I presume you mean sqltrace):
kamloops$ fossil pull --sqltrace
-- sqlite3_open: [/home/bch/work/netbsd_src/.fslckout]
PRAGMA foreign_keys=OFF;
SELECT sql FROM main.sqlite_master WHERE name=='vfile';
-- sqlite3_open: [/home/bch/.fossil]
PRAGMA foreign_keys=OFF;
SELECT value FROM vvar
On Tue, Jun 23, 2015 at 11:33:31AM -0700, bch wrote:
Still no dice:
kamloops$ fossil pull --verbose
Pull from http://netbsd.sonnenberger.org
Bytes Cards Artifacts Deltas
Sent:9546202 0 0
Received: 78 2
On Tue, Jun 23, 2015 at 01:05:00PM -0600, Andy Bradford wrote:
Thus said bch on Tue, 23 Jun 2015 11:58:35 -0700:
Good idea (I presume you mean sqltrace):
More likely he meant --httptrace which will reveal the HTTP transactions
during the pull operation (e.g. what was sent/received).
I tried that (and sent response that only went to Andy (which I think
is not first time has happened between Andy, fossil-users, and
myself)).
kamloops$ fossil pull --httptrace
Pull from http://netbsd.sonnenberger.org
Round-trips: 1 Artifacts sent: 0 received: 0
Pull done, sent: 9759
Thus said bch on Tue, 23 Jun 2015 11:58:35 -0700:
Good idea (I presume you mean sqltrace):
More likely he meant --httptrace which will reveal the HTTP transactions
during the pull operation (e.g. what was sent/received).
Andy
--
TAI64 timestamp: 40005589adfe
On Tue, Jun 23, 2015 at 12:31:20PM -0700, bch wrote:
I tried that (and sent response that only went to Andy (which I think
is not first time has happened between Andy, fossil-users, and
myself)).
kamloops$ fossil pull --httptrace
Pull from http://netbsd.sonnenberger.org
Round-trips: 1
On Mon, Jun 22, 2015 at 01:44:12PM -0700, bch wrote:
W/ latest fossil from tip of [trunk], a pull now looks roughly like
this (note, no reported errors or warnings, no looping like before,
but still not actually working properly):
Well, I've rebuild the repository, so it should have no
on tech-kern and
tech-net. (user: ozaki-r tags: trunk)
[...]
On 6/19/15, bch brad.har...@gmail.com wrote:
include fossil-users@ ...
-- Forwarded message --
From: bch brad.har...@gmail.com
Date: Fri, 19 Jun 2015 12:05:13 -0700
Subject: Re: [fossil-users] DB corruption
Thus said bch on Mon, 08 Jun 2015 15:31:31 -0700:
rid: size
==
What are some of the SHA1 hashes for these RIDs?
Thanks,
Andy
--
TAI64 timestamp: 40005579f382
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
So... what do these 0-byte blobs _mean_ ?
I just took the time and rebuilt the repo and retried a pull, but same
problem (content does not match sha1 hash). Does anybody know what a
next step ought to be ?
-bch
On 6/8/15, bch brad.har...@gmail.com wrote:
rid: size
==
1355: 0
2090601:
ref: line 196 ./src/xfer.c
...
sha1sum_blob(content, hash);
if( !blob_eq_str(pXfer-aToken[1], blob_str(hash), -1) ){
blob_appendf(pXfer-err, content does not match sha1 hash);
}
...
On 6/8/15, bch brad.har...@gmail.com wrote:
There's either a corrupted database or transport corruption
On Mon, Jun 08, 2015 at 02:07:36PM -0700, bch wrote:
unclear what I should check -- you mean measure blob sizes in the
sqlite db, or tcpdump or some fossil option w/ another pull attempt
Right, the entry in the blob table.
Joerg
___
fossil-users
rid: size
==
1355: 0
2090601: 0
2090613: 0
2090654: 0
2090685: 0
2090719: 0
2090744: 0
2090748: 0
2090762: 0
2090769: 0
2090789: 0
2090811: 0
2090821: 0
2090833: 0
2090840: 0
2090845: 0
2090891: 0
2090903: 0
2090918: 0
2090923: 0
2090948: 0
2090964: 0
2090989: 0
2091012: 0
2091035: 0
2091110:
On Mon, Jun 08, 2015 at 11:52:20AM -0700, bch wrote:
There's either a corrupted database or transport corruption occurring
w/ netbsd-src, but additionally apparent string mis-handling in the
fossil binary:
For unknown reasons, sometimes empty artefacts appear. Can you check
your repo copy?
unclear what I should check -- you mean measure blob sizes in the
sqlite db, or tcpdump or some fossil option w/ another pull attempt
?
-bch
On 6/8/15, Joerg Sonnenberger jo...@britannica.bec.de wrote:
On Mon, Jun 08, 2015 at 11:52:20AM -0700, bch wrote:
There's either a corrupted database or
18 matches
Mail list logo
