[Default] On Fri, 9 Jan 2015 10:59:30 -0800, jungle Boogie
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:
http://twit.cachefly.net/audio/floss/floss0026/floss0026.mp3
--
Regards,
On Fri, Jan 9, 2015 at 1:59 PM, jungle Boogie
wrote:
>
> Hi Luca,
> On 8 January 2015 at 23:18, Luca Ferrari wrote:
> > Partly unrelated, and quite old, but there's another interesting
> > interview about SQLite: http://twit.tv/show/floss-weekly/26
> >
>
> Yes, but unfortunately the file is 404.
Hi Luca,
On 8 January 2015 at 23:18, Luca Ferrari wrote:
> On Thu, Jan 8, 2015 at 5:55 AM, Scott Robison 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 u
On Fri, Jan 9, 2015 at 11:48 AM, Joerg Sonnenberger 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 same state (same blob ID
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 scrat
On Thu, Jan 8, 2015 at 5:55 AM, Scott Robison 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 interesting
interview
On Thu, Jan 8, 2015 at 7:17 PM, Stephan Beal 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 does (and Hg (and m
On Fri, Jan 9, 2015 at 1:13 AM, 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.
>
Indeed, the mtime (available directly) and size (available indirectly, via
a join) are quick checks, bu
On Thu, Jan 8, 2015 at 7:01 PM, Stephan Beal wrote:
> On Fri, Jan 9, 2015 at 12:56 AM, Andreas Kupries > wrote:
>>
>> I.e. the command implementation would have to detect the unchanged
>> files on update and skip them.
>>
>
> Which would almost certainly once in a blue moon, as a side-effect of
On Fri, Jan 9, 2015 at 12:56 AM, Andreas Kupries
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 conjunction with
manifest
On Thu, Jan 8, 2015 at 3:32 PM, Joerg Sonnenberger
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 similar performance
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 similar performance hits ? Does it have a
> diff't method to verify integrity, or d
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 similar performance hits ? Does it have a
diff't method to verify integrity, or does it punt on that front
because of guarantees from elsewher
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 ha
On Thu, Jan 8, 2015 at 7:34 PM, bch 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 curious to know
On Thu, Jan 8, 2015 at 7:34 PM, Warren Young 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 through to get
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
On Thu, Jan 8, 2015 at 7:16 PM, 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?
>
Is it
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?
W
On Thu, Jan 8, 2015 at 6:34 PM, bch 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:
https://www.fossi
Dear Richard,
From: Richard Hipp
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 wrote:
On Thu, Jan 8, 2015 at 6:55 AM, Scott Robison
wrote:
On 1/8/15, Richard Hipp wrote:
> On 1/8/15, Baruch Burstein wrote:
>> On Thu, Jan 8, 2015 at 6:55 AM, Scott Robison
>> 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 1/8/15, Andy Bradford 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.
>
Permission prob
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 1/8/15, Baruch Burstein wrote:
> On Thu, Jan 8, 2015 at 6:55 AM, Scott Robison
> 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 lookin
On Thu, Jan 8, 2015 at 6:55 AM, Scott Robison
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. Show us what you've
On Thu, Jan 8, 2015 at 8:41 AM, Stephan Beal wrote:
> On Thu, Jan 8, 2015 at 5:55 AM, Scott Robison
> wrote:
>
>> Just watched the interview at http://twit.tv/show/floss-weekly/320 ...
>> good job!
>>
>
> FYI: the interview itself starts at minute 7.
>
Be prepared to pause for a laugh at minute
On Thu, Jan 8, 2015 at 5:55 AM, Scott Robison
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
"Freedom is sloppy. Bu
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
29 matches
Mail list logo
