Re: [fossil-users] I have no idea what this is trying to tell me...

[Warren Young]

On May 8, 2019, at 7:30 PM, Michael Richter  wrote:
> 
> ERROR: [CPU/STM32F103RC_buildnumber] is different on disk compared to the 
> repository

This happens during handling of the repo-cksum option, which is enabled by 
default.  For that check to fail, it means you’ve got data corruption somewhere 
along the line.  It calls into question the durability of your filesystem, the 
integrity of RAM, etc.

If the computer is utterly reliable, this cannot happen and repo-cksum is a 
waste of CPU time and disk I/O.

Here’s an old thread with more detail on the problem:


https://fossil-users.fossil-scm.narkive.com/9ybRAo1U/error-file-is-different-on-disk-compared-to-the-repository-during-commit

You might post such things to the forum instead in the future:

https://fossil-scm.org/forum/

This mailing list is deprecated:

 
https://fossil-users.fossil-scm.narkive.com/tWk8GI2P/this-mailing-list-is-now-deprecated
___
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] Fossil update

[Warren Young]

On Nov 7, 2018, at 6:18 AM, Zoltán Kócsi  wrote:
> 
> For some projects we used colour-coding of the Timeline entries, for
> example releases were coloured differently from developers-only commits
> and so on. That all seems to have gone.

If you upgraded your central repository server from 1.29 to 2.7 to fix the 
problem suggested by drh — someone’s been checking in SHA3-hashed artifacts — 
then you also have to update your skin.

If you were using the stock skin before, just go into Admin > Skins and select 
the Default skin again.  You might have to switch to some other skin and back 
to get it to overwrite your outdated skin files.

If you made changes to your local skin, you’ll have to merge the changes made 
to the default version of the skin you started with into your local version.

In versions 2.5 and 2.7, there were a lot of changes to the default skin, some 
of which were done to track changes made to the HTML emitted by “fossil server” 
in support of newer features.  Outdated skins won’t style the new HTML properly.
___
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] This mailing list is now deprecated

[Warren Young]

On Aug 11, 2018, at 12:19 PM, Warren Young  wrote:
> 
> The /forum repository on fossil-scm.org currently doesn’t even allow you to 
> clone the repository

I’m misremembering.  See https://fossil-scm.org/forum/forumpost/db505ad4af
___
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] This mailing list is now deprecated

[Warren Young]

On Aug 11, 2018, at 12:01 PM, Andy Bradford  wrote:
> 
> Throwing a rock through an 747's window  is one way to solve the problem
> of getting a plane  to drop in altitude, but that  doesn't mean it's the
> best way.

Why is that a good analogy for what’s been done here?

I’d say your analogy is exactly backwards: we’ve got people throwing rocks at 
our plane to make it drop in altitude, and we can’t prevent them from doing so, 
so instead we’ve redesigned the plane to make it impervious to thrown rocks.

> The problem described on that link  is about spammers subscribing to the
> mailing lists and  then sending automated spam to those  who post to the
> mailing list.

Yes, and that can’t happen with Fossil forums.

> I guess this new forum feature  was easier to implement,

The Fossil forum feature is inherently valuable, so you can’t charge the effort 
spent on it against the current spam problems.  Two of my own public 
Fossil-based projects will be adopting it soon.

With that cost externalized, the question then becomes whether it’s easier to 
use Fossil’s new forum moderation features or to keep fighting the spammers 
one-on-one.  Since part of that cost is also externalized — i.e. by drh making 
me a moderator — it seems likely that the new method will mean less overall 
work for drh.

That in turn means we either get more improvements in Fossil and SQLite, or drh 
gets time to do things he’d rather be doing than fighting spammers.  That 
sounds like a good thing to me.

> even if it does make communication less useful.

The Fossil forum has been quite busy over the past few days.  Most of the 
discussion is about the forums themselves, rather than general-interest Fossil 
topics, but that’s normal for a big new feature set.

It doesn’t seem that the new method is materially less useful than the old.
___
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] This mailing list is now deprecated

[Warren Young]

On Aug 11, 2018, at 11:36 AM, Andy Bradford  wrote:
> 
> The mailing list has yet to
> deliver spam as far as I can tell.

I’d have a hard time proving it, since I delete such things from my local 
archive, and I wouldn’t be surprised if many of the public archives have their 
own inbound spam filtering, too.

But, I’m pretty sure I do remember a few incidents of this.  The mailing list 
admin then has to go in and manually boot the user out, and probably add 
filtering to prevent that email address from re-joining the list.  That 
probably falls on drh’s shoulders.

Certainly there’s no reason in principle this could not happen.

As long as the Fossil forum moderators are paying attention, it *can’t* happen 
with Fossil forums.

> I believe what you mean is that  your email address that you use on this
> mailing list has been harvested by spammers and that they are contacting
> you directly.

Fossil does not expose the email address of its users.

The /forum repository on fossil-scm.org currently doesn’t even allow you to 
clone the repository, and even if it did, you wouldn’t get a copy of the user 
table without high-level privileges that won’t be handed out to anyone who 
isn’t already trusted.

> That can be easily thwarted by simply setting your From address to be an
> invalid address

“Easily”?  Either:

1. On every post, you manually edit the “From” address in your MUA to something 
invalid.  Yes, it’s just a drop-down selection in modern MUAs, but it’s an 
extra step on each and every posting.

2. You reconfigure your mailer to always use the invalid address by default, 
and then have to remember to fix it on every email reply where you’d actually 
like to receive a reply.

3. Set up some kind of smart filtering system (procmail, etc.) to do this based 
on the destination address for each email.

All three options fall outside the scope of “easily,” in my book.

Maybe you have an easier option?
___
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] Why no EXE+DLL like SQLite?

[Warren Young]

On Aug 10, 2018, at 4:05 PM, Ron W  wrote:
> 
> I recall some discussion about adding fsuser support to Fossil

Yes, it was checked in years ago.  See src/fusefs.c.

Getting FUSE working on Windows is reportedly difficult, however:

https://superuser.com/q/179436/14927

> so this could be done. 

Fossil-via-FUSE sounds pretty risky to me.  What happens if the host 
application says “File > Save” but there’s a merge conflict?  Does the app give 
an error dialog like “File I/O error”?  Will the user understand what that 
means and why it’s happening?  Does the user then manually do a “fossil up” and 
then save their copy over the top, effectively reverting the other user’s work?

At some point, you can’t insulate the users from having to know what version 
control is all about.
___
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] This mailing list is now deprecated

[Warren Young]

On Aug 10, 2018, at 7:19 AM, Andy Bradford  wrote:
> 
> Thus said Warren Young on Wed, 08 Aug 2018 11:45:09 -0600:
> 
>>> Will this ever be enabled? I prefer email over web forum posting.
>> 
>> How  would  you  prevent  spammers  from  using  an  email  submission
>> mechanism?
> 
> Most mailing list managers prevent  this by only allowing subscribers to
> submit  emails.  I cannot  recall  the  last time  I  saw  spam sent  to
> fossil-users@lists.fossil-scm.org…

That’s not the problem described in the thread I linked you to:

   
http://sqlite.1065341.n5.nabble.com/Problems-with-v3-9-0-entry-point-sqlite3-finalize-could-not-be-located-td85005.html#a85069

You only need to read the first post, not the whole thread.

Fossil forums prevent that problem.

> Gmail supports email aliases.

If you’re speaking of the free Gmail product, it only supports the 
user+...@example.com style, which fools no spammer.  They just strip the +ext 
bit off.

If you mean G Suite, you only get 30 of them per account.  I run the mail 
server for my personal domains, and I have 240 aliases on my main email 
account.  You want lots of aliases because it allows you to have unique email 
addresses for any site whose security you are not entirely certain about.

I wish I’d created *more* aliases, in fact, because my real email address gets 
most of the spam I receive, by far, suggesting that I should have hidden it 
more often.

>> If we don't solve that problem first,  we'll be right back in much the
>> same mess as today.
> 
> Replacing a mailing list with a web  forum seems to simply trade one set
> of problems  for another.

Every choice worth spending thought on has tradeoffs.

drh has made his choice.  I don’t think you’re going to sway him on this.

> I'm  on dozens  of other public  mailing lists
> that get a lot more traffic than Fossil Users does and there seems to be
> no problems there…

Roughly 80-90% of mail traffic is spam, but that’s not a problem?

   https://skeptics.stackexchange.com/q/2175

> Why don't  we leave  both in place  and see what  people prefer  to use?

I made that very suggestion earlier.

> Those who  are willing to  live with the  problems that come  with email
> will express their preference by continuing to use email.

Some of the burdens fall on drh, rather than on the users of the mailing list, 
so he has some say in how all of this goes.

> Is the web forum now moderated?

Yes, from day 1.  I am one of the moderators.

> Does it help?

No spam has made it into the forum blockchain yet.

I also haven’t seen anyone attempt to spam the forum.  If it never happens, 
that’s fine with me.
___
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] This mailing list is now deprecated

[Warren Young]

On Aug 9, 2018, at 8:33 PM, Offray Vladimir Luna Cárdenas  
wrote:
> 
> I can not login after registering myself.

Are you perhaps putting your email address in the user name field?  It only 
accepts user names, for now at least.
___
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] This mailing list is now deprecated

[Warren Young]

On Aug 9, 2018, at 2:12 AM, Aslak Raanes  wrote:
> 
> On 9 Aug 2018, at 4:23, Warren Young wrote:
> 
>> On Gmane’s About page, we find this: "Gmane is not an unproblematic 
>> project…Gmane makes it much easier for spam harvesters to gather these real, 
>> authentic mail addresses.”  So, Gmane is part of the problems that 
>> originally motivated the creation of and move to Fossil forums!
> 
> For the fossil-users mailing list Gmane via nntp only exposes mail addresses 
> as:
> 
>Warren Young 

And here are the next two sentences on that same Gmane About page:

   “Even though the Gmane web interface to the news spool obfuscates all 
addresses, a spam harvesting bot just has to point itself to the news interface 
to slurp down the entire spool. And there's not much I can do to stop that from 
happening.”

It stems from the fact that Gmane requires that you use a legitimate email 
address as a user name on their service.
___
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] This mailing list is now deprecated

[Warren Young]

On Aug 8, 2018, at 5:49 PM, Will Parsons  wrote:
> 
> I am
> disappointed that now I shall have to use a (expletive deleted) web
> forum to post comments...I have been using Gmane to read and post to
> both the Fossil and SQLite mailing lists.

I’ve always thought of Gmane as just another web front end for mailing list 
archives, but I now see that they allow NNTP posting.  May I then rephrase your 
complaint as “NNTP good, HTTP POST bad?”

On Gmane’s About page, we find this: "Gmane is not an unproblematic 
project…Gmane makes it much easier for spam harvesters to gather these real, 
authentic mail addresses.”  So, Gmane is part of the problems that originally 
motivated the creation of and move to Fossil forums!

> Please don't let this happen to the SQLite
> mail list also.

I believe the only question is “when,” not “whether:”

http://sqlite.1065341.n5.nabble.com/Mailing-list-shutting-down-td102466.html

This change is happening as a result of list spam problems going back to 
October 2015 at least:


http://sqlite.1065341.n5.nabble.com/Problems-with-v3-9-0-entry-point-sqlite3-finalize-could-not-be-located-tp85005p85069.html

I’ve gotten such spam here at work as recently as July 11, and our corporate 
email is handled by a mail service that’s *very* aggressive about dropping such 
emails before they even get to us.  My home email server gets a lot more of it.

I remember a time when an X Window server would allow any other computer on the 
LAN to pop up a window on your computer.  There was a program that marched an 
Energizer bunny across the bottom of all computers in the lab, with no special 
permission or background program needed on each computer to allow it.  The 
program just started sending pixels to each machine in turn, and the X server 
dutifully displayed the graphics as requested.

We don’t live in that world any more.  Spammers and other malefactors took our 
civilized Internet and ruined it for the rest of us.

Expletives indeed, but that solves nothing.  Fossil forums should be an 
effective solution to this real problem, and they give many benefits to us 
besides:

https://fossil-scm.org/index.html/doc/trunk/www/forum.wiki
___
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] 'fossil open' and existing local 'manifest' and 'manifest.uuid' files

[Warren Young]

On Aug 7, 2018, at 8:51 PM, Artur Shepilko  wrote:
> 
> When executing 'fossil
> open' for a newly created repo, if there're any existing local files
> named "manifest" and "manifest.uuid"  these get deleted.

Those files are generated by Fossil when you have the default-off setting 
“manifest” enabled.

I’m guessing that Fossil sees the files there, sees that “manifest” is 
disabled, so it assumes they were left by a previous run with the setting 
enabled and cleans them up.

Maybe it should only delete these files when you say “fossil set manifest 0”?
___
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] Error during commit

[Warren Young]

On Aug 6, 2018, at 11:30 AM, Philip Bennefall  wrote:
> 
> a second commit right afterwards caused a segfault again

In advance of drh getting time to work on this, maybe you could give two 
debugging steps on your end:

1. If you’re doing this on a platform that will run Valgrind, try running a 
debug build of Fossil under it against your repository:

$ cd /path/to/fossil/source/tree
$ ./configure --fossil-debug
$ make clean && make && sudo make install
$ cd /path/to/checkout/directory
$ valgrind fossil status

2. If you get a vgcore out of that, load it into GDB and produce a backtrace.  
If not, cores are probably disabled there, so run Fossil under gdb and get a 
backtrace that way.

(The first way is more likely to give a clean backtrace, as the failure gets 
caught before it can cause damage.)
___
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] Why no EXE+DLL like SQLite?

[Warren Young]

On Aug 5, 2018, at 2:14 PM, Gilles  wrote:
> 
> 1. SQLite is a DLL + EXE package

A great many programs have need for an embedded DBMS.  Very few programs have 
need for an embedded DVCS.

Note also that these are empirical observations, rather than opinions.

> 2. There's no maintained GUI for Fossil.

Looking for a project? :)
___
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] "fossil gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?

[Warren Young]

On Aug 4, 2018, at 12:13 PM, Gilles  wrote:
> 
> But then, "fossil changes" returns nothing either, and it's coherent with the 
> Unix philosophy.

Precisely.  You’re applying Windows mores to a tool that comes out of the Unix 
tradition.  As long as you do that, you’ll have expectation mismatches.

It is not correct to say that Fossil had no output in this case.  Its output 
was the exit status code, which was zero, meaning there was no failure.  Since 
there is also no standard output, that means there are no differences.  You can 
check for this combination in a POSIX shell:

diffs=$(fossil diff)
if [ $? = 0 ]
then
echo No difference found.
elif [ -n "$diffs" ]
then
echo Difference found.
else
echo Program exit failure, code $?.
fi

If you know the history of mathematics, you know what kind of contortions they 
had to go through before they invented the concept of zero.  This is analogous.

If we relied instead on text output to signal “No changes,” it would break if 
Fossil was ever localized:

if fossil diff | grep -q 'No changes'
then
… do something for the change case …
else
… do something else for the no-change case …
fi

You’d erroneously end up in the no-change case because the output would be 
“Aucun changement” on an OS configured for a French locale, if Fossil ever gets 
localized for French.

If you doubt the usefulness of such a script, consider a “make release” script, 
which first checks whether there are any changes to unexpected files before 
proceeding.  In one of my projects, the only expected changes upon creating a 
release are a new section in the ChangeLog.md file and a single-line change to 
the VERSION variable within the Makefile; anything else means you’ve probably 
forgotten to check something in separately first.  The above shell script logic 
allows us to test for things like this and stop the process if pilot error is 
suspected.

If I’ve yet to convince you that this design philosophy is sensible, consider 
that it’s one of several reasons why Unix type systems are far more easily 
scripted than Windows systems, which in turn is one of the largest reasons 
they’ve taken over the cloud space.  You can’t deploy 1000 Windows instances at 
peak load every day and tear them back down as the load decreases when you 
cannot easily and reliably script the process.

I speak from experience.  One of my current Windows software projects drives a 
program that is externally scriptable only by programming to its .NET API.  If 
this program were available on Linux and followed its conventions, I’d expect 
to be able to replace the .NET code and its attendant MSI deployment mess with 
a far simpler shell script.  I’ve probably spent more time getting the MSI 
creator working than I’d have spent writing that shell script.

Incidentally, I asked you for “fossil stat” output in part because I 
anticipated this possibility: it didn’t give you an “EDITED” line for these 
files you’ve been checking for changes.  You will come to notice absences like 
that.  It will be a clue that you either have no changes or that you forgot to 
add a new file to the repository, so Fossil is still ignoring it.
___
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] "fossil gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?

[Warren Young]

On Aug 4, 2018, at 6:49 AM, Gilles  wrote:
> 
> d:\temp\> fossil gdiff myfile.txt
> 
> Nothing.

Is d:\temp a checkout directory?  What does “fossil stat” give in that 
directory?
___
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] "fossil gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?

