Re: [fossil-users] Fossil's (lack of) use of the Ticket system

[Shal Farley]

On 2018-08-04 4:48 AM, Gilles wrote:
It might, since forum softwares (should) provide "sticky posts" that 
are displayed at the top.


The one trick I've seen that seems most effective is to integrate the 
search function with the New Topic function such that the user is 
presented with a dynamic drop-down of suggested posts while typing their 
subject line.


People accustomed to that behavior in Google search may find it natural 
to select an existing subject text to see what's there.


Shal Farley 
Cheshire Engineering Corporation
+1 626 303 1602
http://www.CheshireEng.com


___
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

[Shal Farley]

On 2018-08-02 1:57 AM, Pietro Cerutti wrote:
Send out the whole content of a post, and you'll have a mailing-list. 


Well, the distribution half of a mailing list anyway.

Devise a mechanism to allow replying to such an email and sync it with 
the forum, and you'll have made a gian leap forwards in dismantling 
the web/email barricade.


That's what most mailing lists (those with on-line archives) do. 
Visiting the archive is purely optional, it's there in case you didn't 
keep a message or just joined and want to read-up before asking "dumb" 
questions.


However as others have mentioned having inbound email processing, unless 
very carefully handled, would defeat the initial purpose: to stop 
wasting drh's time dealing with spam, and particularly the annoying spam 
that was being sent directly to list members after they post. Not long 
ago I got several score of those based on a posting from years ago.


For my part, as long as the notifications contain the message body text 
I'm fine with having to go to the web forum to reply.


In answer to DD's caveat, I'm even fine with having to go to the forum 
to get context for the occasional post which needs it; but even in a 
forum where quoting when you reply is uncommon or unheard of, I find 
that I usually have enough context from just the emails.


Shal


Shal Farley 
Cheshire Engineering Corporation
+1 626 303 1602
http://www.CheshireEng.com

___
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...

[Shal Farley]

On 2018-06-14 1:47 PM, Warren Young wrote:

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.
In Groups.io  creating and using a password is 
optional, because some users expect logging into a web site to work that 
way. The other method is having the site email you a login link whenever 
you need a new session.



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.
That is a valid criticism of Groups.io's technique. On the other hand, 
it is a mailing list service - in some regards an extension of your 
email service. Just don't post your most guarded secrets to the list.



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, 
and the reason I spoke up here in the first place. That and the deep 
development effort required and ongoing maintenance to keep up with the 
changing deliverability landscape as mailbox providers evolve their 
anti-abuse defenses.


As I said in my first, 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. 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.


Yes, I'm a mailing-list advocate, and hence a dinosaur. Which, on /this/ 
list in particular, is about the most hilarious insult I've seen in 
quite some time.


Shal

___
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...

[Shal Farley]

On 2018-06-13 7:05 AM, Richard Hipp wrote:

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?


Groups.io  supports Markdown (web posting only). 
Messages composed in markdown are converted to HTML before sending to 
the subscribers.


It also supports editing of messages in the archive, with a wiki-like 
revision history. And a Wiki on the side.


Shal

___
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...

[Shal Farley]

On 2018-06-13 4:28 AM, Richard Hipp wrote:

Unfortunately, I'm going to need to shut down this mailing list due to
robot harassment.  I am working to come up with a fix or an
alternative now.  Your suggestions are welcomed.
If you're open to a commercial mailing list with web archive features 
I'd recommend Groups.io  over either a Yahoo Group 
or Google group. It has the key advantage of being under active 
development by a developer with deep experience in mailing lists and a 
commitment to bring them into the modern world. It is also run on a 
"freemium" business model which means no ads or tracking/selling of user 
info.


Too, if you can export the current MailMan archive as an mbox file they 
can import it for you. The web interface provides search and browse 
capability for message threads as well as reply and new topic posting. 
The email interface provides full subscription management support 
(subscribe, unsubscribe, digest or individual messages, and topic muting 
or following) for those who don't want to bother with the web interface.

The most recent problem is that robots are visiting the subscription
page and entering innocent user's email addresses and names.  This
causes a confirmation email to be sent to that user.  If it were just
single confirmation email that the user could ignore, that would be
fine.  But apparently MailMan sends one email for each subscription
request.  The robots have figured this out and are putting in hundreds
of subscription requests for the same individual, apparently to harass
them.
I don't know if Groups.io has a specific countermeasure for this novel 
form of abuse, but the developer would no doubt take care of it were the 
problem to follow you. I can inquire (or you could) at supp...@groups.io 
if you're interested.


