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
Hello,
is 'ls --age $single_filename' supported? For a vanilla file, I get an error:
---
michai@main:~/proj/068$ ls -l scratch.txt
-rw-r--r-- 1 michai users 56173 Jun 27 17:17 scratch.txt
michai@main:~/proj/068$ f ls scratch.txt
scratch.txt
michai@main:~/proj/068$ f ls -v scratch.txt
On Mon, Jul 21, 2014 at 11:43 AM, Stephan Beal sgb...@googlemail.com
wrote:
On Mon, Jul 21, 2014 at 11:39 AM, Michai Ramakers m.ramak...@gmail.com
wrote:
datetime(checkin_mtime(4258,rid),'unixepoch') FROM vfile WHERE
(pathname='scratch.txt' ) OR (pathname'sc
f: SQL error: callback
On 21 July 2014 11:43, Stephan Beal sgb...@googlemail.com wrote:
On Mon, Jul 21, 2014 at 11:39 AM, Michai Ramakers m.ramak...@gmail.com
wrote:
datetime(checkin_mtime(4258,rid),'unixepoch') FROM vfile WHERE
(pathname='scratch.txt' ) OR (pathname'sc
f: SQL error: callback requested query
On Mon, Jul 21, 2014 at 11:39 AM, Michai Ramakers m.ramak...@gmail.com
wrote:
michai@main:~/proj/068$ f ls --age scratch.txt
SQLITE_ABORT: statement aborts at 15: [SELECT pathname, deleted, rid,
chnged, coalesce(origname!=pathname,0),
datetime(checkin_mtime(4258,rid),'unixepoch') FROM vfile
Hello,
when I view file-ages of a subtree of the repo using the (extremely
useful) 'glob=' property to '/fileage', the displayed 'relative-to'
date of the tip doesn't match the displayed offsets of the artifacts.
(offset is displayed as 38.9 days, while in fact the last checkin of
the artifacts
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
On 13 July 2014 00:21, Michai Ramakers m.ramak...@gmail.com wrote:
looking at an old post
(http://lists.fossil-scm.org:8080/pipermail/fossil-users/2011-December/007799.html)
reporting leftovers in the form of empty dirs when switching between
checkouts, I wonder if anything has been done to
13 matches
Mail list logo