[Warren Young]

On Aug 4, 2018, at 5:16 AM, Gilles  wrote:
> 
> fossil settings > gdiff-command(global) "C:\Program 
> Files\WinMerge\WinMergeU.exe”

Double check that the executable is in fact there, not somewhere else, like 
c:\Program Files (x86).

If that doesn’t work, try “dir /x c:\” and putting in the short version of the 
path to avoid the embedded space.  If I had to guess, it’s:

c:\PROGRA~1\WinMerge\WinMergeU.exe

But check.  It could be ~2 or other things.

And if that still doesn’t work, try using forward slashes.  It’s possible this 
is running through sprintf() or similar internally to Fossil, so those 
backslashes are causing confusion.

> 2. Is there a way to make fossil.exe autocomplete commands, eg.
> 
> fo + TAB : fossil.exe
> fossil gd + TAB : fossil gdiff
> fossil gdiff my + TAB :fossil gdiff myfile.txt

That’s not something fossil.exe can do, even in principle.  It’s a function of 
your shell, not of the command the shell is about to run.  fossil.exe hasn’t 
even run yet at the point where you’re wanting command argument completion.

There are several advanced shells for Windows (e.g Cmder), but I don’t pay much 
attention to that space, so I can’t actually give any recommendations.

If you are willing to use a POSIX type shell on Windows, several of the 
advanced shells can be configured to do this.  E.g. with Bash:

https://hackaday.com/2018/01/19/linux-fu-custom-bash-command-completion/

Zsh can also certainly do it, and probably Fish as well.

Such shells are vastly superior to cmd.exe anyway.
___
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] Fossil's (lack of) use of the Ticket system

[Warren Young]

On Aug 3, 2018, at 12:18 PM, Richard Hipp  wrote:
> 
> On 8/3/18, Dan Barbarito  wrote:
>> Hi all, I am trying to understand why Fossil itself does not use the
>> built-in ticketing functionality. I understand that trolls + spammers may be
>> a problem, but can't ticket changes simply be approved/denied?
> 
> I tried that.  What I found was that I was spending an inordinate
> amount of time pressing the "Reject" button on new ticket moderation
> because almost all tickets were of the form "How do I do …"

There’s nothing inherently wrong with answering tech support questions via a 
ticket tracker as opposed to a mailing list or a web forum.  A great many 
people are in fact trained to do this by their local IT departments, who 
require that every problem be reported via the local ticket tracker.

In my own public Fossil projects, I’ve found that people are preferring to post 
tickets anonymously rather than subscribe to my mailing lists and post there.  
It seems to me that we should clear obstacles from this path rather than put up 
barriers along it.


The actual problems are:


Problem 1: Web search crawlers apparently do not index Fossil tickets very 
well: I just tried a few searches for closed tickets in one of my public repos 
which should turn up just that one ticket, and couldn’t find them.

The consequence is that answering support questions via the ticket tracker is 
effectively private 1:1 support, not the distributed one-to-many form that 
allows FOSS projects to function well despite scant tech support resources.

Solution: Ensure that the “All Tickets” report is always discoverable by a web 
spider, even if /ticket is somehow unlinked from the navbar.  Ensure that the 
report’s output is easily indexed.  It looks like Fossil does not generate 
robots.txt, so that shouldn’t be a reason for this.


Problem 2: Fossil currently only announces new tickets via /timeline[.rss], so 
that the only ones likely to answer questions are those paying attention to the 
repo’s timeline, which means the burden mainly falls on those doing the 
development.  In a healthy FOSS project, much of this burden is taken up by the 
community instead, relieving core developers of dealing with it.

Solution: Fossil.next should allow a logged-in user to subscribe to certain 
timeline events, including new tickets, but not limited to it.  Some will also 
want to get an email on every checkin, for example.


Problem 3: “Tickets” in the current skin navbars is vague, so people will 
frequently misinterpret its nature and proper use.  Also problematic would be 
terms like “Issues” or “Support.”

Alternate Solution 1: Split it into “Bugs” and “Wish List” by pointing to 
appropriate default ticket table reports.  The exact terms are not important.  
What is important is that the terminology carry intent: if you are not filing a 
bug report or expressing a wish (i.e. feature request), you should be posting 
elsewhere.  

If “Forums” precede these two links on the navbar, more people will tend to 
post there first unless they specifically know they have a bug to report or a 
wish to express.


Alternate solution 2: Fossil.next should create several default sub-forums, 
including Bug Reports, Feature Requests, and Support Requests.  The “Tickets” 
navbar link should be hidden from normal users.  Users with suitably high 
capability should be able to promote a forum post to a ticket tracker entry.

> I have a really long queue right now.  I need to
> spend several days (probably) working on SQLite.  I'll get back to
> this Fossil enhancement as I am able.  Thank you for your feedback -
> it is important.  I will deal with it as soon as I can.

The other web forum technologies have a long history, with a lot of development 
behind them.  Expectations will be high, so I would expect the wish list length 
to mainly increase for quite some time yet.

I think what you have already is close to a minimum viable product.  I’m not 
sure it’s yet ready to take over for the SQLite and Fossil project mailing 
lists, but for small projects like mine, it’s probably nearly good enough to 
start using soon.
___
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] About to merge the forum-v2 branch

[Warren Young]

On Aug 3, 2018, at 3:29 PM, Richie Adler  wrote:
> 
> El 03/08/2018 a las 11:13, Warren Young escribió:
> 
>> The vast majority of mail users *do* go out and specifically pull emails,
>> either via IMAP or by visiting a web mail interface of some kind.
> 
> Is there a reason why you exclude POP3 from the "pulling”?

Add it to the list and re-read the sentence.  Does doing so falsify the 
sentence’s first clause?

We could also include Exchange AciveSync, BBM, and MCI Mail in the list of 
email pull protocols.  Where do you want to stop?

My only point in that prior post is that email is rarely delivered directly to 
you, it’s usually pulled by the client making a connection out to some server 
first, which means Fossil Forums are working the same way.
___
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] About to merge the forum-v2 branch

[Warren Young]

On Aug 3, 2018, at 9:04 AM, Pietro Cerutti  wrote:
> 
> On Aug 03 2018, 14:13 UTC, Warren Young  wrote:
>> On Aug 2, 2018, at 2:57 AM, Pietro Cerutti  wrote:
>>> 
>>> The fundamental difference between email and web content, is that emails 
>>> are delivered to me
>> 
>> Only if you run your own SMTP server.
>> 
>> The vast majority of mail users *do* go out and specifically pull emails, 
>> either via IMAP or by visiting a web mail interface of some kind.
> 
> Don't take my words so strictly. Email are delivered to me, as in, to my 
> email client, be it a standalone executable or a web email interface.

Then in that same spirit, Fossil forums traffic is also delivered to you, 
either by

a) visiting the central Fossil instance; or

b) visiting a Fossil instance that’s kept sync’d with that central instance; or

c) subscribing to the Fossil repo’s RSS feed; or

d) signing up for email notifications, which according to drh will soon contain 
the whole message content, at least optionally.

>>> and once they are, they are mine.
>> 
>> If you want a copy of all of the Fossil Forum traffic, you can just sync the 
>> forum repo.  If you do it on the same schedule your mail client polls its 
>> IMAP server or whatever, then you have the data just as quickly.
> 
> The important point is of my sentence above is that *all* of my email is 
> delivered to that single place where I can organize it.

Do you subscribe to no other discussion forum than mailing lists?  Your 
information inputs are not already fragmented?  I’ve had at least two unrelated 
forum technologies to monitor at any given time since the late 1980s.

Fossil/SQLite isn’t the first mover in this slow exodus from email, not by a 
long shot.

Email was designed for a more civilized time on the Internet, when you could 
depend on things like ARPANet ToS agreements and local administration to solve 
problems.  

The current attempts to fix the email system’s problems are in part 
accelerating the exodus by making email software harder and harder to develop.

One of my biggest arguments against this Fossil Forums feature — which has been 
discussed for years now — was all the work it’s going to end up taking to 
support enough of the various email-related protocol standards to reach a 
suitably large fraction of the end users.  But, drh seems to feel it’s worth 
taking on, so I’m now going to support his efforts.

> I can easily follow tens of mailing lists, because of this centrality of the 
> delivered information.  Do you think your workflow is applicable to anybody 
> interested in following the discussions happening in more than 3 or 4 Fossil 
> forums?

Create a bookmark folder in your browser of choice for all of the web forums 
you want to visit periodically, put it on the browser’s bookmarks bar, and then 
on the same schedule you currently check your email, hit whatever 
keystroke/mouse gesture it takes to open that folder’s bookmarks all at once.

This is functionally little different than having an email client configured to 
sort mailing list traffic into separate local folders.

> While I don't doubt that a forum is a nice feature per se, I just think 
> moving Fossil mailing lists to a forum is going to make drh's life easier by 
> avoiding email spam at the cost of making anyone else's harder by 
> decentralizing where one goes and reads his daily batch of news and by 
> dismissing a well established way of interacting online.

Since it’s drh doing the work, I’d say his needs and wishes matter most.  FOSS 
is a do-ocracy: he who does the work makes the rules.

> Change is hard.

Yup, but I think the time to argue against this particular change is over.  The 
arguments were held over the past 2 or so years, both here and on the SQLite 
mailing list.

I’ve been on both sides of it, but now that it’s over, I don’t see any point in 
continuing the angst.  It is time to get through the new pains: development, 
debugging, and deployment!
___
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] [UI] Increase font size in side-by-side page?

[Warren Young]

On Aug 3, 2018, at 5:38 AM, Gilles  wrote:
> 
> Problem is, the font size is a bit small:

That’s because the default view is side-by-side.  Try clicking the Unified Diff 
link at the top of the Fossil UI diff view.
___
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] About to merge the forum-v2 branch

[Warren Young]

On Aug 2, 2018, at 2:57 AM, Pietro Cerutti  wrote:
> 
> The fundamental difference between email and web content, is that emails are 
> delivered to me

Only if you run your own SMTP server.  

The vast majority of mail users *do* go out and specifically pull emails, 
either via IMAP or by visiting a web mail interface of some kind.

> and once they are, they are mine.

If you want a copy of all of the Fossil Forum traffic, you can just sync the 
forum repo.  If you do it on the same schedule your mail client polls its IMAP 
server or whatever, then you have the data just as quickly.

Unlike most web forums, Fossil’s Merkle tree based storage mechanism means it’s 
very difficult to delete forum traffic from the server side before you get a 
copy.  IMAP doesn’t give you that: someone who can get to your mail server can 
delete mail traffic before it’s delivered to you.  Some people even call this a 
feature, calling it aggressive server-side spam filtering.

With Fossil forums, once you’ve sync’d the current content, nothing the server 
can do will make your local Fossil instance delete it.  In that respect, it is 
just as strong as IMAP.

> I can store them, move them around

You can store and move the Fossil forums repo around, too.

> modify them as I like to apply tags and labels

You can’t rewrite Fossil forum message content, but then I suspect you aren’t 
doing that to delivered mailing list traffic, either.

As for labeling and such, Fossil is DBMS-backed, with a flexible web front end. 
 The main limit on what you can make it do as far as mark-up and presentation 
of stored data goes is will and skill.

> They are easy to access (IMAP) from many different places and different 
> devices

Fossil can do that, too.  That’s a large part of what it means for something to 
be a DVCS.

> easy to search

Fossil forums are backed by the SQLite FTS feature.

> and standard.

SQL and RSS are standards, too. 

Unlike with most web forum software, Fossil forums will allow you to pull your 
raw data back out at will.

You could even build a Fossil forums to IMAP gateway, if you wanted.

> the location where I go and pull might change over time

I’m not quite sure what you mean here, so please confirm my guess: you mean 
that with mailing lists, you can unsubscribe with one email address and 
subscribe with another?

One big reason you might do that is because your old email address has been 
overrun by spam, which is a large reason why this feature is being added to 
Fossil in the first place: with Fossil forums, there is no publicly-visible 
email address for the spammers to harvest.

If instead you’re just observing that you change mail providers over time for 
other reasons, Fossil likewise doesn’t care which ISP you log into your account 
from to pull the data or post messages.

With auto-registration, Fossil will let you have multiple identities on the 
forum server, either serially or concurrently.

> And content itself might change over time (although this doesn't often happen 
> in fossil).

Once a mailing list message is sent to your SMTP server, it is difficult for 
someone to change it, except in cases like my aggressive server-side filtering 
example above.

Fossil falls on both sides of that line.

On the one side of the line, it allows a posted message to be edited, just like 
a Fossil wiki article: the original version is always available, but mistakes 
can be fixed in the window between someone posting a message and others viewing 
it, reducing needless followup posts, confusion, and (yes!) loss of face.

On the other, Fossil’s strong Merkle tree design means that it takes 
cooperative effort from all parties to actually modify or remove data from the 
repository.  The edits I just spoke of don’t actually change old content, the 
new content is just substituted for the old content at the UI level only.

> Devise a mechanism to allow replying to such an email and sync it with the 
> forum

…and now you’ve got spammers again, which defeats a large part of the purpose 
of creating this new feature set.
___
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] [fossil-dev] About to merge the forum-v2 branch

[Warren Young]

On Aug 1, 2018, at 3:43 PM, John P. Rouillard  wrote:
> 
> In message <23ebb036-9e71-4e02-b496-1361e3852...@etr-usa.com>,
> Warren Young writes:
>> On Jul 31, 2018, at 7:47 AM, Richard Hipp  wrote:
>>> 
>>> The intent is to replace this mailing list
>> 
>> Are you also going to import all the old content, so that people can
>> clone the forum repo — assuming you still plan to keep the forum and
>> code as separate repos — and get a locally-searchable archive?
> 
> According to the comment above

Not according to me, but to drh:

https://fossil-scm.org/forumtest1/forumpost/9b6f3f36bdb

> I must have missed that if it was stated.

The current forumtest1 contents are currently small enough to read 
front-to-back in 15 minutes or so. ;)

> Since I clone the fossil repo to my RasPI I am really not interested
> in cloning the forum/mailing list along with the source code.

If you won’t use the mailing list archive, fine, I have no particular wish to 
force you to clone it.  

However, when weighing your wishes, we must keep the costs in perspective: 
According to that same post, we’re only talking about 35 MB or so of data.

The Raspbian Desktop SD card image is currently about 4.8 GB unpacked, so with 
the smallest-possible 8 GB card, a SQLite mailing list archive clone is small 
enough to rattle around in the free space like a BB in a milk jug.

If you’re using Raspbian Lite, you can install on a card as small as 2 GB, and 
you’ll have enough space left over for some development tools, Fossil, and 
several repository clones, including those of the Fossil and SQLite mailing 
lists.

What I’m saying here is, give me a use case where 35 MB actually matters here 
in 2018.

I can give one: those behind SQLite and Fossil might not want to pay the higher 
bandwidth bills resulting from a repository that’s 35+ MB larger.  At their 
scale, it might actually matter, and in that case, they should calve it off as 
a separate repository so that only those that actually want to make use of it 
will bother to clone it.  (I do, and I will, if allowed.)

Here’s a thought for you: how many old forums (generic definition) have you 
been part of in the past that have since disappeared, taking their archives 
with them into oblivion?  Wouldn’t you like to have a copy of some of that?  
For me, the answers are “dozens,” and “yes”.  The Fossil Forums Feature gives 
us that, finally.

> I throw away 99+% of the traffic on the mailing list after reading
> it.

You also probably ignore 99+% of past software versions, 99+% of past checkin 
comments, 99+% of old wiki content…  The thing a VCS should provide is access 
to the odd 0.01% of past artifacts that you can’t identify in advance of need.

If I’m writing a new ticket for a bug that was discussed on the mailing list 
months ago, I’d sure rather refer to it using a link to a forum post in the 
same repository than to some third-party mail archive service that has a fair 
chance of changing their URL scheme or even going out of business before the 
ticket is closed.

> A method that allows syncing without forum artifacts or a command to
> purge forum artifacts would be helpful.

A method to get some kind of thinned-out clone has been a longstanding wish.

I think the main problem is that it’s a lot of difficulty for a fairly uncommon 
use case.  Most of the time for most projects — including, critically, SQLite 
and Fossil-SCM.org — a full clone is cheap enough that it just isn’t worth 
doing the work.
___
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] [fossil-dev] About to merge the forum-v2 branch

[Warren Young]

On Jul 31, 2018, at 7:47 AM, Richard Hipp  wrote:
> 
> The intent is to replace this mailing list

Are you also going to import all the old content, so that people can clone the 
forum repo — assuming you still plan to keep the forum and code as separate 
repos — and get a locally-searchable archive?

Currently, I keep all mailing list content locally, which is occasionally 
helpful.  Web searches often fail to turn up conversations I *know* exist, 
which I can find simply by telling my mail client to search within a given mail 
folder.  This is especially common with projects that have lots of web search 
conflicts, like “Fossil”.

