Re: [fossil-users] FLOSS interview
[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, Cordialement, Groet, Kees Nuyt ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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. > > % fetch https://twit.cachefly.net/FLOSS-026.ogg > fetch: https://twit.cachefly.net/FLOSS-026.ogg: Not Found Well, the MP3 version is still available from the original link that Luca shared, so you can download that as an alternative. It does indeed seem that the Ogg link is dead though. - joe ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 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.
% fetch https://twit.cachefly.net/FLOSS-026.ogg
fetch: https://twit.cachefly.net/FLOSS-026.ogg: Not Found
> Luca
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 and chnged=0) in vfile. This sounds like something very interesting to try (in both fossil and libfossil), but i'm still in "limited typing mode" due to an elbow nerve infection (from too much typing!) for at least another week :(. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 scratch. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 about SQLite: http://twit.tv/show/floss-weekly/26
Luca
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS 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 maybe even SVN)). Maybe Fossil qualifies for an "Enhanced Integrity" item on its feature list. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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, but "can one really be certain?" (i'm largely
playing Devil's Advocate here.)
Here's the checkout ("vfile") schema:
https://www.fossil-scm.org/fossil/info/6aa448a328fef31516933b763985247add80292b?ln=475-503
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 > external forces, have a false negative and cause grief? The current > behaviour is "slow but sure," but obviously inadequate (or "over-adequate") > for massive repos. > 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. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 parsing, i.e. C. Or we write an SQL routine like file_is_changed(name) and reimplement 'update' and friends to use the new vtable? (i'm just speculating - don't know if that's reasonable/feasible.) > 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 external forces, have a false negative and cause grief? The current behaviour is "slow but sure," but obviously inadequate (or "over-adequate") for massive repos. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 hits ? Does it have a >> diff't method to verify integrity, or does it punt on that front >> because of guarantees from elsewhere, or a different requirements ? > > You can't really avoid the O(n) hit without using a background monitor > or the like. My point is that table update is done in such a bad manner, > that the *constant* factor is extremely high. In other words, you want > to update to a version with m changed files for a working copy with n > files, the write cost should be O(m), but it is O(n). Ok, is that something which can be fixed by rewriting key pieces of SQL and/or C ? I.e. the command implementation would have to detect the unchanged files on update and skip them. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com, http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 does it punt on that front > because of guarantees from elsewhere, or a different requirements ? You can't really avoid the O(n) hit without using a background monitor or the like. My point is that table update is done in such a bad manner, that the *constant* factor is extremely high. In other words, you want to update to a version with m changed files for a working copy with n files, the write cost should be O(m), but it is O(n). Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 elsewhere, or a different requirements ? -bch On 1/8/15, Joerg Sonnenberger wrote: > 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 50k files, that's a lot of IO, especially as > almost nothing changes. The stat(2) part is a necessary evil, but by > itself quite fast, especially on a SSD. > > Joerg > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 50k files, that's a lot of IO, especially as almost nothing changes. The stat(2) part is a necessary evil, but by itself quite fast, especially on a SSD. Joerg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 if there is a spike in site traffic in the coming week -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 to the version in question of each file. But yeah, i guess we could say it's effectively O(N) (and conceptually it certainly is). > (It’s a good assumption unless you’ve taken some uncommon steps to ensure > that it *is* reliable. See “Disks from the Perspective of a File System,” > by Marshall Kirk McKusick in ACM Queue: http://goo.gl/hHvdQ8) > i think it's fair to say that Richard's fairly well-versed in the topic of disk reliability ;). > >What is the limiting factor? > > The balance between your patience and your disk’s I/O throughput. > Pretty much! Even the largest repos will _eventually_ finish, provided they don't overstep sqlite/system limits. Repos with large blobs might fail on systems with very constrained memory/virtual memory. e.g. if you have a 2GB blob in your DB, Fossil needs (at times) to allocate more than twice that (e.g. when diffing versions, as the delta generation algorithm requires all content to be in memory). A Raspberry Pi without enough swap space (virtual memory) could easily choke on that (and would take ages swapping out to SD Card). This problem has historically been ignored since SQLite’s repo was viewed > as “large” at ~50 MiB. > Interestingly, i've had to face philosophical questions in libfossil in this regard. My instinct tells me to (like fossil) calculate the R-card by default, but the optimizer and memory allocator in me screams out "no!" So there's a toggle, but the "final" default is as yet undecided. > >Is there a path to improve this performance similar to the SQLite > speed gains in the last 2 years? > > The SQLite improvements improve Fossil’s speed, too. > > I wouldn’t recommend turning off repo-cksum unless you are storing your > fossils on uncommonly-durable storage: > > 1. Battery-backed hardware RAID; or > > 2. A filesystem that does data checksumming itself, like ZFS, so that > Fossil’s data checksumming is redundant. > For "small" repos (which covers the vast majority of single-user/small-team repos), there's little reason to disable it. It was (AFAIK) never recognized as a "problem" until Fossil was pushed into service in "very large" repos. Perhaps Richard recognized the potential for this during the initial, but had a backwards-compatible long-term fix should it ever pose a problem: simply make it (the R-card) an optional part of the manifest. Whether that was accident or foresight, i can't say, but based on my experience with Richard i'd bet it was foresight. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 assumption that the filesystem may not be reliable. (It’s a good assumption unless you’ve taken some uncommon steps to ensure that it *is* reliable. See “Disks from the Perspective of a File System,” by Marshall Kirk McKusick in ACM Queue: http://goo.gl/hHvdQ8) >What is the limiting factor? The balance between your patience and your disk’s I/O throughput. If your disk can run the Fossil MD5 scan at a rate of 100 MByte/sec, a 300 MByte repository file will take at least 3 seconds to do many types of operations unless you turn the repo-cksum setting off. This problem has historically been ignored since SQLite’s repo was viewed as “large” at ~50 MiB. >Is there a path to improve this performance similar to the SQLite speed > gains in the last 2 years? The SQLite improvements improve Fossil’s speed, too. I wouldn’t recommend turning off repo-cksum unless you are storing your fossils on uncommonly-durable storage: 1. Battery-backed hardware RAID; or 2. A filesystem that does data checksumming itself, like ZFS, so that Fossil’s data checksumming is redundant. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 SQLite or the fossil approach itself? > The number of files is the primary factor, if i'm not sorely mistaken. Building up a manifest of (say) 5k+ files takes up a large amount of memory and time, and calculating the R-card for it is _tremendously_ expensive (computationally and memory costs). IIRC, the BSD package repo was the initial reason the R-card was eventually made optional (see the 'repo-cksum' option). The mtime-changes option can also speed up access on large repos, but 5 files in a checkin still requires stat()ing 5 files. Is there a path to improve this performance similar to the SQLite speed > gains in the last 2 years? > Not a concrete one, but we are always happy when people point out new efficiency improvement possibilities. Since we have literally the world's foremost expert writing much of the SQL, we get the benefit of his ability to write SQL which he knows sqlite can handle most efficiently. Not that _all_ of the SQL is written by Richard, but certainly the core-most SQL is/was primarily his. FWIW (and this is my personal opinion): i've never seen Fossil as having been in the market to compete for users or draw users away from any given SCM. "It is what it is." Fossil serves a particular niche very well (small/medium projects with small, focused teams), and is (if i may say so) an absolute godsend for single-developer projects (its CGI support, though archaic-sounding, is what first got me to take a close look at Fossil). It doesn't support other niches well (massively projects: Kernels, OpenOffice, BSD package super-repository, etc.). i've never seen that as a bad thing. i.e. never felt that fossil _should_ necessarily aim to scale up to those types of projects. That said: it'd be interesting to hear ideas about how it might be (re-)made to. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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? What is the limiting factor? Is it SQLite or the fossil approach itself? Is there a path to improve this performance similar to the SQLite speed gains in the last 2 years? Thanks for Fossil! On Thu, Jan 8, 2015 at 1:05 PM, Stephan Beal wrote: > 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.fossil-scm.org/fossil/eventedit > > ;) > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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.fossil-scm.org/fossil/eventedit ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 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! :)
Just watched it myself. A couple of notes on the interview:
1. You forgot to mention the main difference between git and fossil -
history is immutable.
I did a poor job of selling Fossil on that interview. The session was
nothing like what I expected and as a result I was not properly
prepared. Oh well..
I disagree! Thank you so much for writing to Randal and being on the show. I
appreciated the fact you were honest about the project (i.e. may not work
extremely well with netBSD), and that you made it clear to keep using what you
like.
I also liked that you stressed the BSD license so the git people can take
fossil stuff and add it to git.
--
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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. {snicker}
>>>
>>> Oh, and I'm always looking for a good text editor. Show us what you've
>>> got! :)
>>>
>>
>> Just watched it myself. A couple of notes on the interview:
>>
>> 1. You forgot to mention the main difference between git and fossil -
>> history is immutable.
>
> I did a poor job of selling Fossil on that interview. The session was
> nothing like what I expected and as a result I was not properly
> prepared. Oh well..
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.
>> 2. Can we see that text editor? ;)
>
> My text editor, written ~20 years ago in Tk3.6, is now uploaded to
> http://www.fossil-scm.org/e.txt - To use it, download it and rename it
> to just "e" (or whatever else you want) and make it executable and put
> it on your $PATH. Make sure you have Tcl/Tk installed. It also works
> on Windows, but you have to manually start it, ex: wish c:/bin/e.tcl
> FILETOEDIT
>
> There is nothing to recommend this editor. I like it, since it is
> customized to how I work. But I would be very surprised if anybody
> else found it useful. There are lots of full-featured editors
> available - this is not one of them.
>
>
>>
>>
>>
>> --
>> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
>>
>
>
> --
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 problem fixed. Please try again. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
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 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! :)
>>
>
> Just watched it myself. A couple of notes on the interview:
>
> 1. You forgot to mention the main difference between git and fossil -
> history is immutable.
I did a poor job of selling Fossil on that interview. The session was
nothing like what I expected and as a result I was not properly
prepared. Oh well..
> 2. Can we see that text editor? ;)
My text editor, written ~20 years ago in Tk3.6, is now uploaded to
http://www.fossil-scm.org/e.txt - To use it, download it and rename it
to just "e" (or whatever else you want) and make it executable and put
it on your $PATH. Make sure you have Tcl/Tk installed. It also works
on Windows, but you have to manually start it, ex: wish c:/bin/e.tcl
FILETOEDIT
There is nothing to recommend this editor. I like it, since it is
customized to how I work. But I would be very surprised if anybody
else found it useful. There are lots of full-featured editors
available - this is not one of them.
>
>
>
> --
> ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
>
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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
> got! :)
>
Just watched it myself. A couple of notes on the interview:
1. You forgot to mention the main difference between git and fossil -
history is immutable.
2. Can we see that text editor? ;)
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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 22: "You know ex-smokers seem to be the most adamant about second-hand smoke? It's kinda the same way with ex-git users who are now on fossil." -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] FLOSS interview
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. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
