On Mon, Jul 21, 2014 at 7:53 AM, Gour g...@atmarama.net wrote:
Stephan Beal sgb...@googlemail.com writes:
i don't have any more ideas off-hand, but i've never worked with repos
having anywhere near that many files.
After seeing that Eric's advice to turn checksumming off helps, I wonder
Stephan Beal sgb...@googlemail.com writes:
Checksumming, in this sense, is the generation of the so-called R-card. The
R-card is the 3rd or 4th line of defense against corruption, is _very_
costly to calculate, and is very possibly overkill.
Considering that I already modified
On 7/20/2014 23:39, Gour wrote:
but I wonder how safe is to operate Fossil repo with checksum checking
off?
It's as safe as inserting *anything* into a SQLite DB without
checksumming all contents of the DB first.
Could this catch problems, in theory? Sure.
If it does, though, all it can
On 7/21/2014 08:53, Warren Young wrote:
If it does, though, all it can tell you is that your local filesystem or
OS or storage subsystem is untrustworthy.
Relevant reads:
http://queue.acm.org/detail.cfm?id=2367378
https://www.sqlite.org/howtocorrupt.html
On Mon, Jul 21, 2014 at 10:53 AM, Warren Young war...@etr-usa.com wrote:
On 7/20/2014 23:39, Gour wrote:
but I wonder how safe is to operate Fossil repo with checksum checking
off?
If you're running Fossil on a system that already does data checksumming
(not just *metadata*
Richard Hipp d...@sqlite.org writes:
I would say that as long as you are running a version of Fossil that is
well-tested, it is safe to leave repo checksumming turned off.
Great!
I suppose the repo checksum might also find the problem of trying to do a
check-in while the files in the
On Mon, Jul 21, 2014 at 4:53 PM, Warren Young war...@etr-usa.com wrote:
I also don't see that this feature buys you anything if you're on a system
with reliable fsync(). Say, a Linux box running XFS with write barriers
enabled, with the filesystem stored on a storage subsystem that doesn't
Hello,
I've Fossil repo mostly containing uncompressed Gnucash XML files and
commits even for trivial changes are quite slow:
$ time fossil ci -m update logs
You need a passphrase to unlock the secret key for
user: Gour-Gadadhara Dasa g...@atmarama.net
4096-bit RSA key, ID 52B5C810, created
On Sun, Jul 20, 2014 at 1:52 PM, Gour g...@atmarama.net wrote:
New_Version: 6d606bba0322d91e38a5e36541264ff3e9f0036b
24.30user 0.55system 0:27.02elapsed 91%CPU (0avgtext+0avgdata
40804maxresident)k
0inputs+7304outputs (0major+39916minor)pagefaults 0swaps
...
checkins: 973
files:
Thus said Stephan Beal on Sun, 20 Jul 2014 14:03:12 +0200:
fossil commit -m ... --delta
Excellent! I always wondered how to turn on delta manifests. Does this
turn it on for the entire repo, or just the files in the commit?
Thanks,
Andy
--
TAI64 timestamp: 400053cbde68
On Sun, Jul 20, 2014 at 5:20 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
Thus said Stephan Beal on Sun, 20 Jul 2014 14:03:12 +0200:
fossil commit -m ... --delta
Excellent! I always wondered how to turn on delta manifests. Does this
turn it on for the entire repo, or just the files
Stephan Beal sgb...@googlemail.com writes:
fossil set mtime-changes 1
Strange that it was 'off', although default should be 'on'. If not set,
Fossil checks hashes, right?
then, on the next commit:
fossil commit -m ... --delta
Did that, but not much improvement so far.
Can you try that
On Sun, Jul 20, 2014 at 5:58 PM, Gour g...@atmarama.net wrote:
Stephan Beal sgb...@googlemail.com writes:
fossil set mtime-changes 1
Strange that it was 'off', although default should be 'on'. If not set,
Fossil checks hashes, right?
Correct about the hashing, but i don't recall what
Stephan Beal sgb...@googlemail.com writes:
i don't have any more ideas off-hand, but i've never worked with repos
having anywhere near that many files. Maybe a list-member who has can
suggest something. Maybe it's something as simple as changing the sqlite3
write mode (and maybe it's not).
Gour wrote:
Stephan Beal sgb...@googlemail.com writes:
i don't have any more ideas off-hand, but i've never worked with repos
having anywhere near that many files. Maybe a list-member who has can
suggest something. Maybe it's something as simple as changing the sqlite3
write mode (and
Eric Rubin-Smith eas@gmail.com
writes:
Maybe try this?
fossil setting repo-cksum off
Then re-test.
That had drastic effect:
$ time fossil ci -m update logs
You need a passphrase to unlock the secret key for
user: Gour-Gadadhara Dasa g...@atmarama.net
4096-bit RSA key, ID 52B5C810,
Stephan Beal sgb...@googlemail.com writes:
i don't have any more ideas off-hand, but i've never worked with repos
having anywhere near that many files.
After seeing that Eric's advice to turn checksumming off helps, I wonder
if there is something which can be done to make Fossil operate
Hello,
with one of the repos I experience slow commits:
7.54user 0.51system 0:17.16elapsed 46%CPU (0avgtext+0avgdata 24388maxresident)k
1186752inputs+1584outputs (0major+56950minor)pagefaults 0swaps
Here is some more info:
igour atmarama ~ financije trunk $ fossil dbstat
18 matches
Mail list logo