This also argues against those who say that local mailing list archives are too 
big or slow things down.  It’s been many years since mail clients couldn’t 
handle many years of a typical FOSS project mailing list content, and it’s been 
many years more than that where I even noticed the disk space it requires.

If bandwidth is a concern, the DVCS nature of Fossil should allow us to 
trivially set up a mirror network.  You just need to link to a bunch of people 
who’ve stood their ML repo clones up on public servers.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Is abort() necessary in fossil_panic()?

[Warren Young]

Checkin [81632289] on the forum-v2 branch changed a call to exit(1) in 
fossil_panic() to call abort() instead, which causes SIGABRT on POSIX type 
systems, which in turn causes Fossil to dump core if that’s configured on the 
system.  I’m a developer, so core dumps are enabled on my private Fossil 
servers.  (Not on public ones to avoid an easy disk-filling DoS attack.)

I suspect that dumping core is so rarely helpful in most of the 112 cases where 
fossil_panic() is currently called in src/* that attaching a debugger is a 
better plan in those rare cases where something like a backtrace is needed.

I discovered this when running “fossil init” without arguments to get a help 
message.  This makes me wonder how many of those 111 other code paths are going 
to drop cores for insufficient cause.

I think it’s appropriate for a function called “panic” to drop core.  What I’m 
questioning is that Fossil really has 112 cases where dropping core on exit is 
the best plan.  If all of these can’t move to fossil_fatal() calls, then I 
guess we need a third “scream and die” function that splits the difference 
between these two.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Logout/PW/Email UX fix

[Warren Young]

It's long bothered me that Fossil puts the password change feature on the 
"Logout" screen, and that clicking "Logout" doesn't actually log you out.  This 
is not discoverable other than by accident.

What’s brought this issue to a head for me is the new forum feature, where now 
we also have the Email Alerts link on this page as well, which also has nothing 
to do with logging out.

I propose that

$USERNAME  Logout

change to 

$USERNAME

and that this page simply be the user settings page.

I’d then like to see /login change to something more generic like /user.  If 
someone depends on the existing name as an API, a /login alias could be added, 
either in code or via the existing URL aliasing feature.

While logged out, `$USERNAME` in the second bit of HTML above can change to 
`Log In`.
___
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] Delay with `fossil ui' (related to backoffice processing?)

[Warren Young]

On Jul 22, 2018, at 4:21 AM, Florian Balmer  wrote:
> 
> writing to a FILE* pointing to NULL may have
> exactly the same effect as writing to a FILE* pointing to "/dev/null”?

You can open a file called NUL on Windows to get the same effect as /dev/null 
on POSIX type platforms.

Unlike on POSIX, NUL is just a special-cased file name, not the name of an 
actual device, so it’s possible to get around it with NTFS file path trickery:

https://superuser.com/questions/282194/

That’s no concern here, since the Fossil code will likely just say "NUL".
___
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] Delay with `fossil ui' (related to backoffice processing?)

[Warren Young]

On Jul 22, 2018, at 1:18 AM, Florian Balmer  wrote:
> 
> [5544931c] src/backoffice.c:240

That’s brand new code, less than a week old.  It’s not surprising it’s not 
rock-solid yet.

I expect drh is now on the case. :)
___
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] Delay with `fossil ui' (related to backoffice processing?)

[Warren Young]

On Jul 21, 2018, at 11:48 AM, Florian Balmer  wrote:
> 
> I've noticed something with the current tip version of Fossil…

> I tried to find a "last good" version by means of "bisecting", but…the delay 
> never appears with Fossil 2.6.

I can see only two ways for those two sentences to be true at once, but it’s 
unclear which is the case from the way you phrased it:

1. The tip of trunk and *only* the tip of trunk exhibits the problem behavior.

2. Every checkin after 2.6 exhibits it.

Which is it?

If the problem first appeared with [76800769], the fix drh checked in to clean 
up the dangling journal files you were reporting, then I wonder if the delay is 
waiting out some SQLite lock.

Windows’ native locking behavior is much more restrictive than the default on 
pretty much every other platform, so I wonder if the new shutdown code path 
created a temporary deadlock that gets broken by a SQLite timeout.

Try backing that checkin out to see if the prior problem (dangling journal 
files) reappears, while the delay also goes away:

fossil up trunk # back out from the bisect
fossil revert   # just to be sure
fossil merge --backout 76800769

Then build and test.
___
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] Backup traffic

[Warren Young]

On Jul 20, 2018, at 3:32 PM, John P. Rouillard  wrote:
> 
> Does a clone/sync grab passwords and user accounts as well? I thought those
> weren't copied in the clone but were private to the repository.

You get a copy of the users table *if* you clone while logged in with a user 
with Setup privileges.  It might also work with Admin, but I haven’t checked.

Otherwise, you’re right: Fossil strips the user table contents while cloning, 
on purpose.
___
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] Backup traffic

[Warren Young]

On Jul 20, 2018, at 5:04 AM, Richard Hipp  wrote:
> 
> create your backups by cloning and syncing

…with Admin privileges.  Otherwise, you won’t get important things like the 
user table.  After the first clone, each backup should consist of both a 
“fossil sync” as well as a “fossil conf pull all”.

While you can recreate the user *list* from Fossil checkin contents and then 
recreate the users table and do whatever dance it is you do to pass out user 
passwords and get them changed to something secure, it’s better to just back 
all that up to begin with.
___
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] Backup traffic

[Warren Young]

On Jul 20, 2018, at 2:12 AM, Florian Balmer  wrote:
> 
> There's a lot of backup traffic

Quantify “a lot.”  

Do you have benchmark numbers showing that the current load is too high, and 
that your wished-for changes will reduce load to acceptable levels?

> (This was also the main reason for my complaining about the leftover
> WAL and SHM files, recently, which accumulated in my backup logs.
> Because in the end, WAL and SHM have to be kept together with the
> SQLite database, as they might contain valuable information?)

The greater concern is that if these files are present after all clients have 
disconnected from the DB, it means you’ve got a DB client that is dying without 
closing the DB properly.  That’s a problem in its own right, but it might also 
mean that the last transaction run might not have hit the journal before the 
program died, so it’s effectively rolled back upon replay of the journal.

Rather than worry over the resulting WAL size, I’d find out why the DB client 
is dying early and fix that, so that the WAL ends up being deleted entirely 
upon a clean DB shutdown.

> From peeking at the Fossil timeline, my question is, will the new
> "backoffice processing" cause even more frequent updates to the main
> repository database, i.e. with the pids stored in the configuration
> table, and updated after each web page display?

How many checkins, syncs, etc. do you have per day?

I find it odd that some people get so itchy over DB concurrency and such with 
Fossil when highly active projects might have 40 or so commits per day.  
Amortized evenly over an 8-hour work day, that’s only one every 12 minutes.  
With real-world bursty traffic, there’s still an excellent chance that on every 
DB update, there is no write contention at all.

> Does anybody care about the repository
> database, holding all your valuable contents, being modified
> frequently with simple non-contents state information?

If I didn’t trust it to withstand that, I wouldn’t trust it to hold my unique 
work products, either.
___
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] OT: security/entropy (was Re: New Fossil user experiences)

[Warren Young]

On Jul 15, 2018, at 8:47 AM, Joerg Sonnenberger  wrote:
> 
> On Sat, Jul 14, 2018 at 05:24:26PM -0600, Warren Young wrote:
>> On Jul 14, 2018, at 2:18 PM, Joerg Sonnenberger  wrote:
>>> 
>>> On Fri, Jul 13, 2018 at 03:27:14PM -0600, Warren Young wrote:
>>>> 
>>>> For example, 100 a’s requires a 7-bit run-length plus zero bits for our
>>>> only code point
>>> 
>>> You need more than zero bits to encode the original a though.
>> 
>> There’s only one letter in this alphabet, so all we need is a run length
>> to say how many of them there are in our message.
> 
> You are kind of making my point for me. You are adding a priori
> knowledge of a single letter alphabet in a context where this assumption
> makes no natural sense. By that line of reasoning, you can also assume
> knowledge that passwords are always a multiple of size n and the entropy
> would be near zero…

I’m taking inspiration from Huffman coding here, so you actually need 7 bits 
for the length prefix + sizeof(dictionary_with_one_entry).
___
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] Fossil in a chroot jail. Was: Chiselapp status

[Warren Young]

On Jul 13, 2018, at 8:58 PM, Warren Young  wrote:
> 
> On Jul 13, 2018, at 7:09 PM, Richard Hipp  wrote:
>> 
>> So, if you want to use the rate limiting feature on
>> Linux, you will need /proc mounted in your chroot jail.  I wish there
>> were a better way…
> 
> That’s actually one of the older features of cgroups.  Maybe take a look?

Reference: 
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/sec-cpu

This isn’t quite the same thing as your current system, which cuts off service 
entirely when the load is high, but I think it’s more useful: allow a single 
process to use the whole CPU, but when there’s competition for the CPU, limit 
each one to a specific amount as needed to give each cgroup-controlled process 
a predetermined minimum slice.

This part of cgroups was created specifically for the sorts of purpose you’re 
interested in: preventing one process from hogging the system when there are 
many non-cooperating processes running on the same hardware, as with 
multi-tenant VM hosting.
___
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] OT: security/entropy (was Re: New Fossil user experiences)

[Warren Young]

On Jul 14, 2018, at 2:18 PM, Joerg Sonnenberger  wrote:
> 
> On Fri, Jul 13, 2018 at 03:27:14PM -0600, Warren Young wrote:
>> 
>> For example, 100 a’s requires a 7-bit run-length plus zero bits for our
>> only code point
> 
> You need more than zero bits to encode the original a though.

There’s only one letter in this alphabet, so all we need is a run length to say 
how many of them there are in our message.

Another way to look at it is that a bit encodes one of two states, but we only 
have one state in this example, so we don’t need a whole bit to encode it.

If the example were a’s or no-a’s, then you’d have two states, and thus need to 
encode it with bits.  But materially, that’s no different from an a’s or b’s 
system, which also requires one bit per state.
___
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] Fossil in a chroot jail. Was: Chiselapp status

[Warren Young]

On Jul 13, 2018, at 7:09 PM, Richard Hipp  wrote:
> 
> So, if you want to use the rate limiting feature on
> Linux, you will need /proc mounted in your chroot jail.  I wish there
> were a better way…

That’s actually one of the older features of cgroups.  Maybe take a look?
___
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] OT: security/entropy (was Re: New Fossil user experiences)

[Warren Young]

On Jul 13, 2018, at 3:13 PM, Warren Young  wrote:
> 
> 2. Add a dollar sign to the message, and bpc goes up a bit.  (This conflicts 
> with your report that adding a special character didn’t change it, but it did 
> for me.)

I just realized where the discrepancy comes from: you *replaced* one character 
of the original message with a special character, so the resulting alphabet 
size didn’t change, whereas I *added* a non-alphanumeric character to the 
message, which did change my alphabet size.

This calculator doesn’t know about “special characters,” all it knows about are 
the number of unique input symbols it is given and how that relates to the 
total message size.
___
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] OT: security/entropy (was Re: New Fossil user experiences)

[Warren Young]

On Jul 13, 2018, at 3:13 PM, Warren Young  wrote:
> 
> Now paste in an equivalent number of ‘a’ characters, and you get 0 bits of 
> entropy.  Strictly speaking, you get 1 bit of entropy for the whole message, 
> but it shows 0 because the calculator is rounding the result off to 3 
> significant figures.

Hmmm…we also need something like a run-length prefix to reconstruct the 
message, so this calculator is undershooting slightly.

For example, 100 a’s requires a 7-bit run-length plus zero bits for our only 
code point, so we should get 0.07 bpc, within this calculator’s apparent 
precision even without dealing with roundoff errors.

Still, it’s good enough for our purposes here, which is to make it clear to us 
that if you use a hex string as a passphrase, you need 128 characters of it to 
fully justify the use of 256-bit symmetric encryption.
___
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] OT: security/entropy (was Re: New Fossil user experiences)

[Warren Young]

On Jul 13, 2018, at 2:22 PM, David Mason  wrote:
> 
> Acgq75VpCWjdsJaa5abe9JeX3I (don't worry, this isn't a real password to 
> anything)
> 
> …I fed this through an online entropy calculator and got 4.29 bits of Shannon 
> entropy

That calculator is giving you bits *per character*.

You can see this several ways:

1. Double the message and the bits per character doesn’t change because the 
size of the source alphabet doesn’t change.

2. Add a dollar sign to the message, and bpc goes up a bit.  (This conflicts 
with your report that adding a special character didn’t change it, but it did 
for me.)

3. Turn on the calculator’s case folding option and the bpc value goes down a 
bit.

One key realization you should get from this calculator is that ASCII text is 
not 7 or 8 bits of entropy per character.  It simply is not, because not all 
characters in the source text are equally likely.  Many code points may never 
be used in a given corpus.

Another realization is that a random blob of hex noise should asymptotically 
approach 4 bpc, since each character is 4 bits of data, and the data are 
supposed to be evenly distributed across the code space.

Here’s some noise from grc.com/pass:

C79683189EFBEBEC30A4C1A6D733F0242FB48E2582F3B2E7581D85E91E0A2FA5

The initial value is 3.91, and pasting it in a bunch of times does increase the 
value towards 4, suggesting it’s got pretty good entropy.

Now paste in an equivalent number of ‘a’ characters, and you get 0 bits of 
entropy.  Strictly speaking, you get 1 bit of entropy for the whole message, 
but it shows 0 because the calculator is rounding the result off to 3 
significant figures.

> So I tried:
> dd if=/dev/random bs=100 count=1|od -c
> and the result only gave 5.00 bits

That’s plausible.  With a much larger sample, the result should approach 7, 8, 
16, or 21, depending on your local character set size.  (Respectively: pure 
ASCII, ISO 8859 or similar, UCS-2 and full Unicode.)

Now see if you can guess the asymptotic ideal for this slightly different 
command:

$ dd if=/dev/random bs=100 count=1 | od


Spoiler below.




















………..












3, because the output is restricted to octal, thus 3 bpc.
___
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] Chiselapp status

[Warren Young]

On Jul 13, 2018, at 2:13 PM, Roy Keene  wrote:
> 
> Upgrading from Fossil 2.1 to something more recent hasn't been a priority;  I 
> have to go through the versions and verify no new features will cause 
> problems when hosting untrusted repositories, and I haven't done that.

I guess you’re worried about CSRF, XSS and such?

There was an XSS fix in 2.3, and there’s one still pending for the current 
release.  I didn’t pay attention to who noticed these problems and wanted these 
fixes, but if you’d asked me yesterday, I’d have guessed Chiselapp!

> If you would like to volunteer to do that then it'll go faster !  :-D

Would it be easier to switch to a technology like BSD jails or Illumos zones 
that let you run a separate Fossil instance for each customer, so that you 
don’t have to worry about how multiple customers’ Fossil instances will 
interact?

With Fossil’s option of a single statically-linked executable, you might end up 
with only a handful of files in each container, so that the attack surface is 
little more than Fossil itself, and if exploited, all you get access to is the 
repository data within that single container.

cgroups based containers on Linux (e.g. Docker, though not limited to it) are 
reportedly not as strong as BSD jails or Illumos zones:

https://unix.stackexchange.com/questions/127001/linux-lxc-vs-freebsd-jail


https://www.blackhat.com/docs/eu-15/materials/eu-15-Bettini-Vulnerability-Exploitation-In-Docker-Container-Environments-wp.pdf


https://www.reddit.com/r/IAmA/comments/31ny87/i_am_the_cto_of_joyent_the_father_of_dtrace_and/cq414ac

Yet, they may be strong enough for this purpose, given its tight scoping.

chroot() might even be strong enough given the tight scoping.  None of the ways 
I’m aware of to escape a chroot() apply to a minimal Fossil-in-a-box 
configuration.  Most of these methods require root access inside the chroot, 
and there isn’t cause for that, not even for low-numbered port binding, since 
your HTTPS front end could map external URLs to high-numbered internal port 
numbers.
___
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] New Fossil user experiences

[Warren Young]

On Jul 13, 2018, at 9:39 AM, Andy Goth  wrote:
> 
> On 07/11/18 16:10, Warren Young wrote:
>> On Jul 10, 2018, at 8:58 PM, Andy Goth  wrote:
>>> I thought it interesting that he spoke of merging as if it were a
>>> distinct task in the workflow for adding a file.
>> Did he check the file in on a branch and then merge it down to trunk?
> 
> No he did not, but after reading my email to this list, he told me he said 
> merge because his git habit is to always work on a branch.  I took that as an 
> opening to discuss the difference between git and Fossil branches.

In my public Fossil projects, the policy is that any checkin that is 
potentially destabilizing should be done on a branch, as should any coherent 
line of work that will require multiple checkins to complete.  Trunk is ideally 
stable at all times, so as long as a checkin is self-contained and trunk 
remains as stable as before, direct checkins to trunk are fine.

The rule requiring multiple-checkin lines of work to be on a branch doesn’t 
apply if each step along the way is self-contained and doesn’t destabilize 
trunk.  So for example, work on a new script that requires multiple checkins 
can be done directly on the trunk as long as that script isn’t called by 
something other developers run frequently, such as the build system.

This is an ideal not always achieved, but since there are consequences to not 
achieving it, over time developers on the project learn to be thoughtful about 
checking in directly to trunk.

As a result of this policy, a new developer’s first checkin might well be on a 
branch, either because they’re going off on a new development tangent that will 
take them multiple checkins to finish, or because they’re still feeling 
tentative about their work, so they want one of the old hands to okay it before 
merging it to trunk.

>> once publicized, a URL should never die
> 
> our project is private

In that case, I think it’s perfectly fine to delete these docs unceremoniously, 
as needed.

> Only the front page and the wiki are public, and I've been migrating most of 
> our wiki stuff to the private areas because in my opinion it gives away too 
> much secret sauce.  Probably not worth shunning wiki history though.

Until one of the publicly-hosted “private” repository services is designed to 
and audited at the same level we use for VPNs, I’m unwilling to trust any of 
them.

If your codeveloper is remote from you, I recommend that you relieve Fossil of 
the burden of providing the capital-S security for your project, laying that 
off on SSH or some VPN technology you trust instead.

I’m not a black hat, so I haven’t tried to break Fossil’s permission system, 
but I only depend on it about as much as a door lock: it’s a thing to prevent 
civilized users from doing things we’d rather they not do.  If I decide that a 
Fossil repository’s contents shouldn’t be visible to the public, I don’t put it 
on a publicly-accessible server, period.

If you want to treat Fossil as a CMS for your public web site, I’d run it as a 
separate instance, with only those things you’re willing to publicize going out 
to it.

For off-site backups of private repositories, I use the attached script.  
Technically it violates my rule not to put private data on publicly-accessible 
servers, but I trust AES, gpg, and my key to turn that repository data into a 
blob of useless noise to anyone without the key.

There are several things you need to adjust in the script to use it:

1. The “pass” value on line 3.  I use a generated random blob, but it could be 
a passphrase or similar.  If it’s short enough to be called a password, run it 
through an entropy calculator: if your password gives less than 256 bits of 
entropy, you’re artificially weakening the encryption.

2. The repository list used in the “for” loop.

3. The “bdir” output directory.  It could be something like ~/Dropbox/Fossils, 
or it could be a directory sync’d elsewhere by a command that you append to the 
script.

I’ve come to this position not out of specific distrust over Fossil’s security 
design, but out of deep respect for what the ‘hats can do once they’re feeling 
motivated to attack something.  SSH, VPNs, GPG, and AES have all been pounded 
on by the ‘hats sufficiently long and hard that I trust those technologies 
implicitly, as long as the best practices are followed.  

Since Fossil hasn’t attracted that sort of attention yet, I feel that my idea 
of “best practice” for Fossil security is just my opinion and worth only as 
much as that realization implies.

While I’m pontificating on paranoia, I’ll say that a VPN is only a VPN if it is 
truly private.  Technologies which fail to provide the “P” are not VPNs.  
Hence, PPTP is not a VPN, in my view:

   https://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol#Security

> I'll have to leave it to him to make his own macOS binary

Here’s the current 

Re: [fossil-users] /usr/bin/ld: cannot find -ldl

[Warren Young]

On Jul 12, 2018, at 4:23 PM, Warren Young  wrote:
> 
> cc-check-function-in-lib dlopen dl
> cc-check-function-in-lib iconv iconv
> cc-check-function-in-lib inflateEnd z
> cc-check-function-in-lib gethostbyname nsl
> cc-check-function-in-lib ns_name_uncompress resolv
> cc-check-function-in-lib sqlite3_open sqlite3 $extralibs
> cc-check-function-in-lib dlopen dl 

Copy-paste bug: remove the second dlopen(2) check.  It should be checked early, 
because many other libraries use this syscall.

The networking stuff is after the core syscall checks, but before any libraries 
that do networking, etc.

The order of the libnsl and libresolv checks might need to be swapped, but I 
think I’ve got it right as shown.
___
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] /usr/bin/ld: cannot find -ldl

[Warren Young]

On Jul 12, 2018, at 4:06 PM, Richard Hipp  wrote:
> 
> On 7/12/18, Jungle Boogie  wrote:
>> 
>> openBSD -current x64
> 
> I don't have access to such a system for debugging purposes.  Can you
> suggest a patch?

I’d suggest revisiting the decision to replace cc-check-function-in-lib with 
the custom check-function-in-lib variant.  The logic behind it seems suspect: 
you *want* it to modify LIBS because you order the calls to the function in 
leaf-to-root order.

That is, the checks should be ordered so:

cc-check-function-in-lib dlopen dl
cc-check-function-in-lib iconv iconv
cc-check-function-in-lib inflateEnd z
cc-check-function-in-lib gethostbyname nsl
cc-check-function-in-lib ns_name_uncompress resolv
cc-check-function-in-lib sqlite3_open sqlite3 $extralibs
cc-check-function-in-lib dlopen dl 

That call list is based on the current contents of auto.def, but consider it 
pseudocode, not a patch, intended just to show the pattern: the most 
depended-upon library is checked for first, because it may be needed to link 
one or more of those that follow, especially on non-Linux systems which usually 
have linkers that won’t chase dependencies for you automatically.

The stock version of cc-check-function-in-lib *prepends* each subsequent 
library for this very reason: so that the first-checked library ends up at the 
*end* of LIBS.
___
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] New Fossil user experiences

[Warren Young]

On Jul 10, 2018, at 8:58 PM, Andy Goth  wrote:
> 
> "Got fossil ui working.  Added, merged and committed website_design.md."  I 
> thought it interesting that he spoke of merging as if it were a distinct task 
> in the workflow for adding a file.

Did he check the file in on a branch and then merge it down to trunk?

> “...I'm reading the best practice for fossil is to leave the deprecated .md 
> in place?"  I'm not sure where he got the idea that it's best to not delete 
> files

It’s not Fossil-specific at all: once publicized, a URL should never die, else 
you get broken links, if only from web crawlers that saw that document once 
upon a time and then continue to return it in search results.

There are several embedded documentation files in both the Fossil and SQLite 
project repositories that are deprecated, presumably for this reason.

It’s arguable whether this rule applies to your codeveloper, because page 
lifetime also plays into it.  It sounds like the file was only available for 
minutes, and then on a “young” site with very few outside people looking at it, 
if any at all.  So, who could possibly have even known the URL was valid, much 
less cached it semi-permanently?

> “People don't much like this behavior, but it's what we have, and it can be 
> changed.”

Did you make it clear that “it can be changed” means your codeveloper can 
change it on his end, as opposed to waiting for someone to get around to 
changing Fossil for him?

Two weeks ago, Fossil trunk was changed so that you no longer need to 
reconfigure Fossil’s checkout tree to enable this:

http://fossil-scm.org/index.html/info/27e5e5ce65262f5a

That is, the mv-rm-files option is now present in all Fossil builds.  It is 
just not enabled by default.

> Regarding fossil changes, he said, "If I get a carriage return/new line with 
> no prompt, does that mean there are no changes to apply?"  So there seems to 
> be a bit of confusion, or at least hesitancy, about fossil changes (probably 
> also fossil extras) printing nothing.

That’s not a Fossil issue, it’s a Unix vs Windows issue: traditionally-designed 
Unix programs often do their work silently if no problem occurs and there is 
nothing to tell the user.

This design choice is part of Unix’s focus on the shell as a programming 
environment, rather than as a thing to type commands at interactively.  DOS 
never developed this tradition of scripting commands and interpreting stdout 
and stderr, so Windows inherited that, and thus Windows programs tend to 
blabber.

Compare the operation of Unix cp vs DOS COPY, for example.

Fossil comes out of the Unix tradition, so Fossil only writes output when it 
has something important to tell you, or you asked it to tell you something.

> fossil sync website_design.md

That the sync command stores the given URL blindly here seems like a UX bug to 
me.  Just as Fossil re-prompts for a password until it gets one that works, it 
should not store the URL until it successfully uses the given one to sync the 
local repo.

> This was easily fixed with fossil remote-url.

I’d have told your codeveloper to use “fossil sync URL” here instead, so he 
could compare and contrast the incorrect and correct forms of the command.

By giving him a different command to back out, he may now be afraid to use 
“fossil sync” entirely.

> the default of not deleting the file from disk is confusing to new users.

Yes, well, the argument’s been had for years here.  I take the recent change on 
Fossil trunk as a sign that *eventually* the default will change.  We shall wee.
___
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] branch assistance needed

[Warren Young]

On Jul 5, 2018, at 12:22 PM, Nicola  wrote:
> 
> moving check-ins between branches is implemented by simply renaming tags.

It’s better to say that you can move a checkin *and all of its children* by 
adding/changing a propagating tag to that checkin.  In Fossil UI, this is the 
"Make this check-in the start of a new branch named:” option.

You cannot take a checkin with children and move just that one checkin to 
another branch with a single tag manipulation.  For such tasks, we have to fall 
back on “fossil merge --cherrypick”.

Furthermore, you can’t merge checkins from one branch into another solely by 
messing with the tags on a checkin, whether plain-old tags as I think the OP 
was doing or the self-propagating tags that are the basis of Fossil’s branching 
system.

Here’s my best-effort attempt at recreating what the OP described:

https://imgur.com/a/6S4Y1nw

You either end up with two trunk branches or a single branch plus a checkin off 
the trunk branch that also happens to be tagged “trunk”.

I suspect what drh meant up-thread about an easier method in Fossil UI to fix 
this is that you should be able to straighten out a tangle in the timeline by 
re-applying propagating tags to the root of the branches to disentangle them.  
I agree that such tools are too rarely needed to be worth spending time on.  We 
have alternate tarpit escape methods that work well enough already.
___
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] branch assistance needed

[Warren Young]

On Jul 4, 2018, at 9:50 AM, Dewey Hylton  wrote:
> 
> The solution ended up being much less messy than I anticipated

Yes; while Fossil will let you create awful messes, this is mitigated by 
several design choices:

1. It’s really hard to make Fossil actually lose data.  It can be done, but it 
takes enough effort that you’re highly unlikely to do it by accident.

2. If you have a mess with no data loss, recovery within the existing 
repository is usually simple enough that restoring from a backup copy and 
replaying your work is almost never the best option.

3. Once bitten this way, the reason why you were bitten and the right way to 
avoid it is usually clear.  Contrast  other systems where you can be 
told how you screwed up and how to fix it and still be at risk of doing it 
again because the right way doesn’t “click”.

> This is a great community.

Fossil is worth fighting for.

___
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] branch assistance needed

[Warren Young]

On Jul 3, 2018, at 3:09 PM, Dewey Hylton  wrote:
> 
> Essentially what I did was to commit a change to a new branch, forget I was 
> in that branch and committed another unrelated change which should have gone 
> back to trunk but went into the branch.

That’s no big problem so far.  I’ve done it myself, probably more than once.

The right way to fix it at this point would be to cherrypick the changes that 
should have been on trunk from the branch onto trunk:

   $ fossil up trunk
   $ fossil merge --cherrypick abcd1234  …etc
   $ [test]
   $ fossil ci
   $ fossil up my-new-branch

At that point, what you have is effectively as if you’d done this instead:

   $ fossil up trunk
   $ [hack, hack]
   $ fossil ci
   $ fossil up my-new-branch
   $ fossil merge trunk

So, it’s an easy cleanup.

> I then attempted to change that latest commit by adding a 'trunk' tag and 
> cancelling the new branch tag.

Ow!

> I'm pretty sure that was wrong, but I'm unsure now where to go with this.

Cleanup is similar to the above, it just creates an uglier timeline:

$ fossil up trunk
$ fossil merge --integrate my-new-branch
$ [test]
$ fossil ci
$ fossil merge --backout abcd1234  # ID of first checkin on 
my-new-branch
$ [test]
$ fossil ci
$ fossil merge --cherrypick abcd1234
$ fossil ci my-new-branch

You might have to give a checkin ID in the first command instead of a branch 
name if it isn’t putting you in the timeline where you think you ought to be.  
Fossil might even complain about having two “trunk” branch tips with this 
command; if so, the solution is the same.

It’s okay to give the same branch name in the last command as you used 
originally because Fossil just uses branch names as auto-propagating labels.  
Checkin IDs and their relationships are what matters to Fossil, not branch 
names.  Still, you might prefer to give it a different name to avoid causing 
yourself confusion, even though Fossil isn’t confused at all.
___
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] [minor] src/style.c:427 → "%

[Warren Young]

On Jul 2, 2018, at 9:38 PM, David Mason  wrote:
> 
> It's pretty common to put classes on  tags, to use CSS to conditionally 
> choose different renderings by simply changing the class of the body tag.

I think you’d have to write TH1 code to get Fossil to serve more than one 
 tag on a given repository.

That then makes me wonder if that would be another way to trick Fossil into 
serving a second  tag.  Consider this pseudocode:


   return [concat ""]


I say “pseudocode” because it’s probably horrid Tcl style, if it compiles at 
all.  I speak only pidgin Tcl these days.
___
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] [minor] src/style.c:427 → "%

[Warren Young]

On Jul 2, 2018, at 8:11 AM, mario  wrote:
> 
> This misses anything but plain  tags in the header
> ↓
>  if( sqlite3_strlike("%%", zHeader, 0)!=0 ){
>Th_Render(zDfltHeader);
>  }
> 
> It might rather be %%, so any style attributes
> like  get recognized still.

Under what conditions would you have two different  tags in a single 
document differing only by class, and thus need a CSS selector to differentiate 
them?

I suspect this is just a bad example, but then I ask myself, if I’m going to 
apply CSS styles to a tag, wouldn’t I just put it into the CSS file, which I 
can already modify without changing Fossil?

What’s the real motivation here?

> I see the value in the draft feature, but it's
> also a bit confusing still (while working on broken skins at least.)

While I agree that the new skin editor is considerably more complicated to use 
than the pre-2.5 method, I also don’t see how to make it simpler without losing 
functionality we gained in that release.

This feature set solves a few real problems faced by drh during the 2.5 
development sequence in support of the many UI improvements he made while 
actively soliciting feedback on those changes.  In order to get that feedback, 
he had to point people to a running instance, so rather than take the expense 
and complication of setting up a public demo server, drh created this feature 
set so he could demonstrate proposed skin changes using the fossil-scm.org 
instance to get that feedback.

This feature set adds the following abilities:

1. Lets normal site visitors A/B compare proposed changes by visiting URLs 
differing only in the skin draft’s name.

2. The Fossil admin user can now invite others to edit the skin.

3. Edits can be made to drafts, so you can test on a production server without 
breaking it for uninterested users.

The prior way skin editing worked, only the admin user could switch and edit 
skins.

I don’t think you’re going to see any changes to this mechanism unless your 
proposal can achieve the same ends.

> - draftN… just treated as saved skins?

I don’t see why that couldn’t be done in principle.

The main practical problem is that skins can be named in a way that would 
require ugly URL escaping to be specified in place of the current draftN bit:

https://fossil.example.com/Blitz%2C%20No%20Logo%20(built-in)/home

A secondary problem is that it appears that Fossil’s current URL parser can’t 
quite cope with that once decoded, based on the 404 error pages it generates.

There is a side-benefit of this change: if someone has a public Fossil instance 
and one of the end users thinks the default skin is ugly, he can change it by 
selecting the name of a skin he likes better in the URL.  Currently, you can 
only change the skin this way in a local clone which you’re running “fossil ui” 
on.

> - edit header/footer/css buttons for each draft/skin

I’m not seeing the value of that change.  The current mechanism is:

1. Select the skin/draft to edit.

2. Click the CSS/Header/Footer/Details edit links.

Are you proposing to replace this with a grid, with skin names down the left 
edge and 4 edit buttons per row to the right of each skin name?  That does not 
sound like a simplification to me.

If you have something different in mind, a graphical mockup or wireframe 
drawing might help get your point across.

> - and [test] urls for each available backup/save/draft

We already have that: it’s Step 5 on the setup_skin page.  The test URL list 
changes whenever you change the draft name in Step 1.
___
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] Meta-enhancement

[Warren Young]

On Jun 28, 2018, at 8:53 PM, David Mason  wrote:
> 
> Looks nice. What I meant was: what do I have to change to make it work.

Clone my repository, go into Fossil UI, then navigate to Admin > Tickets.  Copy 
as much or as little of what you see there into your Admin > Tickets sections 
as makes sense for your your purposes.

Then do the same for Admin > Skins.  At minimum here, you’ll want my Bugs and 
Wish List button changes.

You need to copy from a local clone because you won’t be able to get into my 
repository’s Admin section via my public Fossil instance, lacking admin 
privileges on that instance.
___
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] Meta-enhancement

[Warren Young]

On Jun 28, 2018, at 6:15 AM, David Mason  wrote:
> 
> where did you make these changes?

It’s most readily seen in this repository:

https://tangentsoft.com/pidp8i

In addition to the reporting changes I previously described, there are others, 
mainly in Admin > Tickets > Common.  For instance, my resolution_choices list 
includes the nonstandard “Implemented” choice, which I use instead of “Fixed” 
when I finish implementing a feature request ticket.

Further thoughts on this topic:

Features do sometimes jump multiple levels.  For instance, an idea that was 
once just a good idea — “Medium” in my system — may eventually be deemed 
essential and thus jump straight to Immediate priority.

Features sometimes also fall multiple levels.  A person filing a feature 
request might have what he thinks is a really hot idea (“High”) but when we 
later go through the release planning exercise, management may think it’s a bad 
idea for some reason, so it drops to Low rather than being deleted.  We may add 
a comment on reprioritizing at this point to record who spiked the idea, so we 
know who has to be convinced if the idea comes back up again.

The High priority pool rarely drains, even immediately after planning the next 
release.  We have more great ideas than time to implement them.  We just hope 
to get to those ideas before the world changes enough that the feature ideas 
become worthless, in which case we need more developers: we’ve left fruit on 
the tree.

The Medium pool never drains until the project planners run out of good ideas, 
at which point it’s time to mothball the project.

If the Low pool ever drains, it probably means you’re not capturing enough of 
the organization’s knowledge in Fossil.  After enough member turnover, the 
organization will forget things it should remember.

“Low” may be an idea graveyard in a private repository, but in a public repo, 
it is where features that the core developers are unlikely to get to land.  
This pool is a good place to point outside contributors, since they’re ideas 
worth keeping but they’re unlikely to conflict with a core developer’s plans.  
That’s not an exclusive characterization: Medium will have more such ideas, 
just with a higher risk that some core developer has his eye on it and has 
plans to get to it someday.

Fossil’s ticketing system is really quite flexible.  There’s a good chance you 
don’t have to accept things you don’t like about it: the fix might be easily 
accomplished.
___
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] Meta-enhancement

[Warren Young]

On Tue, Jun 26, 2018 at 10:57 PM, David Mason  wrote:

> we all sell the value of fossil partly because it has a wiki
>

The current wiki is great for evergreen content: information whose lifetime
is independent of that of the software being discussed. Whenever the
documentation must evolve in lockstep with the software it describes, you
should use the embedded documentation feature
 instead.

We could heal this dichotomy if, after saying something like "fossil up
2017-06-05", the wiki as presented by "fossil ui" would show the wiki
documents contemporaneous with that checkout. Then it wouldn't much matter
whether you chose wiki or embedded docs.

and ticket system
>

The problem there is spam.

With the upcoming email and forum features, that problem may be solved by
requiring an email-verified login before someone can create a ticket, so
that it is no longer necessary to have a human gatekeeper on the ticket
tracker.

I'm no better on my personal projects...
>

I am. ;)  I use the wiki and ticket tracker on both public and private
Fossil repos.

No one's spammed my public Fossil ticket tracker yet, but as I recall, it's
set up to require a valid user login to create tickets.
___
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] What should email notifications look like?

[Warren Young]

On Jun 22, 2018, at 12:18 PM, Richard Hipp  wrote:
> 
> == 2018-06-22 01:28:10 Check-In ==
> Fix harmless compiler warnings. (user: drh tags: email-alerts)
> https://fossil-scm.org/fossil/info/5fde17bbbc2cba69d3f8

Some systems I’ve used in the past have an option to include a diff on 
checkins.  This avoids the need to go back to the web site — Fossil UI in this 
case — in most cases.

Coupled with this option is usually a max diff size limit, so that a massive 
checkin doesn’t create huge email notifications.  That in turn encourages 
sensibly-sized checkins, which is a good thing.
___
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] Cloning repository with large files very slow

[Warren Young]

On Jun 21, 2018, at 1:25 PM, E Cruz  
wrote:
> 
> some of the source files define a few very large tables.  These tables do not 
> change often, but when they do most of their content is replaced with 
> something completely different from the previous version.

Are the differences merely at the binary level or is the semantic content also 
changing?

For instance, these two commands give entirely different output, but with 
identical semantic content:

$ echo "Hello, world!" | bzip2 | od -t x1
$ echo "Hello, world!" | lz4   | od -c

The point is, there may be an encoding for your data that reduces the size of 
the diffs to include only the semantic differences.

As an example, storing two different versions of a PNG in Fossil is probably 
less efficient than storing the same logical image data in Windows BMP form 
plus a conversion command to PNG during the build process, since the BMP is 
uncompressed and has very little metadata, so that only the actual pixel 
differences are stored in Fossil.  

(If you doubt this, I actually tested it and reported on the differences some 
years ago here.)

Many binary data formats have this same property.  They’re optimized for the 
size of individual files on disk, not for the total size of a 
delta-and-gzip-compressed version control repository.

Yet another example is all of the binary data formats based on ZIP: ODF, JAR, 
APK…  They’d store more efficiently in Fossil if unpacked into a tree before 
being checked in between changes.

> When changes to these files are committed, fossil takes a long time to 
> process the commit (a couple of minutes for a 20MB table, over 10min for a 
> 60MB table).

That’s superlinear, which is bad.

Try unsetting repo-cksum on this repository, if it’s enabled:

https://fossil-scm.org/index.html/help?cmd=repo-cksum

With that unset, you become responsible for local file integrity.  Some of the 
more modern filesystems obviate the need for manual integrity checks or 
secondary checks like the one Fossil does: ZFS, APFS, etc.
___
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] No rule to make target 'src/email.c', ...

[Warren Young]

On Jun 21, 2018, at 9:03 AM, Richard Hipp  wrote:
> 
> On 6/21/18, Eric Dillon  wrote:
>> Fails to compile on Win32 VS2013 (12.0)
>> 
>> email.obj : error LNK2019: unresolved external symbol _popen referenced in
>> function _email_send
> 
> Thanks for the report.  Fixed now.

You might want to change the “sendmail -t” default for Windows as well.  
Requiring that someone use Cygwin, WSL, or a native Windows port of 
Sendmail/Postfix just to get sendmail(1) on Windows seems like a big “ask”.

The more Windows-native methods seem to be one of these options:

https://stackoverflow.com/q/15433202/142454
https://superuser.com/q/63081/14927

I think the PowerShell option has the least burdensome requirements, needing 
only a simple script, which we can provide in the Fossil docs.  Here’s a link 
to a forum thread describing how to read stdin from PowerShell, leaving only 
the need to parse it to parameters that can be fed to the SmtpClient.Send() API:


https://social.technet.microsoft.com/forums/scriptcenter/98a05368-6a0c-4cf3-bf7e-4bb8ae748fe6

Are there any PowerShell scripters here who can stitch this information 
together into a working script, one that takes RFC 822 via stdin, parses the 
headers and body into variables, and calls the API correctly?

I could probably puzzle it out, but I’d end up writing Perl in PowerShell.  A 
native speaker would do a better job.
___
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] The legacy of FOSSIL_ENABLE_LEGACY_MV_RM

[Warren Young]

On Jun 20, 2018, at 7:45 PM, bytevolc...@safe-mail.net wrote:
> 
> it is the only compile-time flag that
> determines if a setting is hard-coded or if it is obtained from the 
> repository config.

I don’t believe that to be an accurate description of the way the build-time 
option behaves.  Or at least, it is not an accurate description of ./configure 
--with-legacy-mv-rm, which is how you normally set that C preprocessor flag.

I believe all this configuration option does is determines whether the run-time 
setting mv-rm-files exists.  It doesn’t set it by default, and with that option 
unset on a repository, you get the old behavior, the one that doesn’t match 
POSIX mv/rm semantics.

After configuring Fossil with this option, you must still set this option on 
each repository.  Fortunately, this is not difficult:

$ fossil all set mv-rm-files 1

I seem to recall that the “all” command didn’t always work with settings with 
arguments, but I might have a hash bucket collision going on right now.
___
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] Backups of deconstructed fossil repositories

[Warren Young]

On Jun 17, 2018, at 2:05 PM, Warren Young  wrote:
> 
> If you’re willing to gamble that if the first test returns true that the 
> second will also returns true, it buys you a big increase in speed.  The 
> gamble is worth taking as long as the files’ modification timestamps are 
> trustworthy.

I just remembered something: “fossil up” purposely does not modify the mtimes 
of the files it writes to match the mtime of the file in the repository because 
it can cause difficult-to-diagnose build system errors.  Writing changed files 
out with the current wall time as the mtime is more likely to cause correct 
builds.

I wonder if the fossil deconstruct mechanism also does the same thing?  If so, 
then you can’t take the rsync mtime optimization without changing that behavior.
___
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] Backups of deconstructed fossil repositories

[Warren Young]

On Jun 17, 2018, at 12:16 PM, Thomas Levine <_...@thomaslevine.com> wrote:
> 
> One inconvenience I noted is that the deconstruct command always writes
> artefacts to the filesystem, even if a file of the appropriate name and
> size and contents already exists.

You might want to split that observation into two, as rsync does:

- name, size, and modification date match
- contents also match

If you’re willing to gamble that if the first test returns true that the second 
will also returns true, it buys you a big increase in speed.  The gamble is 
worth taking as long as the files’ modification timestamps are trustworthy.

When the timestamps aren’t trustworthy, you do the first test, then if that 
returns true, also do the second as extra assurance.

> Would the developers welcome a flag
> to blob_write_to_file in src/blob.c to skip the writing of a new
> artefact file if the file already exists?

In addition to your backup case, it might also benefit snapshotting mechanisms 
found in many virtual machine systems and in some of the more advanced 
filesystems.  (ZFS, btrfs, APFS…)

However, I’ll also give a counterargument to the whole idea: you probably 
aren’t saving anything in the end.  An intelligent deconstruct + backup 
probably saves no net I/O over just re-copying the Fossil repo DB to the 
destination unless the destination is *much* slower than the machine being 
backed up.

(rsync was created for the common case where networks are much slower than the 
computers they connect.  rsync within a single computer is generally no faster 
than cp -r, and sometimes slower, unless you take the mtime optimization 
mentioned above.)

The VM/ZFS + snapshots case has a similar argument against it: if you’re using 
snapshots to back up a Fossil repo, deconstruction isn’t helpful.  The 
snapshot/CoW mechanism will only clone the changed disk blocks in the repo.

So, what problem are you solving?  If it isn’t the slow-networks problem, I 
suspect you’ve got an instance of the premature optimization problem here.  If 
you go ahead and implement it, measure before committing the change, and if you 
measure a meaningful difference, document the conditions to help guide 
expectations.
___
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] A fossil library

[Warren Young]

On Jun 15, 2018, at 4:46 PM, Stephan Beal  wrote:
> 
> - refactoring to a lib is a huge effort.

That’s the real trick, I think: the library needs to be part of Fossil proper, 
so that it stays up to date.

That in turn means finding and maintaining a strong boundary between whatever 
your conception of “less Fossil” is from “whole Fossil.”

If such a clear boundary doesn’t already exist, refactoring Fossil until such a 
boundary appears will be difficult, but perhaps worthwhile on its own merits, 
even if your liblessfossil is never used.

More than once, people have proposed applications of Fossil that could use this 
liblessfossil, where arm-twisting whole Fossil into the role was not sensible.
___
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] [sqlite] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 9:34 PM, Warren Young  wrote:
> 
> maybe full SMTP support in Fossil wouldn’t be justified, and it would require 
> integration with a local MTA instead, to push the burden off to the other 
> component.  That wouldn’t be very Fossil, but it would be pragmatic.

On second thought, that’s not true.  Fossil currently does not try to implement 
the client or server sides of TLS.  It delegates to OpenSSL for the former and 
to an HTTPS proxy for the latter.

This may be another area where Fossil is right to delegate.
___
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] [sqlite] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 9:05 PM, Shal Farley wrote:
> 
> On 2018-06-14 1:47 PM, Warren Young wrote:
> 
>> Would you rather see drh spending time fighting spam or writing useful 
>> software?

> I think that's the best reason for outsourcing the mailing list problem

Agreed, which is why I’ve also been on the “keep the mailing list” side of the 
argument: the difficulty in implementing SMTP and its raft of concomitant 
standards.

There are pros and cons on both sides, and the community has listed several of 
each.

drh has his poll results now, so I think it’s now time to start winding these 
threads down and wait to see how he chooses to spend his time.

> I don't think that choice precludes work on building something integrated 
> with fossil that may be interesting and useful for drh and for us.

Also agreed.  In that case, then maybe full SMTP support in Fossil wouldn’t be 
justified, and it would require integration with a local MTA instead, to push 
the burden off to the other component.  That wouldn’t be very Fossil, but it 
would be pragmatic.

> Someone else here suggested already that what works best as a component of 
> fossil in support of a development team might not be the same solution as 
> what works best for an open community of users and developers asking and 
> answering questions.

That was me.  Developer list != user list.  Different technologies for each 
within a single project are sometimes justified.

> Yes, I'm a mailing-list advocate, and hence a dinosaur.

It’s one thing to label yourself such, and quite another for others to throw 
that label at you as an accusation.  Ahem. :)

(Speaking as one who’s been using the Internet since shortly after bang paths 
went out of style.)
___
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] Make Tech Notes work like a Lab Notebook

[Warren Young]

On Jun 14, 2018, at 7:02 PM, Scott Doctor  wrote:
> 
> Looking through my current project fossil UI, it seems that instead of adding 
> a forum module, what about a modification to the Tech Notes module.

In the past, I’ve suggested that a forum could be constructed from a 
combination of the current ticket and wiki mechanisms.  The pieces are already 
all there.

The hard parts I can see from this distance are:

1. Threading, which is strictly optional, but I wnt it.

2. Email integration, which we have many uses for once it’s available, so the 
cost amortizes.

I was going to say add “Quoting,” but it appears that Fossil’s Markdown 
processor already handles nested block quotes.  Neat!

> What I need is a way to simply link and group various tech notes, which may 
> span hundreds of notes over long periods of time.

Are you maybe viewing the future through the past’s lens?  If you’d had a forum 
feature from the start, would you have written the top-level tech notes as 
posts and the subordinate ones as replies, possibly with [links] back to the 
relevant checkin ID?

This would work like the “talk” page on MediaWikis, where the stream of ideas 
over time is visible, unlike on the main article page, where you normally only 
see the latest edition of the article.

> Need a simple way to link a tech note to one or more tickets and other tech 
> notes

Fossil’s existing artifact reference mechanism should work just fine for this.  
That’s one of the primary advantages of having this inside Fossil instead of 
integrating some third-party forum system.

The feature should also allow creation of new forum threads from checkins, etc. 
 I called it “reply to checkin” in a previous message.

> I am thinking if a problem re-surfaces in the future, a search or browse can 
> find and resurrect a thread to help with discussion and documentation about a 
> potential solution, or to simply document results of experiments.

I do this today with comments in the code, and I believe it would be less 
discoverable to have such commentary in the repository timeline instead.  (Code 
tells what, comment tells why.)

But that doesn’t argue against any of the features being discussed, just 
against this one use of the proposed features.

> Need a simple way to add links within the body of a tech note to reference 
> other tech notes and tickets referenced in the text (hyperlinks).

In both Markdown and Wiki syntax, bracket links [abcd1234] work today.

If you want explanatory text instead of a hexbarf link, you can do it in 
Markdown by [specifying the viewing verb in the URL](/info/abcd1234).  The 
equivalent in wiki syntax should be clear.

I’ll admit that that is not terribly discoverable, but I’m struggling to come 
up with a syntax that wouldn’t be ambiguous.  The closest I’ve come is 
[this]([abcd1234]) but that’s hardly discoverable.  It’d have to be documented.

> Also a simple way to add a link in the body text to specific files in the 
> repository.

That’s already available with the embedded documentation feature:

For more information, see [the source code](/doc/trunk/src/foo.c).

In some cases, you might prefer a /file URL instead.  Say “fossil help /file” 
for more info.  

If you did not know that that form of help command was even possible, say 
“fossil help --www” to be further surprised. :)

> I think a few modifications to the tech notes module would make it usable 
> like a lab notebook. I can make notes about whatever, have multiple threads 
> of unrelated issues, and be able to manipulate linkages later so that I can 
> scavenge and organize my notes when I write a paper or documentation about my 
> project. This would be along the lines of what a writer would do using 
> software such as scrivener.

That sounds a lot like a forum feature to me.  It happens to be now-you talking 
to future-you, but it’s the same mechanism.
___
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] Perception of Fossil (dumb idea for pull requests)

[Warren Young]

On Jun 14, 2018, at 5:50 PM, John P. Rouillard wrote:
> 
> In message <20180614213758.ga7...@britannica.bec.de>,
> Joerg Sonnenberger writes:
>> 
>> 
>> How do I develop a patch locally and send it to someone for review?
> 
> Would some combination of:
> 
>  bundle
> 
> published via
> 
>  uv mechanism

Back when I proposed the feature set that became bundles, I proposed that it 
include a way for the outside contributor to create a ticket from a bundle, 
which would be pushed to the remote repository for disposition by someone with 
a commit bit.

That never happened, but now I think it’s another good reason for Fossil to 
have a forum feature.  Someone with a forum login on a repository but lacking a 
commit bit could say

$ fossil bundle push --branch my-new-feature

and have their un-sync’d my-new-feature branch bundled and pushed to a 
sub-forum dedicated to accepting unsolicited outside contributions.

Effectively, the new “push” verb is “fossil bundle export && send to 
contribution sub-forum,” with the local Fossil instance transferring it 
directly to the remote just as with the normal push feature.

Someone with a commit bit could then do a one-click integration of the bundle 
branch from the forum UI, presumably after testing it locally on their machine.

There are several advantages to doing it through Fossil UI instead of the 
current mechanism:

1. fossil bundle import && test && fossil bundle import --publish && send email 
is more involved than fossil up my-new-feature && test && click “Integrate” in 
Fossil UI.

2. Like closing a ticket combined merging a branch with --integrate, clicking 
that button would auto-close both the forum thread and the branch.

3. By integrating it so tightly, the committer doesn’t need to explicitly 
involve the local filesystem at all.  The local Fossil instance gets a copy of 
the bundled branch with the next sync past the outside contributor’s push, and 
the integrate happens using that same contributed bundle.  There’s no need to 
rm ~/Downloads/my-new-feature.bundle after integrating the bundle, nor the 
bulky email containing it.

4. Now we’d have pull requests to shut the Git fans up, except that they’d 
actually be push requests. :)
___
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] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 5:48 PM, bch  wrote:
> 
> On Wed, Jun 13, 2018 at 9:30 AM JH  wrote:
> > One way to implement that is to incorporate SMTP into Fossil directly. 
> 
> Attractive as that may sound, do we really want to be another (near) instance 
> of Zawinski’s Law?

I always had the sense that that “law” was meant to be read with a reluctant 
sigh.  If Fossil knuckles under to whatever Leviathan is enforcing this 
particular law, we should reluctantly sigh as well, particularly the 
unfortunate soul(s) who end up implementing the thing.

Yeah, that’s right, I’m on both sides of this issue.  Cope. :)
___
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] [sqlite] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 3:36 PM, Thomas  wrote:
> 
> On 2018-06-14 22:21, Warren Young wrote:
>> I expect to have no Internet access in the plane I will be aboard shortly.
> 
> I'm not aware of any airline that doesn't provide internet access on 
> long-haul flights. Is there still one left?

I just checked, and for the flight I’ll be on, it’ll cost me about 1/10 the 
monthly cost of my residential Internet service, per device.  If I want to use 
my phone, tablet, and laptop, that’s 3/10 my monthly cost for a few hours of 
terrible service.

…which you apparently think I should pay just so the software I use doesn’t 
have to deal with the offline access case.

You’re very generous with the contents of my wallet.

While on last week’s off-network trip, I tallied the number of apps on my 
tablet that were useless without an Internet connection.  It was about 75% 
before I gave up in disgust.

I decided to do that tally after being unable to move a document from one app 
to the another on the same tablet, because the receiving app only offered a 
“send it to a datacenter in Washington state” import option.

This is not progress.
___
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] Perception of Fossil

[Warren Young]

On Jun 14, 2018, at 4:04 PM, Thomas  wrote:
> As far as I can see until now you got to create an account for every 
> contributor yourself.

I think that’s a feature in a web service that, currently, has no way to do 
email verification.  Else, spammers again.

One presumes that if Fossil gets a forum feature with email gatewaying, 
*optional* self-registration will come along with it.

Many Fossil instance admins will want to turn such a feature off, since 
invite-only is how they want it in the first place.
___
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] [sqlite] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 3:10 PM, Thomas  wrote:
> 
> On 2018-06-14 21:47, Joerg Sonnenberger wrote:
>> I've had to deal with my share of fori. Frankly, they all suck for power
>> users, often badly. While mailing lists do tend to be a bit more
>> annoying than newsgroups, they nevertheless share the majority of
>> advantages. Offline access, decent filtering etc. Heck, a lot of fori
>> programs still hasn't even managed good threading.
> 
> Another example of the past. We're online 24/7 nowadays. Offline access is 
> not required anymore.

I was offline for about 3 days solid, less than a week ago.  No Internet access 
at all, despite having a charged mobile phone with me at the time.

I have made Fossil repo commits from inside an RV, miles from the nearest wifi.

I expect to have no Internet access in the plane I will be aboard shortly.

> In case you really need some help while offline, I cannot imagine how you'd 
> be able to get a request for help out better via mail than dropping off a 
> forum post when you're offline.

What of the other direction?  People like Jörg are more likely to be answering 
questions than asking them.  Why not write answers while offline, then sync the 
answers when back on-network?  Email lists, Usenet, and my proposed Fossil 
Forum Feature allow this.  Web forums generally do not.
___
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] Perception of Fossil

[Warren Young]

On Jun 14, 2018, at 2:51 PM, Ron W  wrote:
> 
> In another forum I follow,a commented claims that Fossil is designed for 
> "cathedral development" not "bazaar development”

That’s the official stance, not some rand-o’s opinion:

   https://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

> so would be of little interest to anyone

The conclusion does not follow from the premise, else most software would never 
be written, which we can see from the fact that most software is not written in 
a bazaar style.

The last time I saw stats on this, it was ~95% written for internal purposes of 
some sort, with only 5% published.  That was before app stores and the 
explosion of open source, however.

On the other hand, it was also before proprietary web apps, which are often 
built cathedral-style.

> Unfortunately, the poster did not elaborate on why.

Fossil wants contributors to have logins on the repository, not to be unknown 
outsiders.  That in turn suggests an invite-only style of development, which 
means that a contributor must earn some amount of trust before being given a 
login.  

The above-linked page also talks about contributor agreements and license 
implications, which I don’t buy as necessary consequences of the Fossil user 
model, but these concepts are frequent companions, to be sure.

You see this in Fossil’s patch and bundle mechanisms, which are much more 
rarely used than direct commits.  In my own public projects, I take patches and 
bundles as letters of introduction, which I use in deciding whether to offer 
someone a login on the repository.

Contrast Git, where the fork-and-PR model is very common, and only the closest 
inner circle may have direct commit rights on the official repository.  That’s 
bazaar-style.

> Except maybe possible issues scaling to a large number of contributors, I 
> don't see how Fossil is less suitable for  "bazaar development" than git or 
> Hg.

I think it’s an uninteresting argument for most projects, where 90+% of the 
code is going to be written by the inner circle anyway, no matter how you 
structure it, so it doesn’t matter if you call it cathedral-style or something 
else.  Bazaar style development is only common on projects popular with 
developers, where many skilled people are likely to make valuable contributions.

Even then, it’s not a necessary pairing, as we can see with SQLite itself, 
where commits are typically allowed only by a very small number.

The Fossil project is more open than SQLite, but even so, only 27% of commits 
come from anonymous or “other,” with only two people having double-digit 
percentage commit rates.  That’s cathedral-style, right there.
___
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] [sqlite] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 1:51 PM, John Long  wrote:
> 
> having to have browser tabs open for dozens of web forums

I bookmark all of the sites I need to go to regularly and place them in a 
folder in my browser’s bookmark bar so that I can open them all at once with a 
Cmd- or Ctrl-Click on the folder.  As I read each forum, I close that tab.

I actually keep two such folders, “Daily” and “Weekly,” suggesting my visiting 
frequency, which is set by how often I expect interesting content to appear.

> having to come up with and manage
> passwords for each of those

I’m not aware of any mailing list that doesn’t require a password, if only via 
some outer SSO provider.  Such a thing would be a spammer’s paradise, if it 
existed.

I don’t see this web forum depending on someone else’s SSO solution.  (OAuth, 
OpenID, etc.)  That would be very un-Fossil.

> and have to actively monitor each one to
> see if anything of interest happens to appear

Yes, just like Usenet. :)

Opening a folder of bookmarks in a browser isn’t much different than opening a 
Usenet client that’s subscribed to an equivalent number of groups.  Both 
aggregate access to many fora, opened with a single user action.

> Most mailing lists assign you a password

I subscribe to a whole lot of mailing lists, and I can’t come up with one where 
I was given the password instead of having to generate it with my password 
manager.

“A small minority,” I believe, but not “most.”

Certainly not GNU Mailman as configured at fossil-scm.org or at sqlite.org, at 
any rate.

> and you don't even have to keep track of it; many
> email you password reminders on a regular basis

If the mailing list is able to email you your password, it’s ripe for attack: 
they cannot possibly be hashing and salting their passwords, as is industry 
best practice:

https://security.stackexchange.com/q/51959

(Pro tip: if a web site has a maximum password length limit under 32 characters 
or so, chances are good that they’re storing your password in plaintext, since 
hashing the password inherently converts it to a fixed length.  Higher limits 
are more likely input sanity limits rather than risk indicators.)

The closest to your usability ideal that I’ve seen is automatic password resets 
via email, which is itself a vulnerability, since it means anyone who can 
access your email account is able to take over any such service associated with 
that email account.  This is what happened in the famous Mat Honan identity 
theft:

https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/

People say, “Oh, it’s just my Google account, who cares if a bad guy takes that 
over?”  This being the account that is associated with their Android phone, 
which is associated with their mobile phone company account, which is 
associated with their credit card account, which is associated with a large 
chunk of their financial life, so now they’re pwned.

Whatever drh decides to build, using a significant slice of his limited time on 
this planet, which time I have no call on, I expect he will take password 
security seriously, evidenced by Fossil’s users table:

https://www.fossil-scm.org/xfer/doc/trunk/www/tech_overview.wiki

(Section 2.2.4.)

> Web forums are right out.

Would you rather see drh spending time fighting spam or writing useful software?

At least if he spends his time building a forum system atop Fossil, we can all 
use it on our own projects as well.  His time spent fighting email spam has 
much more ephemeral benefits.
___
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] [sqlite] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 1:36 PM, Thomas  wrote:
> 
> no one wants to see all those in their inbox.

Mailing list messages are easily filtered.  

I have one mailbox for each mailing list I subscribe to, and I read through the 
messages in list order, which makes it easy to mentally switch gears from one 
project to the next.

If one project gets out of hand for a while, I can mark only that one mailbox 
as “read” without declaring email bankruptcy on all my other email.
___
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] [sqlite] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 10:51 AM, Richard Hipp  wrote:
> 
> On 6/14/18, Roy Keene  wrote:
>> If it's any conideration, if it's not a mailing list or something else
>> pushed to me, I'll never see it.
> 
> I agree.  Any solution must support email notification.  Am working on
> that now.  But, given all the security constraints surrounding email
> these days, it is a tough problem.

I’ve just thought of a reason that you cannot simply send outbound email to a 
local MTA and have it deliver it for you, while conforming to all of the 
relevant RFCs: when the mailing list members receive the message, some may want 
to reply, and that would then go back to the same MTA which would then be 
unable to process the mail correctly.

An MTA plugin and/or hand-configuration to integrate Fossil Forums with the MTA 
could solve it, but now you’re adding complexity.  I suspect many haven’t put 
their public Fossil instances behind an HTTPS proxy for the same reason, and we 
should take that as a caution.

There are definite advantages to Fossil Forums being its own MTA.
___
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] [sqlite] Mailing list shutting down...

[Warren Young]

On Jun 14, 2018, at 4:29 AM, Dominique Devienne  wrote:
> 
> Last discussion/thread on moving away from MLs on the SQLite list showed a 
> clear bias
> against using a forum over a ML IMHO, especially from long time contributors. 
> My $0.02... —DD

I was one of those arguing in favor of mailing lists.

To me, the question comes down to two key questions:

1. Which gets us back into operation faster?  If the effort to maintain a 
mailing list in today’s inimical environment is greater than the effort to 
develop an alternate solution that would sidestep these problems, it’s really 
hard to justify sticking with mailing lists.

2. Does switching add important and valuable new capabilities?

Note the qualifiers.  Animoji are not important to the SQLite or Fossil 
development projects, and their value is very low.  Integration with the Fossil 
DVCS may be very valuable and could become important if it helps win converts.


One new thought since my prior post: many projects (including Fossil and 
SQLite) have separate user and developer communication channels.  It might be 
that the internal developer discussions use this proposed Fossil Forum feature 
and the user discussions are held elsewhere.

In one of my Fossil-based projects, we have a public Google Group for 
discussions that may not even touch on the software development project, with 
developer discussions hidden away in private email, even though there’s nothing 
particularly personal about the discussions.

I mentioned Fossil artifact links in a prior email.  I’m frequently 
hand-crafting these in emails to other developers on the project to refer to 
some checkin, wiki edit, etc.  It’s annoying.
___
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] Mailing list shutting down...

[Warren Young]

On Jun 13, 2018, at 3:12 PM, Richard Hipp  wrote:
> 
> I have found is that forum
> and ticket traffic far exceeds the amount of source code.

I just exported my local 6-year archive of the SQLite mailing list traffic to 
an mbox file, then gzipped it, yielding a 31 MB file.  The current 
sqlite.fossil file is 51 MB.

If we do a linear projection back to the start of the mailing list — August 
2002, according to MARC — then we’d expect the full ML archive to be roughly 
100 MB, not counting the -dev list and such.

That estimate includes the peak in traffic many years ago:

https://imgur.com/a/UdQ5ziH

That chart shows that the SQLite-Users mailing list is “dying,” in that its 
message volume is currently lower than near the mailing list’s beginning, 
despite the much greater popularity of the library these days.  I ascribe that 
to an increasing percentage of questions having web-searchable answers now, 
plus a decreasing willingness to put up with mailing lists.

(I just corrected a funny autocorrect: malign lists. :) )

My gzipped mbox test is worse than a Fossil-based solution, which:

1. would not have all of those redundant RFC 822 mail header labels;

2. would not need many of the message header lines at all (e.g. X-Abuse-Info or 
List-Unsubscribe); and 

3. would not store many of the fields in inefficient plain text forms within 
the SQLite DB.   (e.g. Delivery-Date might be a time_t stored in an INTEGER 
column rather than the verbose text RFC 822 format, and if not, then it would 
probably be the more compact ISO 8601 format so as to make the SQLite date/time 
routines happy.)

There would be no extra disk space cost on sqlite.org, since I assume you’re 
already keeping a mailing list archive there.

The extra space on the wire during cloning can be solved in the same way /uv is 
handled today, if need be.

> this kind of traffic does not lend itself well to delta compression.

In fact, delta compression would benefit two use cases of the Fossil Forum 
Feature:

1. The post editing case, just as with Fossil wiki articles today.

2. Quotations in replies.

Granted, a forum feature would lower the current /stat compression ratios, but 
we’re not really after high compression ratios for their own sake, are we?  
We’re using compression to solve problems: inter-version redundancy, the low 
information density of prose and high-level language code, etc.

Forum posts would be highly compressible by zlib.  The uncompressed mbox file 
in the tests above is about 5x the size of the gzipped version.

> extraneous and noisy forum traffic.

One man’s noise is another man’s signal.

It would be very nice to be able to search the mailing list from within Fossil 
UI, getting only one copy of each matching message, not one from 
mail-archive.com, one from MARC, one from Nabble, one from …

I happen know where we can get a pretty good FTS implementation. ;)

This feature would be even more useful on private projects, where we cannot 
rely on the likes of mail-archive.com to gather and index our discussions.

> This is especially true if attachments are
> allowed on forum posts

You can fob that off on third-party services like Imgur, for the most part, 
just as Stack Exchange does.

If a post really really needs a repo-embedded attachment, it can use an 
embedded doc link, just as you’d do for a Fossil wiki article today.

>> 3. Forum posts can show up in the timeline.
> 
> Yikes.  I think I would certainly want that to be turned off by default.

The timeline search type field defaults to “Check-ins”, does it not?  You’d 
only see forum posts with “Any Type” selected or with a new “Forum Posts” 
filter selected.

Even then, it should be quite manageable.  With the default 100 event search 
window size, you’d still be seeing several days of activity with the current 
level of SQLite mailing list traffic, most of the time.  SQLite’s mailing list 
traffic must be somewhere over the 90th percentile in terms of daily traffic, 
so most Fossil-hosted software projects would show even more days of activity 
in that 100 event window.

To clarify, I don’t mean that the whole forum post would show up in the 
Timeline, just a brief summary, as currently happens with tickets and wiki 
article events.
___
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] Mailing list shutting down...

[Warren Young]

On Jun 13, 2018, at 2:04 PM, Steve Schow  wrote:
> 
> Yea I agree, this is nice stuff to have, but in my view is not compelling for 
> fossil which sets itself apart by being lightweight and simple.

Yes, and I would expect this Fossil Forum Feature to be lightweight and simple, 
in the same way that Fossil doesn’t try to compete feature-for-feature with 
MediaWiki or Jira.  It provides enough wiki and enough ticket tracking for most 
projects.
___
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] Mailing list shutting down...

[Warren Young]

On Jun 13, 2018, at 12:55 PM, Steve Schow  wrote:
> 
> There are other deep solutions such as redmine and others which provide deep 
> collaboration capabilities…which is where that kind of feature would lead to.

That makes me like the idea even more. :)

It would be nice, for instance, to be able to reply to a checkin.  A 
coworker/collaborator often checks something in that you want to discuss, so 
you reply to the checkin, creating a discussion thread from it.

That would also be a step on the path towards a code review feature.  In the 
initial version, simply being able to attach an “Approved” or “Merge it” reply 
to the latest checkin on an experimental feature branch would be useful.

You can sorta do this today with tech notes, but the message target may miss 
seeing it, just monitoring the timeline.  Adding in email notification solves 
that, since the email comes from a trusted source, and is thus easy to filter, 
tag, sort, and escort past the anti-spam filters.

This also allows a platform for CI/CD tools: the tool can “reply” to the 
checkin with the status of the build, tests, etc.  That in turn allows Fossil 
to display build and test status badges in the default Home wiki article.

> Collaboration such as what we see on GitHub, etc..would be cool, don’t get me 
> wrong, but in my opinion would greatly add to complexity in fossil.  I would 
> be using one of those solutions already if I wanted a big complicated 
> collaborative platform like that.

Any software project with more than one remote member needs such a thing.  For 
such projects, a discussion forum is probably more important than a wiki or 
ticket tracker.

I think it’s fair to consider some kind of discussion forum an essential tool 
for software development collaboration, which puts it right in Fossil’s space.
___
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] "remember this password (Y/n)?" and `isatty()`

[Warren Young]

On Jun 8, 2018, at 5:08 PM, Eduard  wrote:
> 
> The '--interactive' switch is only for the sqlite shell I think. It is not 
> accepted for the remote-url command.

So reflect the same feature into main() within src/main.c.  Then test the 
global variable stdin_is_interactive wherever isatty(stdin) is currently used.
___
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] Mailing list shutting down...

[Warren Young]

On Jun 13, 2018, at 10:30 AM, JH  wrote:
> 
> Recently, I started working on that using my smtp.h and smtp.c:

I haven’t looked into your implementation, but I suspect you’re missing a whole 
lot:


http://sqlite.1065341.n5.nabble.com/Many-ML-emails-going-to-GMail-s-SPAM-td98685i20.html#a98722

If Fossil gets an email output path, I’d expect it to be implemented by calling 
out to an existing MTA, rather than use an internal one, at least to start 
with.   Otherwise, large parts of the email world will be unreachable due to 
not implementing all of the necessary standards.
___
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] Mailing list shutting down...

[Warren Young]

On Jun 13, 2018, at 9:18 AM, Richard Hipp  wrote:
> 
> On 6/13/18, Warren Young  wrote:
>> If you do this atop Fossil, then you end up inches away from being able to
>> provide an oft-wanted feature: email notifications on checkins, wiki article
>> changes, and other Fossil events.
> 
> Indeed, there are many advantages to just tacking a forum capability
> onto Fossil.

Let’s list them:

1. Lots of “free” infrastructure: user management, role-based access control, 
web framework, wiki and Markdown to HTML formatters, durable and efficient 
message storage with deltas, pre-designed shunning mechanism.

2. Everyone who clones a Fossil project repository would henceforth also get a 
clone of the project’s message traffic.

3. Forum posts can show up in the timeline.

4. Forum posts will be able to ink to Fossil artifacts in the same way that 
checkin comments, wiki articles, and such can today.

5. Vice versa: a checkin comment can say “Closes issue raised in forum post 
[abcd1234]” and get an automatic *and durable* link to the post.  (How many web 
mail archives have gone away or broken their link structure since the SQLite ML 
was started?)

6. Trivially-implemented delayed offline replies: sync the project repo before 
you go off-network, write your forum message replies on the airplane, in the 
tent, etc. then sync when you get back into the warm wifi bath to push all your 
replies out.

> But there are also disadvantages.  The biggest problem I
> see is that one does not necessarily want the standard Fossil page
> header and footer to appear on the forum pages.

That’s a small cost, and arguably not a cost at all.  If you’re at the SQLite 
project web site and are posting a message, you might well want to make use of 
other Fossil services while you’re there.

The forum feature may well have a sub-header, but that doesn’t argue against 
having a top-level header linking to other site services.

Hacker News, Stack Exchange, Slashdot and other forum sites offer services 
other than messaging in their top-level site headers.

> People looking for
> help with an SQLite question do not need to see "Timeline", "Files",
> "Branches", "Tags", and "Tickets" menu items across the top of the
> page.  (ex: https://www.sqlite.org/src/doc/trunk/README.md)

Some may, and those that don’t need it can ignore it.
___
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] Mailing list shutting down...

[Warren Young]

On Jun 13, 2018, at 8:05 AM, Richard Hipp  wrote:
> 
> My current tthinking is to use a hybrid approach where subscribers get
> emails just like ordinary mailing lists, but posting and replying is
> via web-form only.

If you do this atop Fossil, then you end up inches away from being able to 
provide an oft-wanted feature: email notifications on checkins, wiki article 
changes, and other Fossil events.

> Web-form only post and reply makes it much easier to control spam.

Consider allowing editing as well.  I’ve found that I’ve become accustomed to 
pushing “submit” earlier than I would have in the past, due to Stack Exchange, 
Hacker News, VCSes, etc. because you can later correct typos, grammar errors, 
and clarity problems; but with email, once it’s sent, it’s unchangeable.  
Hence, I’ve been making increasing numbers of spelling, grammar, and clarity 
errors in mailing list posts.

This would be easy to build atop Fossil, being only a slight tweak on its 
normal use case.

> I would like to provide users the option to send messages formatted
> using Markdown.  Are there Markdown libraries available in TCL that I
> can use, that you know of?

This is another thing you’d get for free by building it atop Fossil.

Is there anything wrong with making this web/email feature set dependent on 
linking Fossil with the platform Tcl, so that you have access to the full Tcl 
ecosystem, as opposed to Jim Tcl?

That in turn would open the door to Tcl hooks.
___
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] "remember this password (Y/n)?" and `isatty()`

[Warren Young]

On Jun 8, 2018, at 2:47 AM, Eduard  wrote:
> Maybe it would be possible to add a command-line switch to force it to 
> remember the password, or a switch to make it pretend stdin is a tty?

It looks like that last is already available: -interactive.

I’m not aware of any place that all of the global options to Fossil are 
documented.  I had to dig through the command line parser in main() within 
src/shell.c to find it.

I’m not certain that this option will affect your symptom.  If not, let us know 
exactly what method you’re trying and what symptom you get when it fails, if it 
does.
___
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] Resolving recurring settings conflict

[Warren Young]

On Jun 7, 2018, at 7:04 PM, Warren Young  wrote:
> 
> I’ve set .fossil-settings/allow-symlinks to 1 in one of my repositories, so 
> in order to avoid the complaint from Fossil about a conflict, I also say 
> “fossil unset allow-symlinks” in the checkout.

There’s a related bug that I forgot to mention: the code that checks for 
settings conflicts is running before “fossil unset” is handled, so you get a 
bogus complaint about the conflict from the command that is resolving the 
conflict.  This can give the incorrect impression that your command didn’t do 
anything, but on giving another Fossil command, the conflict has indeed gone 
away.

…until you fossil conf pull all, of course. :)
___
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] style.css served with on settings conflict

[Warren Young]

On Jun 7, 2018, at 6:58 PM, Andy Goth  wrote:
> 
> how does the error logger know that its output will wind up inside CSS?

Is there any kind of “context” object that gets passed through the page 
rendering logic?  If so, the high-level code that generates the CSS can declare 
that the final destination is CSS, cluing the code that builds the error string 
into putting it inside a C-style block comment, or suppressing it entirely.

If not, then the context can be global.  It’s ugly, but it really is global 
context for that particular Fossil child/CGI handler.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Resolving recurring settings conflict

[Warren Young]

I’ve set .fossil-settings/allow-symlinks to 1 in one of my repositories, so in 
order to avoid the complaint from Fossil about a conflict, I also say “fossil 
unset allow-symlinks” in the checkout.

All is fine until I say “fossil conf pull all” command, whereupon the local 
setting comes back.

I’ve gone into Admin > Settings on the central repository and unchecked the 
setting and set it to 0 for good measure, but a conf pull still resets the 
local setting to 0, causing a conflict.

I then tried “fossil conf push all” and thereby blew away my user table and had 
to restore from backup.  I now see how that happened: I effectively said fossil 
conf push user.  I was incorrectly thinking that the following would push just 
the single settings change up to the server:

   fossil conf pull all
   fossil unset allow-symlinks
   fossil conf push all

And if you were wondering why I pushed “all,” it’s because “fossil conf --help” 
did not tell me a more plausible value for AREA.  I was expecting “settings” or 
similar.  None of the other options besides “all” look plausible.  Settings are 
neither email, nor project, shun, skin, ticket, user, or alias.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] style.css served with on settings conflict

[Warren Young]

The error prepended to web pages served by Fossil on settings conflicts is 
being prepended to the style.css file, causing the CSS to be considered invalid 
by Chrome, at least.

This should be done on HTML output only.
___
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] Show time...

[Warren Young]

On Jun 6, 2018, at 7:26 PM, Eduard  wrote:
> 
> Now all I need is a catchy name, like `chiselapp` :p

I put my fossils in /museum.  You are free to do the same. :)

___
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] Show time...

[Warren Young]

On Jun 3, 2018, at 7:28 PM, Richard Hipp  wrote:
> 
> So, if anybody sees any last minute tidying up that we need to do to
> the website in anticipation of a huge influx of first-time visitors,
> please speak up.  Quickly.

There are several nits to pick on the Fossil vs. Git page:

http://fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki

I’ve just checked in a few minor fixes to it.


One remaining issue that has been noticed before and is still outstanding is 
that in style.css, the rules for h2 and h3 have their sizes swapped, so that 
the subordinate header is rendered in a larger font.  I believe the simplest 
fix is that this:

.content h2 {
font-size: 1.05em;
font-weight: bold;
}

should be:

.content h3 {
font-size: 1.05em;
}

That is, we’ve got a simple typo here, h2 -> h3.

There is no need to bold the font explicitly, as that’s the default in all 
sensible browsers, but it’s harmless to include it.  If you feel it’s necessary 
to keep it, it should probably be done in h1 as well for consistency.


Another issue, which is much bigger, is that because the section 3 points 
expand on the summary table, it makes much the same points repeatedly.  
Sections 3.3, 3.4, and 3.7 could be merged.

Additionally, I think this document should explicitly ask the question, “Does 
your project look more like that of the Linux kernel, or more like that of 
SQLite?”  The comment about the low-friction path addresses this somewhat, but 
I think the focus should be more on these design decisions’ impact on the 
end-user experience than on the history that lead to the decisions.

I like the summary table, and I like the parallel to it in section 3, so maybe 
the simplest fix is to reorder these points to group them, then make these 
three sections 3.3.1, 3.3.2, and 3.3.3, with the superordinate section 3.3 
covering the common matters.

That in turn would require an h4 level, not something that is currently defined 
in style.css, but the default stylesheets should include not only that, but 
also h5.


Section 3.6 should mention git-worktree as a partial solution to this relative 
weakness of Git, but also discuss its unfortunate consequences and remaining 
weaknesses:

https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg25686.html


Section 4.1 repeats much of what’s in section 3.  I think you could drop the 
explanatory paragraph below the first three bold bullet points, as they now 
need no explanation.


I think timeline.rss is worth its own bullet point in section 4.1.  It’s not 
strictly part of Fossil UI; that would be /timeline.


In section 4.2, you should mention narrow and shallow clones.  Git has them, 
Fossil doesn’t.
___
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] How to link to licence file in fossil wiki

[Warren Young]

On May 11, 2018, at 7:21 PM, Will Parsons  wrote:
> 
> How could I come across this solution on my own?

Most of what it does is described here, which is well worth a read if you 
haven’t done so already:

   https://fossil-scm.org/index.html/doc/trunk/www/embeddeddoc.wiki

And if you have read it, it’s probably worth a re-read. :)  Fossil’s embedded 
documentation feature has some subtleties that typically take several passes to 
discover, such as the ckout feature.

This mimetype= query parameter override should be documented on that page, too, 
but currently is not.

> does it have something to do with the
> implementation of Fossil itself?

Yes.  Much of what you know about web technologies does not apply directly to 
Fossil because it isn’t reusing some existing web server; blog articles and 
such focused on Apache and nginx often won’t apply to Fossil.

Aside from this mailing list and the docs, I’ve found the Fossil source code 
helpful many times.  It’s reasonably straightforward code.  I’m pretty sure my 
knowledge of the way Fossil handles filename extension mappings to MIME types 
comes from reading the code, not from reading the docs, for example.
___
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] How to link to licence file in fossil wiki

[Warren Young]

On May 10, 2018, at 4:50 PM, Will Parsons  wrote:
> 
> I know (at least I think I know) that I can get the effect I want by
> making the file a Markdown file by renaming it LICENCE.md

Yes.  Scroll to the final paragraph of this Fossil wiki document for a case in 
point:

https://tangentsoft.com/pidp8i/wiki?name=A+Field+Guide+to+PDP-8+Assemblers

That link was made directly, with no mimetype trickery.

> I don’t want to do that.

MIME type detection in Fossil — as in most other HTML-via-HTTP servers — is 
based on file name matches, which generally means file name extensions.  That 
design allows the creator of the files to give a clear signal to the server 
what the Right Thing is in the specific case.

While Fossil could add RE patterns like ^.*/LICENSE$ to cover cases like yours, 
I think that’s a borderline violation of the principle of least astonishment.  
That is to say, it’s arguably wrong, though not unassailably so.

