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
Thus said Kelly Dean on Thu, 08 Jan 2015 08:52:28 +:
> Yes, a badly-behaving one. That's why I said the network probably
> dropped some packets. But I used HTTPS, so the problems the proxy
> could have introduced would be no more than dropped packets, and bogus
> TCP resets (which SS
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:
Just watche
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 Thu, Jan 8, 2015 at 6:45 AM, Ron Aaron wrote:
> Is there any way to have fossil change the ticket resolution to 'fixed'
> when I change the status to 'fixed'?
>
In Administration, in Ticket Config, edit the Edit Ticket page to modify
the TH1 code.
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
Is there any way to have fossil change the ticket resolution to
'fixed' when I change the status to 'fixed'?
I end up doing two changes every single time. I realize one may
want to reopen a 'fixed' bug, but in most cases, when I mark
something as 'fixed' I mean it..
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
Whoever kept trying and failing to download my fossil-src files using MSIE 8.0
an hour ago, and only got 153600 bytes each time... try a better browser.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-
Andy Bradford wrote:
> Any chance you can use --httptrace when cloning with whatever is causing
> this problem? --httptrace will leave behind a handful of .txt files
> beginning with http- which have the requests and replies Fossil makes.
Problem not reproducible at the moment.
>> -rw-r--r--
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
27 matches
Mail list logo
