[Default] On Fri, 9 Jan 2015 10:59:30 -0800, jungle Boogie
jungleboog...@gmail.com wrote:
Yes, but unfortunately the file is 404.
% fetch https://twit.cachefly.net/FLOSS-026.ogg
fetch: https://twit.cachefly.net/FLOSS-026.ogg: Not Found
Try:
Hi Luca,
On 8 January 2015 at 23:18, Luca Ferrari fluca1...@infinito.it wrote:
On Thu, Jan 8, 2015 at 5:55 AM, Scott Robison sc...@casaderobison.com wrote:
Just watched the interview at http://twit.tv/show/floss-weekly/320 ... good
job! I can't believe DRH didn't drop my name, but I'll forgive
On Fri, Jan 9, 2015 at 1:59 PM, jungle Boogie jungleboog...@gmail.com
wrote:
Hi Luca,
On 8 January 2015 at 23:18, Luca Ferrari fluca1...@infinito.it wrote:
Partly unrelated, and quite old, but there's another interesting
interview about SQLite: http://twit.tv/show/floss-weekly/26
Yes,
On Thu, Jan 08, 2015 at 07:13:17PM -0500, Ron W wrote:
Does the check-out DB record the mtime and size of the files in the
check-out? If so, you have at least some defence against false negatives.
It does and to go back to the slow update, it will truncate that table
and populate it from
On Fri, Jan 9, 2015 at 11:48 AM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
It does and to go back to the slow update, it will truncate that table
and populate it from scratch.
Currently, but i suspect we could do better if we'd use the new vtable to
filter out files which have the
On Thu, Jan 8, 2015 at 3:32 PM, Joerg Sonnenberger
jo...@britannica.bec.de wrote:
On Thu, Jan 08, 2015 at 03:21:07PM -0800, bch wrote:
The mtime/stat(2) stress is expensive because it's a order(n)
operation, but better than any other validation (checksumming) method
-- is git not subject to
On Thu, Jan 8, 2015 at 7:17 PM, Stephan Beal sgb...@googlemail.com wrote:
Indeed, the mtime (available directly) and size (available indirectly, via
a join) are quick checks, but can one really be certain? (i'm largely
playing Devil's Advocate here.)
True. Would be worth knowing what git
On Fri, Jan 9, 2015 at 1:13 AM, Ron W ronw.m...@gmail.com wrote:
Does the check-out DB record the mtime and size of the files in the
check-out? If so, you have at least some defence against false negatives.
Indeed, the mtime (available directly) and size (available indirectly, via
a join) are
On Fri, Jan 9, 2015 at 12:56 AM, Andreas Kupries andre...@activestate.com
wrote:
Ok, is that something which can be fixed by rewriting key pieces of
SQL and/or C ?
There's no current way (other than the new vtable) to get the files for a
given version via SQL, so that'd have to be done in
On Thu, Jan 8, 2015 at 5:55 AM, Scott Robison sc...@casaderobison.com wrote:
Just watched the interview at http://twit.tv/show/floss-weekly/320 ... good
job! I can't believe DRH didn't drop my name, but I'll forgive him this
time. {snicker}
Partly unrelated, and quite old, but there's another
On Thu, Jan 8, 2015 at 7:01 PM, Stephan Beal sgb...@googlemail.com wrote:
On Fri, Jan 9, 2015 at 12:56 AM, Andreas Kupries andre...@activestate.com
wrote:
I.e. the command implementation would have to detect the unchanged
files on update and skip them.
Which would almost certainly once
On 1/8/15, Baruch Burstein bmburst...@gmail.com wrote:
On Thu, Jan 8, 2015 at 6:55 AM, Scott Robison sc...@casaderobison.com
wrote:
Just watched the interview at http://twit.tv/show/floss-weekly/320 ...
good job! I can't believe DRH didn't drop my name, but I'll forgive him
this time.
On Thu, Jan 8, 2015 at 8:41 AM, Stephan Beal sgb...@googlemail.com wrote:
On Thu, Jan 8, 2015 at 5:55 AM, Scott Robison sc...@casaderobison.com
wrote:
Just watched the interview at http://twit.tv/show/floss-weekly/320 ...
good job!
FYI: the interview itself starts at minute 7.
Be
On Thu, Jan 8, 2015 at 6:55 AM, Scott Robison sc...@casaderobison.com
wrote:
Just watched the interview at http://twit.tv/show/floss-weekly/320 ...
good job! I can't believe DRH didn't drop my name, but I'll forgive him
this time. {snicker}
Oh, and I'm always looking for a good text editor.
On 1/8/15, Richard Hipp d...@sqlite.org wrote:
On 1/8/15, Baruch Burstein bmburst...@gmail.com wrote:
On Thu, Jan 8, 2015 at 6:55 AM, Scott Robison sc...@casaderobison.com
wrote:
Just watched the interview at http://twit.tv/show/floss-weekly/320 ...
good job! I can't believe DRH didn't drop
Dear Richard,
From: Richard Hipp d...@sqlite.org
Sent: Thu, 8 Jan 2015 07:52:41 -0500
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FLOSS interview
On 1/8/15, Baruch Burstein bmburst...@gmail.com wrote:
On Thu, Jan 8, 2015 at 6:55 AM
On Thu, Jan 8, 2015 at 6:34 PM, bch brad.har...@gmail.com wrote:
Time to collect information on the weak/missing parts and either add
them to the comments of FLOSS Weekly, get Leo to publish an addendum
note, or publish an addendum on fossil-scm.org w/ link to original
interview.
@Richard:
Yes, always interesting to hear from Dr Hipp.
1. I had not considered fossil all push/pull.
2. I was hoping for a followup question to:
Fossil does not perform well with very large repo's or histories 15
years.
How is the performance hit quantified? 1day or 1hour / 1GB repo / commit?
On Thu, Jan 8, 2015 at 7:16 PM, sky5w...@gmail.com wrote:
2. I was hoping for a followup question to:
Fossil does not perform well with very large repo's or histories 15
years.
How is the performance hit quantified? 1day or 1hour / 1GB repo /
commit?
What is the limiting factor?
On Jan 8, 2015, at 11:16 AM, sky5w...@gmail.com wrote:
Fossil does not perform well with very large repo's or histories 15
years.
How is the performance hit quantified? 1day or 1hour / 1GB repo / commit?
Fossil does an O(N) scan over the entire DB as an extra integrity check, on the
On 1/8/15, Andy Bradford amb-fos...@bradfords.org wrote:
Thus said Richard Hipp on Thu, 08 Jan 2015 07:52:41 -0500:
My text editor, written ~20 years ago in Tk3.6, is now uploaded to
http://www.fossil-scm.org/e.txt -
The server keeps closing the connection when trying to get this file.
Thus said Richard Hipp on Thu, 08 Jan 2015 07:52:41 -0500:
My text editor, written ~20 years ago in Tk3.6, is now uploaded to
http://www.fossil-scm.org/e.txt -
The server keeps closing the connection when trying to get this file.
Andy
--
TAI64 timestamp: 400054aea5d2
On Thu, Jan 8, 2015 at 7:34 PM, Warren Young w...@etr-usa.com wrote:
Fossil does an O(N) scan over the entire DB as an extra integrity check,
on the assumption that the filesystem may not be reliable.
The N potentially has another multiplier factor depending on how many
deltas it has to weed
On Thu, Jan 8, 2015 at 7:34 PM, bch brad.har...@gmail.com wrote:
Time to collect information on the weak/missing parts and either add
them to the comments of FLOSS Weekly, get Leo to publish an addendum
note, or publish an addendum on fossil-scm.org w/ link to original
interview.
I would be
On Thu, Jan 08, 2015 at 07:29:53PM +0100, Stephan Beal wrote:
The number of files is the primary factor, if i'm not sorely mistaken.
Correct, but not in the way you expect :) For day to day operation, the
most annoying part is fossil update, which rewrites the mtime table
completely. If you have
On Thu, Jan 8, 2015 at 5:55 AM, Scott Robison sc...@casaderobison.com
wrote:
Just watched the interview at http://twit.tv/show/floss-weekly/320 ...
good job!
FYI: the interview itself starts at minute 7.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Just watched the interview at http://twit.tv/show/floss-weekly/320 ... good
job! I can't believe DRH didn't drop my name, but I'll forgive him this
time. {snicker}
Oh, and I'm always looking for a good text editor. Show us what you've got!
:)
--
Scott Robison
27 matches
Mail list logo