Another risky alternative is file content sniffing.  That’s fine for files with 
magic bytes, but it’s difficult to get right in all cases with plain text.  
Ever had your programmer’s text editor misidentify a file type and give you 
bogus syntax highlighting?  That’s what comes of trying to autodetect it.  It’s 
why many programmer’s text editors have an override mechanism that lets someone 
put a special comment into the file to force a specific interpretation.

> Traditionally files named README, INSTALL, and
> LICENSE/LICENCE have been plain-text files with no extension, and I'd
> like to keep it that way.

That philosophy was fine in the CLI-only world, where the computer user had to 
type a command to act on the file, so you had human intuition, training, and 
knowledge to aid in giving the right command, but in the modern world, we are 
often depending on the dumb computer to do something automatic, yet still 
“correct” by our human perceptions.  

Until we get generalized AI, that means we’re going to have to give the 
computer reliable clues to work with.  For binary files, that can be magic 
bytes, but for plain text files, file name extensions are the best the industry 
has come up with so far.

Other attempts, like file metadata tags (e.g. classic Mac OS 4-letter codes) 
have been rejected as causing more problems than they solve.
___
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] How to link to licence file in fossil wiki

[Warren Young]

On May 11, 2018, at 8:09 AM, Richard Hipp  wrote:
> 
> License