I haven't heard of any of their user lists being afflicted by anything 
like the porn spammer that has cropped up here, but as you know since 
that happens entirely off-list there's not much that can be done about 
it by any list software. There has been talk (in their "suggestion box" 
list) of having "anonymous" groups where the outbound messages would not 
contain the poster's email address; but that hasn't been implemented yet 
and it isn't clear that the users of this list would want that anyway.


One of the reasons I suggest this is that Mailing list implementation 
and support can be a bit of a rabbit-hole, particularly with ongoing  
deliverability challenges like DMARC, FBLs, and other over-aggressive 
spam blocking by mailbox services. Groups.io works those problems so you 
don't have to.


That said, I don't necessarily want to discourage you from considering a 
roll-your-own forum or list facility as others have been discussing, if 
you would enjoy doing that or if you envision a killer advantage.


Shal
List Owner: GroupManagersForum 
Recovering Yahoo Group 
 power user


___
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] Couple of beginner questions

[Shal Farley]

Warren,

> Someone brought up TECO. I don’t expect anyone’s TECO implementation
> to handle UTF-8,

Hmm... I was going to say in jest that the DECUS swap tapes have a 
version written in C, were anyone nuts enough to take a crack at it. 
However Google reveals that it is closer at hand than I thought - 
someone has already ported it to Windows, Mac and Linux:

https://github.com/blakemcbride/TECOC

As someone who once wrote ad-hoc utilities as TECO macros, all I can say 
is: No.


Shal

--

Shal Farley
Cheshire Engineering Corporation
+1 626 303 1602
http://www.CheshireEng.com


___
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] remote check in

[Shal Farley]

Scott,

The problem I am having is how to add files, do check-ins and such via 
the UI, mostly regarding doing it remotely without command line access.


I'm far from an expert user of fossil, but I believe the normal setup is 
to have a local copy of the repository, where command line access is 
simple and direct, and use fossil's sync feature to deliver checkins to 
remote servers.


In a multi-developer situation each developer would work with their own 
local repositories, in sync with a common server.


Shal

--
Shal Farley
Cheshire Engineering Corporation
http://www.CheshireEng.com


___
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] remote check in

[Shal Farley]

K,

It would be helpful to the other members of this list if you would not 
chime in with provocative non-sequiturs when you don't know the answer.


Just my humble opinion.

Shal
(see, you trolled me out of my lurking state)

--

Shal Farley
Cheshire Engineering Corporation
http://www.CheshireEng.com


On 10/22/2016 3:52 PM, K. Fossil user wrote:

Hi,

1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
...
___
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] diff after update

[Shal Farley]

On 9/11/2015 7:11 AM, Richard Hipp wrote:
>
> "fossil diff --versus-undo" maybe???

Along the same lines, how about:

"fossil diff --updated"

The semantics being it is a diff of the things you just updated 
(implicitly with respect to what they were before the update command).


-- Shal


--
Shal Farley s...@cheshireeng.com
Cheshire Engineering Corporation  http://www.CheshireEng.com
120 West Olive Avenue+1 626 303 1602
Monrovia, CA 91016   FAX +1 626 303 1590
___
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 force text for all files?

[Shal Farley]

Stephan,

> If it has ANY bytes above 127, it's not, by definition, ASCII. i.e.
> "it's binary."

I would disagree with part of this statement. I agree that ASCII defines 
only the 7-bit code values, but I think this whole thread has run off 
the rails in talking about the content values as determining whether the 
file is "text" or "binary".


But this discussion of content heuristics misses the point of why there 
is a distinction to be made in the first place. And that I think has 
more to do with whether the content is organized into "lines".


In a functional sense for Fossil, a "text" file is one for which it is 
useful to display a line-oriented difference. For all other files 
("binary" files) the difference can only be displayed in a way that is 
agnostic of the internal structure (if any) of the content.


Given that there is no universal heuristic for discriminating "text" 
from "binary" files based on content, that determination must be treated 
as a bit of metadata about the file.


Likewise, it is necessary to know for a given file what representation 
is used to separate lines. Knowledge of the line separator is seldom 
carried as metadata, because it is usually uniform in a given system. 
But in these days of interoperable systems and multi-platform support, 
this detail also may be a necessary piece of metadata to know about a 
file. ASCII code calls out the CR (carriage return) and LF (line-feed) 
control characters. DOS-based systems (including Windows) follow the 
direct ASCII tradition of using CR and LF, paired in that order (and 
often represented as CRLF) as the line separator. That tradition is also 
embodied in the Internet Mail standards for message content, header and 
body (absent MIME extensions). Unix-based systems use the LF character 
alone as the line separator in files (aka "newline"). Other systems have 
used CR alone.


