On 13/12/17 18:02, Warren Young wrote:
On Dec 12, 2017, at 12:33 PM, Juan Francisco Cantero Hurtado
wrote:
I want share a fossil repo using a static http server
Call something like this from a crontab:
$ wget -O /var/www/html/dl/my-project.zip http://localhost:8080/zip
Then in the HT
One thing I often wish Fossil did was show other things (tickets, wiki
pages) that reference tickets rather than just checkins -- I often have a
mess of tickets that refer to other tickets and no place to generate a
list of them, or reverse them.
On Wed, 13 Dec 2017, Richard Hipp wrote:
On 1
On Dec 13, 2017, at 2:21 PM, Zakero wrote:
>
> The "fossil clean" command has the "--emptydirs" option. That might be
> useful for the "rm" command as well.
If Fossil got that option, I’d probably forget that it existed a week after the
change went in. I’d end up saying something like
$
On Dec 11, 2017, at 9:19 PM, Warren Young wrote:
>
> I’d go as far as #F8F8F8 myself.
One of my Fossil projects’ skins is based on Khaki, which hasn’t yet been
restyled to override the base styles for the timeline boxes, so I get light
gray on yellow, not terribly attractive. The following CS
On Wed, Dec 13, 2017 at 3:01 PM, Warren Young wrote:
> On Dec 13, 2017, at 1:03 PM, jungle Boogie
> wrote:
> >
> > On 13 December 2017 at 07:58, Warren Young wrote:
> >
> >> I’d feel differently if Fossil owned the directories, but it doesn’t.
> They’re mine; leave them alone!
> >
> > Yes, I ag
On Dec 13, 2017, at 1:37 PM, Richard Hipp wrote:
>
> On 12/13/17, Warren Young wrote:
>> I just tried to rebuild a Fossil repo that I’d lost permission to read due
>> to some sysadmin silliness, and got spammed by this in a rapid loop:
>>
>> PRAGMA database_list
>> SQLITE_CANTOPEN: cannot open
On Dec 13, 2017, at 1:03 PM, jungle Boogie wrote:
>
> On 13 December 2017 at 07:58, Warren Young wrote:
>
>> I’d feel differently if Fossil owned the directories, but it doesn’t.
>> They’re mine; leave them alone!
>
> Yes, I agree. I think this topic has been raised here in the past,
> altho
On 12/13/17, Warren Young wrote:
> I just tried to rebuild a Fossil repo that I’d lost permission to read due
> to some sysadmin silliness, and got spammed by this in a rapid loop:
>
> PRAGMA database_list
> SQLITE_CANTOPEN: cannot open file at line 36229 of [1a584e4999]
> SQLITE_CANTOPEN: os_unix
On 13 December 2017 at 07:58, Warren Young wrote:
> I’d feel differently if Fossil owned the directories, but it doesn’t.
> They’re mine; leave them alone!
Yes, I agree. I think this topic has been raised here in the past,
although that was about removing files. Still, If I created the
directo
On 13 December 2017 at 11:08, Richard Hipp wrote:
> On 12/13/17, jungle Boogie wrote:
>> On 13 December 2017 at 09:07, Warren Young wrote:
>>> On Dec 13, 2017, at 9:55 AM, Richard Hipp wrote:
Would Git or GitHub have told me about those prior tickets?
>>>
>>> GitHub is pretty good abo
On 12/13/17, jungle Boogie wrote:
> On 13 December 2017 at 09:07, Warren Young wrote:
>> On Dec 13, 2017, at 9:55 AM, Richard Hipp wrote:
>>>
>>> Would Git or GitHub have told me about those prior tickets?
>>
>> GitHub is pretty good about surfacing such information, as long as the
>> ticket ref
On 13 December 2017 at 09:07, Warren Young wrote:
> On Dec 13, 2017, at 9:55 AM, Richard Hipp wrote:
>>
>> Would Git or GitHub have told me about those prior tickets?
>
> GitHub is pretty good about surfacing such information, as long as the ticket
> references the checkin ID.
Yep. With most pr
On 12/13/17, Warren Young wrote:
> On Dec 13, 2017, at 9:26 AM, Warren Young wrote:
>>
>> ...I’d lost permission to read...
>>
>> SQLITE_CANTOPEN: os_unix.c:36229: (2) open(/nunya/binness.fossil-wal) - No
>> such file or directory
>
> Actually, it looks like it’s opening the DB for reading but th
On Dec 13, 2017, at 9:26 AM, Warren Young wrote:
>
> ...I’d lost permission to read...
>
> SQLITE_CANTOPEN: os_unix.c:36229: (2) open(/nunya/binness.fossil-wal) - No
> such file or directory
Actually, it looks like it’s opening the DB for reading but then fails to write
the WAL file because t
On Dec 13, 2017, at 9:55 AM, Richard Hipp wrote:
>
> Would Git or GitHub have told me about those prior tickets?
GitHub is pretty good about surfacing such information, as long as the ticket
references the checkin ID.
In fact, GitHub can be a bit overeager about cross-linking everything. Ju
-Original Message-
From: Warren Young
* The second is the presence of free pages not yet vacuumed. This is
unused space that IMO ‘unfairly’ lowers the ratio.
I disagree. The unused free pages *should* be charged against you, because
that is space Fossil is taking on your disk, and
On Dec 12, 2017, at 12:33 PM, Juan Francisco Cantero Hurtado
wrote:
>
> I want share a fossil repo using a static http server
Call something like this from a crontab:
$ wget -O /var/www/html/dl/my-project.zip http://localhost:8080/zip
Then in the HTML:
Download
> I want share only t
A bug was reported again SQLite, just moments ago. Bisecting lands on
this check-in: https://www.sqlite.org/srcx/info/559733b09e
Right away, I see that there are two prior bug reports against the
same check-in, which seems like important information from a project
administrator perspective. (I h
On Dec 12, 2017, at 2:40 PM, Thomas wrote:
>
> On 2017-12-11 22:55, Warren Young wrote:
>> notepad.exe and Internet Explorer also obey the 8-character tab standard.
>> Go tell Microsoft it is wrong, too.
>
> I'm not sure how many people use notepad.exe to edit source code or to write
> softwa
I just tried to rebuild a Fossil repo that I’d lost permission to read due to
some sysadmin silliness, and got spammed by this in a rapid loop:
PRAGMA database_list
SQLITE_CANTOPEN: cannot open file at line 36229 of [1a584e4999]
SQLITE_CANTOPEN: os_unix.c:36229: (2) open(/nunya/binness.fossil-wal
On Dec 13, 2017, at 8:31 AM, Tony Papadimitriou wrote:
>
> * The first is the inclusion of un-versioned files which although inflate the
> total file size have no play in the versioning part, which is what I believe
> the compression ratio was meant to highlight.
If unversioned file data isn’t
On Dec 13, 2017, at 6:21 AM, Tino Lange wrote:
>
> The directory/directories will keep existing!
Given that Fossil doesn’t know anything about directories, other than as
containers for the files it manages, I’m not sure that isn’t the right thing.
To have Fossil remove intermediate directories
It appears that the compression ratio shown with the ‘fossil db –db-check’
command is based on the actual total file size of the repo against the would-be
size of all expanded versions stored separately (based on description here:
https://www.fossil-scm.org/xfer/doc/trunk/www/stats.wiki).
There
Hi!
When doing a
$ fossil rm --hard dir1
it will unregister from fossil and then delete all files within the
'dir1' hierarchy.
But: The directory/directories will keep existing!
I need to do a
$ rm -rf dir1
afterwards (so the whole --hard is mostly needless, since I need to do
the additional
24 matches
Mail list logo