If that works, then I’d strongly suggest text/plain instead.  You don’t want 
Fossil to tell the browser that it should try interpreting ampersands and angle 
brackets in the plain text of the license.
___
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] Fossil 2.6: shm- and wal-files left behind

[Warren Young]

On May 9, 2018, at 12:44 PM, Florian Balmer  wrote:
> 
> With Fossil 2.6, sometimes there's *.fossil-shm and *.fossil-wal files left
> behind in the directory where the repository databases are stored.
> 
> This happens if an unversioned file is accessed through the /uv web
> interface for the second time (or more)

If “fossil server” or “fossil ui” is still running in the background, then I 
would fully expect the WAL and SHM files to still be around.  The worrying case 
is when they’re left behind after the SQLite-based process that created them 
has died.

> I'm aware this is not dangerous, as SQLite will recover any information
> from the leftover files, but nonetheless I'm reporting it.

If it’s the case that there are no active Fossil instances while those files 
are on disk, then yes, it’s good to report this, because it means the SQLite DB 
connection isn’t being shut down properly.
___
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] Recently added or enhanced /timeline query parameters

[Warren Young]

On Apr 28, 2018, at 1:07 PM, Richard Hipp  wrote:
> 
> (1) The new days=N query parameter shows all activity within the
> previous N days.