And additionally, the character set used to represent text in a file 
must also be carried as metadata (because of the ISO-8859 and other 
code-page based character sets).


Only if all these items of metadata are known can the file content, or 
differences in the file content, be displayed in a useful form. So 
returning to this thread, it is convenient to have a heuristic that 
works most of the time to discriminate "text" from "binary" files, but 
it is necessary to also have a way for the user to explicitly provide 
that metadata (and ideally the character set metadata).


-- Shal

___
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] File contains invalid UTF-8, but is not UTF-8.

[Shal Farley]

Andy,

> If no characters between 128 and 255 are valid UTF-8, and they can
> never be valid UTF-8  characters, and are used by many  encodings,
> why doesn't Fossil simply ignore them when they  are committed?

I think Stephan said it poorly. A solitary byte in that range is never 
valid UTF-8, but UTF-8 represents all code points higher than 127 as a 
sequence of bytes in the 128 to 255 range. Those byte sequences have a 
structure, so it is possible to tell if a string of bytes in that range 
represents a valid UTF-8 sequence.


-- Shal

--
Shal Farley s...@cheshireeng.com
Cheshire Engineering Corporation  http://www.CheshireEng.com
120 West Olive Avenue+1 626 303 1602
Monrovia, CA 91016   FAX +1 626 303 1590
___
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 is changes or status trying to tell me when it lists files as "MISSING"?

[Shal Farley]

Stephan,

Here's what I propose for the help text:

-
Usage: fossil update ?OPTIONS? ?VERSION? ?FILES...?

If FILES is omitted, all files in the current checkout are subject to 
being updated and the version of the current checkout is changed to 
VERSION. Any uncommitted changes are retained and applied to the new 
checkout.


If one or more FILES are listed after the VERSION then only the named 
files are candidates to be updated, and any updates to them will be 
treated as edits to the current version. Using a directory name for one 
of the FILES arguments is the same as using every subdirectory and file 
beneath that directory.


The VERSION argument can be a specific version or tag or branch name.
If the VERSION argument is omitted, then the leaf of the subtree
that begins at the current version is used, if there is only a single
leaf.  VERSION can also be "current" to select the leaf of the current
version or "latest" to select the most recent check-in.

The -n or --dry-run option causes this command to do a "dry run".  It
prints out what would have happened but does not actually make any
changes to the current checkout or the repository.

The -v or --verbose option prints status information about unchanged
files in addition to those file that actually do change.

Options:
  --case-sensitive  override case-sensitive setting
  --debug  print debug information on stdout
  --latest acceptable in place of VERSION, update to latest version
  -n|--dry-run If given, display instead of run actions
  -v|--verbose print status information about all files

See also: revert
-

Hopefully I've concisely described what is true, but not too concisely. 
I am somewhat concerned with the phrase "any updates to them will be 
treated as edits to the current version" -- I'm hoping that clearly 
enough says that the checkout's version remains unchanged, that the 
checkout is not updated to VERSION in the FILES case.


-- Shal


On 6/27/2014 7:57 PM, Stephan Beal wrote:

On Sat, Jun 28, 2014 at 2:37 AM, Shal Farley wrote:

...
What neither help update nor fossilbook20 section /5.2.9 update/
says is that if you specify a file or path then it does NOT change
the version of the current checkout to VERSION. The text says it
does and does not mention this exception.


i'm not clear what you're saying there. The book is maintained by a 3rd
party, but i don't mind updating the fossil-side docs if you can suggest
an improved wording over the current text.



--
Shal Farley s...@cheshireeng.com
Cheshire Engineering Corporation  http://www.CheshireEng.com
120 West Olive Avenue+1 626 303 1602
Monrovia, CA 91016   FAX +1 626 303 1590
___
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 is changes or status trying to tell me when it lists files as "MISSING"?

[Shal Farley]

stephan,