Nice!

I think this will end up being more useful than “max N any type,” as I 
frequently find myself fiddling with N as a project gets busy and then calms 
back down again.  I want it to show me one screen showing everything I want to 
see and no more; days is more likely to get me what I want than guessing at 
values of max N.

What would make it even more useful, though, is if it was part of the page UI 
and participated in the page load cookie, so that you wouldn’t have to keep 
resetting it with manual URL editing.

“Days" seems orthogonal to the options in the “Any Type” drop down, so how 
about if this setting is exposed via another drop-down between the “Max 
” bit and the type drop-down, offering the choice of “days of” or “of 
type”, defaulting to the latter for backwards compatibility?  The grammar when 
reading the line gets a little screwy, but short of changing plurals 
dynamically, I don’t know how you fix it:

1. Max 100 of type check-ins
2. Max 7 days of check-ins
3. Max 10 of type wiki
4. Max 7 days of wiki

> (3) Both the yw= and ymd= query parameters accept "now" to mean the
> current day or current week.
> 
> https://fossil-scm.org/fossil/timeline?yw=now
> https://fossil-scm.org/fossil/timeline?ymd=now

Very useful, especially for Agile organizations that schedule work by the week.

But, 2-week sprints are also very common.  “yw=fortnight” seems wrong, so how 
about yf=now to mean the current fortnight, yf=-1 to mean the previous 
fortnight, and yf=2017-01-01 to mean the first fortnight in 2017?

There are a few semantic questions here:

1. Does yf=-1 end at midnight-1 last Friday, last Saturday, or last Sunday?  
(The latter being for organizations that strictly start the week on Monday, 
considering Sunday part of “last week.”)

2. Does “yf=-1” use some definition of even and odd weeks in the year?  If not, 
users are going to get the trailing week of the previous sprint about half the 
time.  Someone coming into work early on Monday of a new sprint and looking at 
“yf=now” should always see a blank timeline, no?

Speaking of midnight, does all of this pay attention to the time zone setting 
in Admin, or is it using midnight UTC in its definition of “now”?
___
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] fossil: error while loading shared libraries: libssl.so.1.1

[Warren Young]

On Apr 6, 2018, at 7:20 AM, Tim Chase  wrote:
> 
>  $ ~/bin/fossil
>  fossil: error while loading shared libraries: libssl.so.1.1:
>  cannot open shared object file: No such file or directory

Given how frequently new security flaws are found in OpenSSL, I think it’s 
probably for the best that this one remain dynamically-linked.  Also, it’s 
pretty commonly available everywhere.

> I do have some libssl.so on the hosted box in question
> 
>  $ find /usr -name libssl.so\* 2>/dev/null
>  /usr/lib64/libssl.so.10
>  /usr/lib64/libssl.so.1.0.1e
>  /usr/lib64/libssl.so