>> In the literal sense, yes. But (if I'm getting this right) the deeper 
>> message was that the checkout knew about them because it itself was not 
>> updated to the "latest" commit - the one in which I'd rm'd the files. 
>> Hence my confusion over "MISSING from what?".
>
> Your understanding is incorrect: MISSING only appears when the checkout 
> knows about a file because that file is listed in that version, and yet 
> the files does not exist on the disk. MISSING does _not_ appear for 
> files which are listed only in other versions.

You and I are saying the same thing. The current checkout in this sandbox was 
still at the version it had been, the version that knew about those files. My 
mistake was thinking that my use of "update latest [path]" had changed the 
checkout to the "latest" version - that latest version is where the files had 
been rm'd.

> Someone had deleted them locally.

Correct, I had moved them out of this sandbox. Those particular files should 
never have been part of any project sandbox and should never have been 
committed. I didn't realize they were there until I was doing some work in 
another sandbox, and rm'd them there, and then committed that as the "latest" 
version.

-- Shal

___
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 is changes or status trying to tell me when it lists files as "MISSING"?

[Shal Farley]

stephan,

>> In this case what MISSING was really trying to tell me was that my 
>> sandbox wasn't at the revision I thought it was.
>
> That's not quite right - MISSING means that the checkout knows about the 
> files, but can't find them (because you rm'd them).

In the literal sense, yes. But (if I'm getting this right) the deeper message 
was that the checkout knew about them because it itself was not updated to the 
"latest" commit - the one in which I'd rm'd the files. Hence my confusion over 
"MISSING from what?". 

I learned what had happened when a coworker suggested using timeline, and that 
showed that my current checkout was still at the version it had been when I 
last committed it (which was two commits earlier than those made in another 
sandbox). So yes, those files were now MISSING from that version.

>> What neither help update nor fossilbook20 section /5.2.9 update/ says is 
>> that if you specify a file or path then it does NOT change the version 
>> of the current checkout to VERSION. The text says it does and does not 
>> mention this exception.
>
> i'm not clear what you're saying there. The book is maintained by a 3rd 
> party, but i don't mind updating the fossil-side docs if you can suggest 
> an improved wording over the current text.

Thanks! I'll ponder a good way to say what I now understand, then you can 
verify that I'm saying something true.

-- Shal

___
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 is changes or status trying to tell me when it lists files as "MISSING"?

[Shal Farley]

Richard,

Ok, thanks.

Rather than be too clever, revert followed by update cleared this up for 
me. Sort of the same answer, revert put the missing files back, update 
deleted them, and now my status has no complaints, as it should be.


In this case what MISSING was really trying to tell me was that my 
sandbox wasn't at the revision I thought it was - I'd confused myself by 
using update with a pathname to update all the files except those I 
didn't want it to delete.


What neither help update nor fossilbook20 section /5.2.9 update/ says is 
that if you specify a file or path then it does NOT change the version 
of the current checkout to VERSION. The text says it does and does not 
mention this exception. What fossil actually does (leaves the checkout 
at whatever version it was at) makes logical sense once you understand 
what's going on. Still, for the sake of newbies, the help and/or the 
book ought to be clear on this rather fundamental point.


-- Shal


On 6/27/2014 4:23 PM, Richard Hipp wrote:

I think your next "commit" attempt will fail unless you either "fossil
rm" the missing files, or create files with appropriate names so that
they are no longer missing.


--
Shal Farley s...@cheshireeng.com
Cheshire Engineering Corporation  http://www.CheshireEng.com
120 West Olive Avenue+1 626 303 1602
Monrovia, CA 91016   FAX +1 626 303 1590
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] What is changes or status trying to tell me when it lists files as "MISSING"?

[Shal Farley]

These are files which I had previously committed in this sandbox, 
checked out in another sandbox, realized during some development in that 
sandbox that they shouldn't have been in the repository in the first 
place and rm'd them there.


Now I'm back in the original sandbox and have updated, mostly 
successfully. Except that I had moved those files outside the sandbox 
(to where they belonged) rather than letting the update outright delete 
them. Info on those files says "no such object:", which is comforting, 
but somewhere fossil is remembering that they had been here.


So the question is, can I ignore the "MISSING" designation and go on 
with editing and committing in this sandbox without further complaint, 
or is there something I should do about them now? I don't want to be 
forevermore told that those files are MISSING.


I suppose I could put a copy of them back and let update delete the 
copies, but that seems rather pointless.


Section /5.2.5 status/ of fossilbook20 is rather sparse. It could use a 
table of the possible status values (EDITED, MISSING, etc.), and what 
they imply about the files.


-- Shal
(A fossil newbie, with some CVS experience)


--
Shal Farley s...@cheshireeng.com
Cheshire Engineering Corporation  http://www.CheshireEng.com
120 West Olive Avenue+1 626 303 1602
Monrovia, CA 91016   FAX +1 626 303 1590
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users