Right, so the problem is simply that the binary you’re running was built on a 
different host platform than the one you’re actually trying to run the binary 
on.

If I were you, I’d build my own Fossil binary on a more similar system, so that 
it *dynamically* linked to OpenSSL 1.0 rather than to 1.1.

That emphasis is because you want package upgrades to give you new OpenSSL 
fixes ASAP without requiring that you remember to — or even realize that you 
need to — relink your Fossil binary to a static OpenSSL library.

> Begging and pleading for the hosting service
> in question to install fossil from their repos is likely out of the
> question because they're pretty horrible and I'm mostly moving stuff
> off them.

Not to mention that you say this is a Debian box, and Debian is still shipping 
Fossil 1.37, which probably isn’t what you want to be running now.
___
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] Why Fossil is so fast?

[Warren Young]

On Mar 26, 2018, at 2:45 PM, Warren Young <war...@etr-usa.com> wrote:
> 
> On Mar 26, 2018, at 2:15 PM, Svyatoslav Mishyn <svyatoslav.mis...@gmail.com> 
> wrote:
>> 
>> Here are results of r.sh when stress.sh was run (and all RAM was used
>> on VPS):

I’ve thought a bit more about this stress.sh script.  It is based on ab, which 
I presume is the Apache Benchmark program.  You aren’t giving it -C, which 
means it’s just bouncing off that URL and sending you back to the login page on 
each HTTP hit.  Thus, it is not at all like a real user trying to use the 
fossil-scm.org repository remotely.

Monitor your HTTP traffic to the Fossil server, and I think you’ll see that you 
aren’t actually pulling vdiffs with this test.

> It is bad science to change more than one variable at a time.  You’ve got a 
> multiply confounded result set here.

It might help to list the confounding factors:

1. Different network path between the two servers under test.

2. Different hardware for each server.

3. Probably different VPS technology on each host.

4. Different repository?  (It’s not clear to me whether you’re working with a 
clone of the same repo on both sides.)

5. Real users vs ab(1) faux users.

You can’t isolate causes until you control for each of these variables.

On top of that, you’re taking Fossil’s reported time deltas as if they’re 
high-quality benchmark data, when I’ve already shown that the numbers are 
biased by +1ms, which is on the order of the time differences you’re working 
with.  You need to be getting your timing information from a purer source.
___
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] Error on commit

[Warren Young]

On Mar 26, 2018, at 1:27 PM, Scott Doctor  wrote:
> 
> aborting due to prior errors

I’ve seen that sort of message on “fossil update” when a local file is marked 
read-only and the file was changed on the remote system.

Obviously that is not exactly what is happening here, but the broader point is 
that if errors occur during a Fossil operation, the SQL-level COMMIT will be 
rolled back, which Fossil then takes as a cue to roll your local checkout 
directory back to *its* prior state.

It might be simplest to make a clean checkout of the repository into a separate 
directory, copy all of the changed files over from the broken checkout, then 
check them in from the clean checkout directory.

If that works, then I would look at local file permissions.

You’re doing this on Windows, yes?

> I tried to do a commit as I have not done so in a while

Commit early, commit often!  If you’re not yet ready to modify the trunk, do 
your work on a feature branch, then merge when the feature branch is stable.

I’ve had work days with *dozens* of commits.
___
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] Why Fossil is so fast?

[Warren Young]

On Mar 26, 2018, at 2:15 PM, Svyatoslav Mishyn  
wrote:
> 
> Here are results of r.sh when stress.sh was run (and all RAM was used
> on VPS):
> 2018-03-26-19:34:08 time generation: 0.001s; load average: 10.909180
> 2018-03-26-19:34:11 time generation: 0.001s; load average: 10.909180
> 2018-03-26-19:34:14 time generation: 0.001s; load average: 12.918450
> 2018-03-26-19:34:15 time generation: 0.001s; load average: 12.918450
> 2018-03-26-19:34:18 time generation: 0.001s; load average: 14.767090
> 2018-03-26-19:34:22 time generation: 0.001s; load average: 14.767090
> 2018-03-26-19:34:24 time generation: 0.001s; load average: 16.547850
> 
> and against fossil-scm.org itself (only r.sh):
> 2018-03-26-20:01:03 time generation: 0.003s; load average: 0.11
> 2018-03-26-20:01:07 time generation: 0.004s; load average: 0.10
> 2018-03-26-20:01:13 time generation: 0.003s; load average: 0.09
> 2018-03-26-20:01:20 time generation: 0.003s; load average: 0.08
> 2018-03-26-20:01:26 time generation: 0.003s; load average: 0.07
> 2018-03-26-20:01:29 time generation: 0.003s; load average: 0.07
> 2018-03-26-20:01:32 time generation: 0.003s; load average: 0.06

I don’t see that you’ve factored out the TCP connection round-trip time.  Even 
from one datacenter to another datacenter on the same continent across a fat 
Internet backbone, a TCP connection still takes at least half a millisecond.  
Across continents, it becomes tens or hundreds of ms, and when you involve the 
residential ISPs, it can be even longer.

It is bad science to change more than one variable at a time.  You’ve got a 
multiply confounded result set here.
___
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] Why Fossil is so fast?

[Warren Young]

On Mar 24, 2018, at 5:11 PM, Svyatoslav Mishyn  
wrote:
> 
> just noticed that page generation of many of my repos is 0.001s.

The calculation for that is in the skin’s Footer code:

[expr {([utime]+[stime]+1000)/1000*0.001}]

In TH1, the utime and stime functions return microseconds, so + 1000 means “add 
one millisecond”, so that when dividing microseconds down to seconds with the 
subsequent arithmetic, the resulting value can never be lower than 0.001s.

It would probably be more mathematically defensible to use + 500 instead to 
round to the nearest millisecond, but that might confuse people when people see 
that it claims to have run in “0.000s”, since it obviously did not run 
instantaneously.

Another mathematically defensible change would be to report that the page 
generation took “less than” the reported amount of seconds.

(Not “less than or equal to,” since a generation time of exactly 1000 µs would 
yield “0.002s” from the above calculation.)

> And that result is identical for many web-pages,
> only difference was for some /search request
> and some heavyweight check-in pages.

Your point?

If we back out the “round up to next millisecond” arithmetic explained above, 
an “0.001s” generation time report means the actual wall time to build the page 
was somewhere under 1ms.

On a 3 GHz CPU, a clock cycle is ~0.33ns, and many Intel CPU instructions do in 
fact take about 1 cycle.  Of those that take multiple CPU cycles, you can often 
wave way the difference with pipelining and speculative execution.  Thus, to a 
first approximation we have enough time to run about 3 *million* CPU 
instructions.

The wonder of it all is not how Fossil can manage to construct a few kilobytes 
of HTML by using millions of CPU instructions, but that we’ve ended up in a 
world where we’re uncertain about whether millions of CPU instructions are 
sufficient to accomplish the task!

> I compared page generation speed with some other Fossil repositories:
> Fossil itself, SQLite, Tcl
> using the same pages which are not strictly related to
> repository size and age: like
> /help, /sitemap, /stat, /wiki, /version?verbose
> 
> and on these repos I got various timings after refreshing page,
> while on mine always 0.001s

You are presumably using a new or at least young repository, thus the various 
log(N) operations are using very small values of N, thus take very few CPU 
cycles to execute.  Additionally, you are doing this on a system that is not 
under load, and which has hot RAM and mass storage caches.

To this, you are comparing other repositories with large N, which probably have 
other concurrent users at any given time, and which are likely to have quite a 
few cache misses.

Naturally your repository is “faster”.  Put it under the same loads, and it 
will slow down as well.
___
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] one Fossil SCGI process for several domains

[Warren Young]

On Mar 21, 2018, at 3:53 PM, Svyatoslav Mishyn  
wrote:
> 
> a.example.net conf:
> location / {
>include scgi_params;
>scgi_pass 127.0.0.1:9000;
>scgi_param REQUEST_URI /fossil_repo_a$request_uri;
>scgi_param SCRIPT_NAME "";
> }
> 
> b.example.net conf:
> location / {
>include scgi_params;
>scgi_pass 127.0.0.1:9000;
>scgi_param REQUEST_URI /fossil_repo_b$request_uri;
>scgi_param SCRIPT_NAME "";
> }

What I do here instead is to run a separate Fossil instance for each 
repository, each bound to a separate TCP port. So, hits on a.example.net 
 are redirected to port 9000, hits on b are redirected 
to port 9001, etc.

That is, I’m not using the /repolist feature at all. Each Fossil instance is 
pointed at a single *.fossil file.___
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] "Not found" error--not understanding

[Warren Young]

On Fri, Mar 16, 2018 at 6:52 AM, Kevin Walzer  wrote:

> On 3/16/18 7:06 AM, Richard Hipp wrote:
>
>> it seems good to move the
>> Fossil binary outside of your web hierarchy.  Perhaps put it in
>> /home/username/bin.
>>
>
> Moving the fossil binary into a different directory helped


That sounds like you were running into SELinux or some other MAC system. It
is common for these systems to be fairly strictly configured for the
standard cases to reduce security problems. In this case, your MAC system
"knows" that the web document root should have only read-only files, so it
refuses to allow writes to that tree by the web server, and it refuses to
allow the web server to execute programs in that tree.

Although these defaults happened to be incorrect for your particular use
case, it is usually better to conform to the MAC system's default
expectations, rather than to reconfigure it to match your wishes. Security
defaults are usually set that way for good reasons, so unless you've got a
lot of expertise in this area, you're probably not in a good position to
second-guess the MAC system's defaults.
___
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] One mouse click to see all the tickets

[Warren Young]

On Sat, Mar 17, 2018 at 4:42 AM, J Ronald  wrote:

>
> steps now:
> 1. click tab "Tickets"
> 2. click "All Tickets"
>
> steps I want:
> 1. click tab "Tickets"
>

Go to Admin > Skins and edit the Header part, changing the default location
for the Tickets link from "/ticket" to "/rptview?rn=1".

I would suggest a refinement, however: set up at least two other reports,
one for open bug report tickets and another for open feature request
tickets, then use the Admin > URL Aliases to assign them sensible aliases
like /bugs and /wishlist. Then you can exchange the default Tickets tab in
the header for two tabs, "Bugs" pointing to
"/bugs" and "Wish List" pointing to "/wishlist".

I've done just that in this repository: https://tangentsoft.com/pidp8i/

If you clone that repository and then open it locally with "fossil ui", you
should have the permissions you need to get into Admin and poke around to
see how I have done this.
___
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] Moving Wiki/MD files between Wiki list on web UI and source tree, and previewing

[Warren Young]

On Mar 13, 2018, at 11:33 AM, Warren Young <war...@etr-usa.com> wrote:
> 
> The examples above both show how you can have a common list of documentation 
> that points to multiple sources.  My project’s example shows a 
> manually-curated list, whereas the Fossil project example shows an 
> automatically-generated index, done with the www/mkindex.tcl script in the 
> Fossil source tree.

Also, realize that the links at the top of each Fossil UI page are just 
elements of the Header part of the skin.  drh has pointed his “Docs” link to 
his script-generated permuted index, and in my PiDP-8/I project, I’ve adjusted 
the “Wiki” link to point to /wcontent rather than to /wiki, which I think makes 
more sense.

The point is, you’re not required to accept the Fossil-provided wiki link if it 
isn’t suiting your purposes.
___
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] Moving Wiki/MD files between Wiki list on web UI and source tree, and previewing

[Warren Young]

On Mar 13, 2018, at 9:43 AM, Tony Papadimitriou  wrote:
> 
> 1. I have some Wiki/MD files created from the web UI.  Can I move them to the 
> source tree and still keep access to them from the web UI?

That’s the whole point of the embedded documentation feature:

   https://fossil-scm.org/index.html/doc/trunk/www/embeddeddoc.wiki

Examples:

1. Everything in Fossil’s own permuted index is embedded documentation:

   https://fossil-scm.org/index.html/doc/trunk/www/permutedindex.html

2. Scroll to the bottom on the home page of my PiDP-8/I project; much of the is 
embedded documentation, which you can tell by the “/pidp8i/doc/trunk” prefixes 
in the URLs:

   https://tangentsoft.com/pidp8i/wiki?name=Home

Many of those links are also to unversioned content, which provides a useful 
tradeoff in some cases:

   https://fossil-scm.org/index.html/doc/trunk/www/unvers.wiki

> And the reverse.

I’m not quite sure what you mean by that.

If you’re simply asking if you can take an embedded document’s content and 
create a wiki article from it, of course you can.  The URL will change, but if 
that’s a problem, you can fix that at the front-end proxy layer with URL 
rewriting.  The URL aliasing feature added in 2.4 might also help.  (Admin > 
URL Aliases.) 

> 2. I have some Wiki/MD files in the source tree (which I can see with the 
> http://repo/doc/version/filename.[md/wiki] link) but I cannot figure out how 
> to associate that link as a Wiki page shown in the Wiki list of the Web 
> interface.

The wiki and embedded docs are different things, useful for different purposes.

A document goes in the wiki when its history is not tied to the history of the 
repository itself: when you roll back to a prior version in the timeline, 
“fossil ui” continues to show the newest version of all wiki documents, whereas 
embedded documentation rolls back to contemporaneous versions.  Therefore, use 
the wiki for “evergreen” content, and the embedded documentation feature for 
documentation that evolves in lockstep with the repository content.

The examples above both show how you can have a common list of documentation 
that points to multiple sources.  My project’s example shows a manually-curated 
list, whereas the Fossil project example shows an automatically-generated 
index, done with the www/mkindex.tcl script in the Fossil source tree.

> 3. Is there a more ‘immediate’ command-line method to review my source-tree 
> Wiki/MD file(s) before committing my changes?
> I mean some way to see how the Wiki/MD will actually show.  Can I do ‘fossil 
> ui’ followed by some option to do this?

You’re looking for the “ckout” special name, documented here:

   https://fossil-scm.org/index.html/doc/trunk/www/checkin_names.wiki

You use it in place of “version” in the example URLs you give in your original 
post, rather than “trunk” or some other version tag.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users