Re: [fossil-users] Fossil update
On 11/7/18, 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. > > Also, the Timeline now seems to show only one branch at a time while the > old version has shown all changes and different branches were > represented by different colours and a graphically displayed line. Those features should be unchanged. If you visit the canonical Fossil self-hosting repo (https://fossil-scm.org/fossil/timeline) or the SQLite Fossil repository (https://sqlite.org/src/timeline) you can see that both of those show all branches using color codes. I do not know what might be causing your problem. Can you provide an example? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil update
On 11/7/18, Zoltán Kócsi wrote: > > Is the latest Fossil binary compatible with the 1.29 version on the > repo file level? That is, will it be able to read the old SQLite file > and modify/update its schema to the latest version without losing > anything? Yes. In fact, I don't recall any major schema changes going from 1.x to 2.x. The big change there, and the reason for the major version number bump, was adding support for SHA3 hashes. 1.x supported only SHA1 hashes. 2.x supports both SHA1 and SHA3. Thus 2.x will read and understand 1.x repos, but 1.x cannot decode 2.x repos. If I had to guess (with so little information) about why you are not seeming to sync, I would suspect that somebody in your organization is using a 2.x version of Fossil and has done one or more commits that use a SHA3 hash. The older 1.x versions cannot understand that and are pretending those checkins do not exist. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] This mailing list is now deprecated
On 8/8/18, Philip Bennefall wrote: > > I am still getting stuck on the registration screen due to the captcha. > What parts do I miss if I don't have an account for now? I have added you as a verify subscriber. You should be getting forum notifications now, without the need to fill in the captcha. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] This mailing list is now deprecated
On 8/8/18, joerg van den hoff wrote: > > > On 08.08.18 14:40 , Richard Hipp wrote: >> Please discontinue use of this mailing list except as an emergency >> back-up to the forum in case the forum stops working. If forum is not >> working, you can also send email directly to me. > > > well no luck here. this: > > An email has been sent to "veedeeh...@gmail.com". That email contains a > hyperlink that you must > click on in order to activate your subscription. > > simply has not happened so far (>5-10 minutes since subscribe). > Check your spam folder? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] This mailing list is now deprecated
The new "forum" feature of Fossil is now live on the self-hosting website: https://fossil-scm.org/forum The forum feature is intended as a replacement for mailing lists like this one. Though still very "beta", I believe in eating ones own dogfood, and hence I am cutting over to the forum for Fossil itself. There is a "subscribe" option on the link above where you can sign up for email notifications to new forum posts. The enhance email notification should work just like a mailing list, with individual emails for each forum post containing complete post content and correct In-Reply-To headers. The only major difference between the forum and this list is that you must go to the forum website to post new content. New submissions via email are disallowed as an anti-spam measure. The Fossil homepage now has a link to the forum instead of a link to mailing list sign-up. Please discontinue use of this mailing list except as an emergency back-up to the forum in case the forum stops working. If forum is not working, you can also send email directly to me. After we have shaken out the forum feature a little further, I will shut down this legacy mailing list. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Who runs Fossil servers on Windows?
If you are running a Fossil server on Windows, please share with me how you set it up. You can respond via private email directly to me if you like. (1) Run using "fossil server" (2) Run using "fossil winsrv" (3) Using Apache with CGI (4) Using Apache with SCGI (5) Using Nginx with SCGI (6) Via SSH using some kind of SSHD for Windows (7) Some other webserver (please specify) (8) Other (please specify) I have the impression that most if not all Fossil servers on Windows are run using either (1) or (2). If you are using any of the other approaches, then I especially want to hear from you. Thanks. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
On 8/7/18, Andy Bradford wrote: > Does it make sense to have backoffice_run() in the SSH transport? If > not, then your fix is apropos. yes, we do want backoffice to run for SSH transport. My "fix" is really a work-around, not a true fix. We need to devise a proper fix for this, but I don't yet have a vision of how to do that. I'm in the process of writing a long post of the "forumtest1" site now that tries to discuss the problems and asks for ideas for a solution. I'll send follow-up email to this list when that post is up. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
Please build the from the tip of the forum-v2 branch and let me know whether or not it is working for you. On 8/7/18, joerg van den hoff wrote: > > > On 07.08.18 00:36, Richard Hipp wrote: > > On 8/6/18, joerg van den hoff wrote: > >> question: the observation that it seemingly is related specifically to > >> repos holding uv files is unimportant/irrelevant? or does that have > >> implications where to look? > > > > This is not much help in debugging. But it is helpful to you in > > bisecting, because it allows you to quickly and easily determine if a > > particular various is working or not. > > > > BTW, when doing the bisect, be sure to use the same Fossil version on > > both ends of the SSH connection. We do not know on which end the > > problem exists, so it is better to eliminate that variable. > > > >> then I do wish you much success with achieving that, of course. > > > > Your assistance in bisecting the delay problem is a step in that > > direction. Thanks. > this is what I've got: > > bisect complete >1 BAD 2018-07-31 23:38:39 71260ba25e79f4aa > # error message, clone fails >5 BAD 2018-07-24 22:01:12 42d821a714d092a8 > # error message, clone fails >7 BAD 2018-07-19 18:54:39 ac6657e2d35c974d > # clone hangs infinitely, no error message >9 BAD 2018-07-19 17:22:04 ada7ecde5bf91e18 > # clone hangs infinitely, no error message > 10 BAD 2018-07-19 16:27:51 f525b6d5e9dcb775 > # clone hangs infinitely, no error message > 11 BAD 2018-07-19 15:58:36 a32a92d227be5663 CURRENT > # clone hangs infinitely, no error message >8 GOOD2018-07-19 15:52:43 aa17077eafbbad37 >6 GOOD2018-07-18 19:22:31 752ea432d1cf20fa >4 GOOD2018-07-14 20:11:37 023ce4edde8ceb2d >3 GOOD2018-06-23 15:48:49 aeb98be80f1d51f5 >2 GOOD2018-01-07 21:38:26 5b558bc76bb9fb5f > > so the last good one is aa17077eafbbad37. > > NOTE: > 1. > I ran this with another repo not holding any uv files and still got the > errors. so my previous observation (only affecting uv sync seems > spurious or at least not true for all repos) > 2. > the bisect is true for the scenario: use ssh-transport from a local > machine over the wire to the remote server. it does *not* happen (with > this repo) if I do the same while being logged in to the server holding > the remote repo. in the latter case the clone suceeds with tip of trunk... > 3. > I have added comments in the bisect log which refer to the checkin > _above_ the comment. the point I want to stress is that the BAD > behaviour changes during the bisect: initially after the last GOOD > checkin, the clone just hangs and never comes back, later/more recently > the error messages and manifest "clone aborted/failed" messages appear. > 4. > the bisect was performed on the (linux/ubuntu) server while keeping > the local (osx) labtop version of fossil constant (on 71260ba25e79f4aa, > I believe). so I think this proves that the problem is happening "on the > other side", not locally). > > hth, > joerg > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'
On 8/6/18, joerg van den hoff wrote: > this is a pure > CLI/ssh scenario. The ssh transport works by invoking the same HTTP processing engine as is used on a website, just on the far end of an ssh tunnel. It's all the same under the covers. That said, I do remember making some minor changes to the ssh transport as part of the refactoring that is currently taking place. Maybe something broke. Can you bisect back to the last release and figure out where the problem was introduced? That would be a big help. > overall, I really hope that not too much complexity is currently added > to fossil that could lead to a situation where fossil no longer excels > by ease of use and stability/absence of problems or serious bugs as it > has done now for so many years, thankfully. There is a lot of refactoring going on right now, in an effort to avoid introducing unnecessary complexity. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Error during commit
On 8/6/18, Philip Bennefall wrote: > But I wanted to report our experience in case it is of use to the > developers, and in case doing so could give us some assistance with the > immediate issue. Thank you for the report. This is definitely something that should be fixed. But I have a large queue of other issues of relevance to far more users (ex: support for email alerts and forum) that need to be fixed first. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Error during commit
On 8/6/18, Richard Hipp wrote: > On 8/6/18, Philip Bennefall wrote: >> Do you have any recommendations for something we could try in order to >> get more information, or would you suggest that we switch to another >> DVCS if we need to store files of these sizes? > > Regardless of the problem, I don't think *any* DVCS is appropriate for > storing gigabyte sized binary files. You should look into a > centralized VCS such as subversion, methinks. Further information: Fossil was written for the purpose of managing the SQLite project. The primary SQLite Fossil repository contains about 5.8 GB of content when fully expanded, but that is compressed down to 92 MB. In other words, the whole repository spanning 18 years of development and 20K check-ins and 78K artifacts is less than 1/10th the size of just one of your files. The largest uncompressed artifact in the SQLite repo is 19 MB and the median uncompressed artifact size is 42 KB. With compression the largest artifact is 1.8 MB and median artifact size is a mere 152 bytes. I analyzed a bunch of other Fossil repositories, and they all mostly have similar stats. Except, usually the maximum uncompressed artifact size is about an order of magnitude less than 19 MB (SQLite is has a few exceptionally large artifacts) and in the case of the SQL Logic Test repository, the median artifact size was 1.5 KB. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Error during commit
On 8/6/18, Philip Bennefall wrote: > Do you have any recommendations for something we could try in order to > get more information, or would you suggest that we switch to another > DVCS if we need to store files of these sizes? Regardless of the problem, I don't think *any* DVCS is appropriate for storing gigabyte sized binary files. You should look into a centralized VCS such as subversion, methinks. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Error during commit
On 8/6/18, Philip Bennefall wrote: > We have a repository in our organization which stores a number of rather > large binary files. When attempting to commit, we sometimes get > something like this: > > > ERROR: [largefile.bin is 999378424 bytes on disk but 210746789 in the > repository My guess is that you are probably overflowing a 32-bit integer someplace. If so, I fear that this will not be something easily fixed. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] strange delay and messages during `fossil (uv) sync'
On 8/6/18, joerg van den hoff wrote: > I see substantial delay (order of many seconds to minute(s)) when > executing > > seen with 2.6 [74c908e709] 2018-08-03 21:06:57 UTC > Please try https://www.fossil-scm.org/fossil/info/71260ba25e79f4aa and let me know whether or not that resolves the issue. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why no EXE+DLL like SQLite?
On 8/5/18, Gilles wrote: > 2. There's no maintained GUI for Fossil. I would argue that running "fossil ui" is your GUI. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Why no EXE+DLL like SQLite?
On 8/5/18, Gilles wrote: > > I'm only a casual programmer, but I assume it would have made it easier > to build a GUI by calling functions within the DLL. How does adding an extra component and a bunch of new interfaces make a program easier to build? I think that the key to building complex systems is to keep them as simple as possible. If you can omit a DLL/shared library and all the maintenance and interface design associated with it, then why wouldn't you? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] service instability
On 8/4/18, bch wrote: > I'm seeing "database locked" (with failure to load timeline via web) > and "panic: multiple calls to backoffice_run()" from > > $ fossil server > > which is a recent phenomenon for me. I think that might be fixed on the forum-v2 branch, though I'm far from certain. Please consider giving that branch a try and let me know if you continue to have issues. I hope to have time to work on things again beginning on Monday. Note that this is merely an annoyance. Pressing "Reload" on your browser will normally clear the problem, and there is no risk of data loss. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] About to merge the forum-v2 branch
On 8/3/18, Richard Hipp wrote: > On 8/3/18, 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"? > > I was just waiting for you to contribute that code, Richie ;-) I misread Richie's email, thinking it was directed at me. I therefore retract my snarky remark -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] About to merge the forum-v2 branch
On 8/3/18, 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"? I was just waiting for you to contribute that code, Richie ;-) -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil's (lack of) use of the Ticket system
On 8/3/18, Stephan Beal wrote: > > i see that Richard just answered, so i'll stop there and see what he says I like Stephan's answer better than my own :-) -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil's (lack of) use of the Ticket system
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 ..." Maybe the forum will turn out the same way. I won't know until we try it. Maybe with a forum in place, we won't get so many "How do I do..." tickets and we can turn tickets back on. I have your request. 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. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] About to merge the forum-v2 branch
On 8/3/18, Pietro Cerutti wrote: > 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. And so it shall be with the new forum. All forum messages will be delivered to you as email. You will need to visit the website in order to *send* new messages. But if you are merely listening, your workflow does not change. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] About to merge the forum-v2 branch
On 8/2/18, Offray Vladimir Luna Cárdenas wrote: > > I also enjoy mailing list. Hopefully some RSS way of > subscribing/replying to the forum from a mail client will be provided > and I will stay here as much as possible before subscribing to the > forum. You will be able to receive all forum traffic by email, just like on a mailing list. (Currently, you only get a notification link that you have to click on to see the actual message. I intend to fix that - but there are several other issues ahead of that one in line.) For sending messages to the forum, however, you will need to visit the website. I do not intend to accept forum traffic via inbound email, as that leads to many spam filtering problems that I do not want to have to deal with. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] About to merge the forum-v2 branch
I am about ready to merge the forum-v2 branch into trunk. If there are any objections, voice them quickly. The forum-v2 branch implements a "forum" capability. Here is a quick summary: * Messages are organized into threads. The initial post of a thread contains a title. All subsequent posts omit the title, but have an in-reply-to field. * Passers-by can post anonymously, or (depending on the configuration) they can create a new account on-the-spot and post using their new account. The "self-register" feature has been in Fossil for ages out of mind. I forget who contributed it. (It did not come from me.) Self-registration has been seldom used before now, as far as I know. * Messages can be edited, either by the user who originally posted the message, or by an administrator. * Each message is an artifact, using a new artifact class called "Forum". See https://www.fossil-scm.org/fossil/doc/forum-v2/www/fileformat.wiki#forum for a description. There are three new cards: G, H, and I. * Because each message is an artifact, forum content syncs just like everything else. * Forum message from untrusted users (ex: anonymous) can be held for moderation. Such messages are not synced nor may they be replied too, until they are approved by a moderator. * Email notification is available for new forum posts. Currently, the alert emails contain a very brief synopsis of the post - essentially just the title. This can be enhanced later to provide the complete text of the post, if that is seen as desirable. * Each forum message has a mimetype. Currently supported mimetypes are text/plain, text/markdown, and text/x-fossil-wiki. New mimetypes can be added later The intent is to replace this mailing list, as well as various other mailing lists (fossil-users, sqlite-users, sqlite-dev, sqlite-announce) with the new forum feature. I hope to shut down the mailing lists and bring the forums all live within about a week. So if you have concerns, voice them soon. This message was originally posted on a test-forum at https://fossil-scm.org/forumtest1/forumpost/10fe5ccbc8 - please consider posting follow-ups there, as a test of the new forum system. If you encounter problems, reply to this legacy mailing list, or directly to me via private email. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Delay with `fossil ui' (related to backoffice processing?)
On 7/22/18, Florian Balmer wrote: > > Just a thought: would it make sense to have --nodelay as a global > option recognized by all commands, and maybe also through an > environment variable, and a CGI control option? So that any backoffice > processing could be temporarily disabled? Everything is in flux right now. Let's iron out these details once I get everything actually working. There is a lot more to be done before we reach that point. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Delay with `fossil ui' (related to backoffice processing?)
On 7/21/18, Florian Balmer wrote: > > I see random delays for the `fossil ui' command, Please test the latest trunk version and let me know if you are still seeing issues. Anybody who has the capability, please also verify that "fossil server --scgi" is now working again. I do not have a SCGI webserver set up on windows with which to test that command so I implemented the fixes there without actually checking them. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Delay with `fossil ui' (related to backoffice processing?)
On 7/22/18, Florian Balmer wrote: > > The Windows HTTP server (and thus `fossil ui') works by spawning > sub-processes for each individual HTTP request, right? This results in > multiple sub-processes per web page (one for the HTML page, one for > CSS, another one for JavaScript, etc.)? > Every Fossil webpage is generated by a separate subprocess. This is true for Windows, Mac, Linux, BSD, whatever. And it is true regardless of how Fossil is launched. The backoffice is a facility to do background processing - things like sending email notifications, syncing with peers, maybe doing aggressive compaction of the repository - anything that is not directly interacting with the user. Backoffice runs after a webpage is generated, in the same subprocess. Once the entire webpage has been generated, Fossil closes the socket or file into which the webpage is being written, and then attempts to do backoffice processing. There can only be one backoffice process at a time, and another backoffice that is "on deck" - ready to run when the current one finishes. In most systems, the webserver returns results back to the user as soon as the output socket closes. So the user does not realize that the process that generated the webpage continues running for up to 60 seconds of backoffice work. But on Windows for "fossil ui" and "fossil server", the webpage is not returned to the user until the subprocess actually terminates. Hence, if the subprocess gets involves in backoffice work, that can delay the return of content to the user. The only comes up on Windows. I do not yet have a good work-around. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Backup traffic
On 7/21/18, Florian Balmer wrote: > > The current tip version of Fossil still > exhibits the behavior summarized here: > > https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27269.html > I think this problem has been addressed in a more general way on the latest trunk. Please let me know if you find otherwise. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Backup traffic
On 7/20/18, 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. If you have Admin or Setup privilege, you can do "fossil config sync user" -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Backup traffic
On 7/20/18, Florian Balmer wrote: > But what is a good > strategy to minimize backup traffic, if repository databases change > that often? > Don't backup by copying the database file (which is not safe to do anyhow, unless you shutdown Fossil during the copy, because otherwise the database file might change while it is being copied, resulting in a corrupt copy.). Instead, create your backups by cloning and syncing. That is what DVCSes are designed to do. The canonical Fossil self-hosting repository, and the SQLite source repository that Fossil was created to manage, are both backed up this way. There are three separate servers, each in separate geographically distributed data centers, managed by two indenpendent ISPs. These repos are all synced with one another automatically using a cron-job. One cool bonus feature of this approach is that the 'backups" are live repositories, that can be directly accessed (as https://www2.fossil-scm.org/ and httpss://www3.fossil-scm.org/site.cgi) so it is easy to verify that the backups are really happening and that they are correct. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Re-sync skins of remote repo
On 7/15/18, Jungle Boogie wrote: > Hi All, > > I'd like to know if there's a way to re-sync to the skin of a remote repo, fossil config pull skin -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] OT: security/entropy (was Re: New Fossil user experiences)
On 7/14/18, Joerg Sonnenberger wrote: > If you can take the output > of any modern CPRNG as hex and don't get 4bpc, the entropy estimator is > broken. I've always understood the output of entropy estimators to me "the entropy is no greater than this", which is somewhat easier to define, since you get your choice of models. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil in a chroot jail. Was: Chiselapp status
On 7/13/18, Warren Young wrote: > > chroot() might even be strong enough given the tight scoping. Just checking to make sure you know: If you launch Fossil as root, it will automatically put itself into a chroot jail in the directory containing the repository, then change its userid and groupid to match the owner of the repository. It does this prior to reading any content from the wire. The chroot jail that Fossil runs in can be very lean. It does not need a shell nor a bunch of libraries (assuming you have statically linked). You will need to mknod a /dev/null, /dev/random, and /dev/urandom inside the jail, but that seems harmless enough. As a defense against DoS attacks, Fossil has a feature were it refuses to run certain expense web pages (ex: creating new tarballs) if the system load averages is too high. Fossil uses the getloadavg() interface to compute this. On Linux, getloadavg() requires that /proc be mounted. 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... -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] /usr/bin/ld: cannot find -ldl
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? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] /usr/bin/ld: cannot find -ldl
On 7/12/18, Jungle Boogie wrote: > > Any clues? Could you tell us what platform you are trying to compile on? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Feature slideshow on fossil homepage
On 7/9/18, mario wrote: > Our current homepage is a bit wall of textish / too bland "Bland" is a feature, not a bug. :-) Nevertheless, it would be cool if you could come up with a skin or demonstration project that showed people how to do the slide-show in case they wanted to do something like that on their own projects. Let's just not make that slide-show part of the default Fossil website. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] branch assistance needed
On 7/3/18, 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. I made that same mistake myself, recently. See https://www.sqlite.org/src/timeline?c=64df1189 Perhaps the best way to fix this is to cherry-pick the fix into trunk. > then attempted to change > that latest commit by adding a 'trunk' tag and cancelling the new branch > tag. I'm pretty sure that was wrong, but I'm unsure now where to go with > this. I've tried a few other things to no avail, but now even after > executing 'fossil update trunk' the 'fossil branch' command shows I'm still > in the new branch. > > So I have two problems to solve: > 1) how do I properly move commits between branches (and to trunk, in my > case)? Cherry pick. > 2) how do I unfudge my current condition and get back to trunk? > There is a way to undo your fudge. But, since this comes up so rarely, there is not a convenient interface. That is something I suppose I need to work on. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 6/28/18, Martin Gagnon wrote: > > To use the ns_* function, you needs to install libbind from packages: > pkg_add -r libbind. > I'm thinking I will probably end up having to write my own DNS query response parser.... -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 6/28/18, jungle Boogie wrote: > > The res_query() function provides an interface to the server query > mechanism. It constructs a query, sends it to the local server, awaits > a response, and makes preliminary checks on the reply. The query > requests information of the specified type and class for the specified > fully qualified domain name dname. The reply message is left in the > answer buffer with length anslen supplied by the caller. Values for > the class and type fields are defined in . > > I think that's what you want! Indeed. So can you write up a little subroutine to parse the binary DNS reply and extract the name of the MX host for us? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 6/28/18, jungle Boogie wrote: > > Does this help? > http://man.openbsd.org/man3/getrrsetbyname.3 > That seems to be an OpenBSD-only library function. So, no, it doesn't really help. Does OpenBSD have req_query() at least? I suppose I could write my own DNS record parser. (sigh...) -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] smtp.c build failures
On 6/28/18, jungle Boogie wrote: > Hi All, > > I know it's still very early on to make use of the new smtp logic, but > I thought I'd report these issues. Is anyone else experiencing issues > with compiling? Did you rerun ./configure? fossil clean -x ./configure make If you still get errors then, please let me know. But first, figure out what library OpenBSD wants to link against in order to pick up the DNS parsing routines. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Embedded Documentation Force Trailing Slash?
On 6/28/18, MKG wrote: > > /index.cgi/doc/trunk/test/ ---> works > "/index.cgi/doc/trunk/test ---> doesn't work > > Technically, this is correct but I'm wondering if there is a way to add the > trailing slash when necessary to make it more usable. I don't recall a way of making the /doc webpage do that. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 6/28/18, Lester L. Martin II wrote: > > Indeed. The entire code dealing with adding in line numbering would need > reworking to enable it (and probably updates to CSS as well). I might > can > look into getting that working as well. I actually think there would be > a way that would be simpler than IIRC prefixing each line with spaces > and > the number and then more spaces. Excellent. Please mail in your CLA when you get a chance. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Patch: Enables integration of syntax highlighting systems
On 6/28/18, Lester L. Martin II wrote: > This patch changes the way `void artifact_page(void)` renders a files > content. > Formerly a `` was issued for content, whereas now a > `` is issued where $ext is the file's > extension (example, "blah.lua" extension would be "lua"). But then the syntax highlighting goes away if you select line numbering, no? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Help with making a subroutine x-platform to windows
If anybody can suggest patches that will get this routine (https://fossil-scm.org/fossil/info/5e083abf6?ln=47) to compile and work on windows, that would really be helpful. Thanks. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Meta-enhancement
On 6/27/18, Andy Goth wrote: > Would you be okay with me creating feature requests to track my own > Fossil development ideas, or would you prefer I keep them in wiki pages > or somewhere else? I prefer them on this mailing list for now. What advantage do you hope to gain from moving feature requests to tickets and/or wiki? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Meta-enhancement
On 6/27/18, David Mason wrote: > > Wouldn't it be better if feature requests didn't count as bugs. And if > tickets were marked as bugs, can't they be redefined as feature requests > (and then left open)? > Yes, you could do that. I encourage you to experiment with that technique on your own projects and let us know how it goes. If you report a positive experience, then I will consider trying it on Fossil and SQLite. My impression is that I would be troubled by the thousands of open feature requests that the ticket system would be carrying around. But perhaps that is just a personal bias that I need to overcome. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Meta-enhancement
On 6/27/18, Warren Young wrote: > > The problem there is spam. > Captchas and requiring moderator approval of wiki edits and new tickets goes a long way toward fixing the spam problem. Another more important reason why I turned off anonymous tickets is that the signal-to-noise ratio was just too low. An overwhelming majority of tickets were really support requests and/or new feature requests. There were very few actual bugs reported by tickets. If a feature request comes in via ticket, I can either leave the ticket open for some future date when I might implement the idea, or I can close it immediately as "not a bug". If I leave it open, then people become alarmed at all the open bugs against Fossil. If I close it right away, people misunderstand that as rejecting the idea. Either way, users end up feeling unhappy. In my experience, the mailing list is a much better mechanism for dealing with community input. Ideas get expressed and debated, but I am under less pressure to pick sides or to take immediate action on marginal ideas. Hopefully the new Forum feature with email notification might work out even better than the mailing list. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Checking out the same check-in displays meaningless error
On 6/26/18, Richard Hipp wrote: > it is mostly harmless. In fact, the message comes from fossil_warning() Quite harmless. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Checking out the same check-in displays meaningless error
On 6/26/18, Dan Barbarito wrote: > Hello everybody, > > I figured I'd share a bug I found on here since tickets by anonymous > users seem to be disabled. I am using the latest code in the trunk > branch and I noticed that if you run "fossil checkout" on the same > check-in twice in a row then you get an error that says "Missed call to > db_end_transaction(). Rolling back." To reproduce, just run "fossil > checkout tip" twice. I have not yet had the chance to try this on the > 2.6 release build of Fossil but I figured I would let you all know that > this is occurring anyway. I added that new error message yesterday, to help ferret out subtle problems. Thanks for the report. But don't stress over the error - though it out to be fixed, it is mostly harmless. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown in tickets
On 6/26/18, Chad Perrin wrote: > > I am running Fossil v2.5 here: > > $ fossil version > This is fossil version 2.5 [188a0e2904] 2018-02-07 18:48:14 UTC > > I see no Markdown formatting option for tickets when visiting the web UI > via `fossil serve`: Go to /Admin/Tickets and edit the scripts you find there to provide support for markdown. As the scripts already provide support for text/plain, text/html, and text/x-fossil-wiki, it should be apparent how to enhance them with an extra case for text/markdown. Once you get this working, submit your changes for inclusion in the SQLite source tree. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Meta-enhancement
On 6/26/18, Andy Goth wrote: > A > forum might be nice, but I don't want to have to enhance Fossil just to > be able to discuss enhancing Fossil! > Initial prototypes for the forum code are already in the tree. It just needs some more work. The recent email notification enhancements were made in order to support ongoing Forum development. Patience, grasshopper. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On 6/26/18, sky5w...@gmail.com wrote: > But now I am confused by this thread? > If/When I add unversioned files, are their original paths stripped? > Are they stored differently than source code? > Unversioned files were created for the purpose of providing a place to store build products when Fossil is used as a server, as you find on the https://fossil-scm.org/fossil/uv/download.html. See https://www.fossil-scm.org/fossil/doc/trunk/www/aboutdownload.wiki for a discussion of how the download page is implemented. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
On 6/26/18, j. van den hoff wrote: > turning this setting on by default might also offer the "least > surprise" for the user It isn't an on/off setting. I was not clear. The setting is the name of the directory that is the root of the unversioned file hierarchy. An empty string for this setting means "off". But there are infinitely many "on" settings. What should be the default? "unversioned"? ".uv"? Just "."? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Markdown in tickets
On 6/26/18, Andy Goth wrote: > Is there a reason why Fossil tickets don't allow markdown? The format > options are wiki, HTML, plain text, and [links only]. Markdown as a formatting option can be added by configuration. Perhaps you are asking for Markdown support to be added to the default configuration? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
My thought was to provide a new setting (perhaps versionable) that specified a directory relative to the root of the check-out into which unversioned files are written whenever one does "fossil update" or "fossil checkout". If the setting is missing or empty, then Fossil works as it does now. If you turn on the setting, though, then the unversioned files work just like other files in the check-out, except that Fossil never records their history. I'm not sure yet whether or not this is a good idea. I'll need to think about it. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] `unversioned' questions
Unversioned files do not appear in the local check-out, by design. It would be an enhancement to make them do so. But you are not the first to request that capability. I've been on a Fossil-enhancement binge lately - perhaps I can find the time to fix that for you... On 6/26/18, j. van den hoff wrote: > today I convinced a colleague to give fossil a try. so we set up a project > (two checkouts/clones, one central server/repo), using a planned journal > article (to be written in latex) as the test case. > > now, while I never have used 'unversioned files' so far, he immediately > wanted to try this option for the jpeg-figures to be included (and > probably modified 100 times before the paper is completed). > > good: he managed to get them into his repo and to sync it to the server. > good: I managed to sync the unversioned files into my repo. > > problems/questions: > > 1. > the files do not materialize in my checkout after "sync -u". they are > "just" present in my local repository. that probably is as it should be > (just as with standard `sync'). but there seems to be no equivalent to > `fossil up' for the unversioned files. > > question: what is the canonical way to get them out of the repo? I see the > export command but it probably is not the idea to issue 20 export commands > (or to write a shell script for that)? > > 2. > if I export the files manually now, what happens after the next push of > unversioned files by my colleague? I guess, I can sync them (but am not > really notified of changed content) but would have again to export them > manually (and would have to know that this is required)? > > maybe I am missing some stupid point here, but my expectation would have > been that unversioned files mostly behave like tracked/versioned files in > that there should be an update facility (say `fossil up -u' or something > like that) of these files in my local checkout? > > thank you, > > joerg > > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Email notifications content transfer encoding
Since Rafal's original inquiry, I have modified the email notification logic to use quoted-printable instead of base64. Quoted-printable is not as clean as plain-old 8bit, but it is much more readable than base64. Acceptable compromise? On 6/26/18, Rafal Bisingier wrote: > Hi > > Richard asked me to post it on the list for discussion, so here it is: > The new email notification functionality in fossil use base64 as > Content-Transfer-Encoding. I personally prefer use of 8bit encoding, > which have a side-effect of human-readable source of message. I admit > that it does not matter much in a normal situation (reading the message > in an email client), but on a few occasions I had to grep/cat through > mailbox files, and having a readable message body was of great help > then. That's why I want to submit for consideration using a 8bit > content transfer encoding for email notifications. Nowadays there are > practically no problems in transport of such messages. The only down > side I could think of is that theoretically there is a limit of 1000 > chars in a line in an email message (and base64 encoding bypasses it). > But would it really be a bigger problem? > On the pros there is simplified debugging (no need to decode message, > which fossil store in his database file in "transport-ready" form - > so currently with base64 encoded body). Of course DRH already wrote a > tool to help in this ;-) so it is already doable without much trouble > https://www.fossil-scm.org/fossil/file/tools/decode-email.c > Nevertheless I'd like to have a readable source of messages. ;-) > > -- > Greetings > Rafal Bisingier > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] mv-rm-files setting
The mv-rm-files setting used to require a compile-time option in order
to function. I have removed that requirement. mv-rm-files now works
without special compile-time options.
On 6/26/18, j. van den hoff wrote:
> I have not fiddled with this for some time and now I do no longer recall
> how exactly this setting is managed. it is mentioned in several of the
> help pages and I do have an entry
> in my global `.fossil' database
>
> INSERT INTO global_config VALUES('mv-rm-files','on');
>
> (I do no longer recall when and how I've put it there :| ...) but it is
> neither reported by `set' AFAICS nor, in fact, does `fossil set' recognize
> "mv-rm-files" as a valid setting. what am I missing? a pointer where to
> look in the documentation would be appreciated...
>
> thank you,
>
> joerg
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
On 6/25/18, jungle Boogie wrote: > If I inadvertently forward my email along > to someone/group without modifying the footer, the person/group would > be able to alter my subscription. How can I fix that? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
On 6/24/18, Dingyuan Wang wrote: > > I just got 50 exactly same "[fossil-src] activity alert" emails > describing 5 check-ins in three minutes. What's happening to the server? > Did today's digest arrive successfully, and only once? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [PATCH] Remove unused option from settings page
On 6/25/18, bytevolc...@safe-mail.net wrote:
> Ping.
https://www.fossil-scm.org/fossil/fdiff?v1=c05a6e30cd4e0324=04e654b0d8ae6f74
>
> On Thu, 21 Jun 2018 22:18:37 +1000
> wrote:
>
>> It appears the "show-version-diffs" setting was abandoned in commit
>> 0a1f4ed6aa.
>>
>> Index: src/setup.c
>> ==
>> --- src/setup.c
>> +++ src/setup.c
>> @@ -1463,19 +1463,10 @@
>>@ in a separate box (using CSS class "timelineDate") whenever the date
>> changes.
>>@ With the "-MM-DDHH:MM" and "YYMMDD ..." formats, the
>> complete date
>>@ and time is shown on every timeline entry using the CSS class
>> "timelineTime".
>>@ (Preperty: "timeline-date-format")
>>
>> - @
>> - onoff_attribute("Show version differences by default",
>> - "show-version-diffs", "vdiff", 0, 0);
>> - @ The version-information pages linked from the timeline can either
>> - @ show complete diffs of all file changes, or can just list the names
>> of
>> - @ the files that have changed. Users can get to either page by
>> - @ clicking. This setting selects the default.
>> - @ (Property: "show-version-diffs")
>> -
>>@
>>entry_attribute("Max timeline comment length", 6,
>>"timeline-max-comment", "tmc", "0", 0);
>>@ The maximum length of a comment to be displayed in a timeline.
>>@ "0" there is no length limit.
>> ___
>> fossil-users mailing list
>> fossil-users@lists.fossil-scm.org
>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On 6/16/18, Stephan Beal wrote: > > 3) Fossil effectively uses exit() to handle just about any type of > non-allocation error. i.e. there's little library-friendly error handling > in fossil. Not just errors. If Fossil finds an opportunity to send a "304 Not Modified" reply, it does so and then immediately calls exit(0), without having to unwind the stack. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
On 6/24/18, Stéphane Aulery wrote: > Hello, > > Le 23/06/2018 à 22:07, Richard Hipp a écrit : >> Just FYI: >> >> I have opened up email notifications on the canonical Fossil >> repository. To subscribe, visit: >> >> https://fossil-scm.org/fossil/subscribe >> >> Your help in finding creative ways of breaking the new system is >> appreciated. > > I subscribed at 2018-06-24 18:22:53 and never received the message of > confirmation. This is what your email system said to the Fossil server when it tried to send your verification email: Jun 24 18:32:49 ubuntu postfix/smtp[2330]: C2148CE08: to=, relay=mx1.free.fr[212.27.48.6]:25, delay=0.98, delays=0/0/0.51/0.47, dsn=5.0.0, status=bounced (host mx1.free.fr[212.27.48.6] said: 550 spam detected (in reply to end of DATA command)) I do not (yet) have the bounce-processing logic working in the new email notification system working, and so Fossil was not able to detect that your confirmation request had bounced. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
On 6/24/18, Dingyuan Wang wrote: > > I just got 50 exactly same "[fossil-src] activity alert" emails Thanks for the report. The problem should be fixed now. There is a variable in the database that remembers when the last digest was sent. Do to a missed COMMIT, that variable was never being updated. Hence, the digests were being sent over, and over, and over. I think I have the problem fixed now, but I do need to better instrument the code to detect these kinds of things and provide better diagnostics. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
On 6/24/18, j. van den hoff wrote: > On Sun, 24 Jun 2018 12:08:30 +0200, Richard Hipp wrote: > >> The UPDATE syntax error should be fixed now. Please try it again. > > yes, it works now. thank you. NB: I received the notification email > regarding the fix prior to actually confirming the subscription again -- > so my confirmation went through despite the SQL error? or is this > indication of some flaw in the subscription logic? > You had already been verify by the fact of visiting the page itself. That was a separate UPDATE (with the correct syntax!) that was performed in a different transaction. Thanks for pointing this out, though. I did have to think about it for a few seconds. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
The UPDATE syntax error should be fixed now. Please try it again.
On 6/24/18, j. van den hoff wrote:
> I get an sqlite error when following the verification link and hitting the
>
> `submit' button there:
>
> SQLITE_ERROR: near "WHERE": syntax error
>
> Database Error
> near "WHERE": syntax error: {UPDATE subscriber SET sdonotcall=0,
> sdigest=0, ssub='c', smtime=julianday('now'), smip='*', WHERE
> subscriberCode=hextoblob('*')}
>
>
> On Sat, 23 Jun 2018 22:07:52 +0200, Richard Hipp wrote:
>
>> Just FYI:
>>
>> I have opened up email notifications on the canonical Fossil
>> repository. To subscribe, visit:
>>
>> https://fossil-scm.org/fossil/subscribe
>>
>> Your help in finding creative ways of breaking the new system is
>> appreciated.
>>
>> Please note that this is still a work-in-progress. All subscription
>> data may be erased at any time. Email notifications might be disabled
>> at any time, in order to close security holes or otherwise work on the
>> system.
>
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
>
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
Just FYI: I have opened up email notifications on the canonical Fossil repository. To subscribe, visit: https://fossil-scm.org/fossil/subscribe Your help in finding creative ways of breaking the new system is appreciated. Please note that this is still a work-in-progress. All subscription data may be erased at any time. Email notifications might be disabled at any time, in order to close security holes or otherwise work on the system. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
Rough developers notes are available at https://www.fossil-scm.org/fossil/doc/trunk/www/emaildesign.md for anybody who wants to experiment with or contribute to this work-in-progress. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] email testing - no subscriber table?
On 6/23/18, Jungle Boogie wrote: > > no such table: subscriber SELECT 1 FROM subscriber WHERE suname='jungle' The email notification tables are created on-demand. Apparently I have missed a call to "email_schema()" someplace in the code. Fix this by running the command: fossil email reset Note that the email notification schema is still in flux. It will likely change again, multiple times, before release. To update the schema run "fossil email reset" again. Bare in mind that when you do so, it will erase all of your subscriber information. Some kind of automatic schema upgrade that preservers subscriber information will be incorporated prior to release. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What should email notifications look like?
Shown below is what I have at the moment. It is more succinct than other examples I've seen, but you can easily follow the link for details. The example below has more check-ins that one would normally find in a single alert (unless you sign up for the "daily digest") because my local repo is not actually sending emails and thus is not purging its "pending alert" queue. --- BEGIN --- This is an automated email reporting changes on Fossil repository [fossil-src] (https://fossil-scm.org/fossil/timeline) == 2018-06-22 01:18:59 Check-In == Rename the email_pending table to pending_alert. Add triggers to fill in the pending_alert table each time a row is added to the event table. (user: drh tags: email-alerts) https://fossil-scm.org/fossil/info/8c4b92ad3e27bb17bdde == 2018-06-22 01:28:10 Check-In == Fix harmless compiler warnings. (user: drh tags: email-alerts) https://fossil-scm.org/fossil/info/5fde17bbbc2cba69d3f8 == 2018-06-22 01:37:26 Check-In == Add the --nocompress option to the "fossil clone" command. (user: drh tags: trunk) https://fossil-scm.org/fossil/info/96d0a4becffa5e4150ab == 2018-06-22 03:17:00 Check-In == Add the /unsubscribe page. (user: drh tags: email-alerts) https://fossil-scm.org/fossil/info/f9116088243353b0f072 == 2018-06-22 12:25:41 Check-In == Make sure the content of outbound email messages always ends with a newline. (user: drh tags: email-alerts) https://fossil-scm.org/fossil/info/b70034837382b06e4b35 == 2018-06-22 13:50:00 Check-In == Add the --sql option to the timeline command. (user: drh tags: email-alerts) https://fossil-scm.org/fossil/info/d51ca5f567349b484540 == 2018-06-22 15:34:06 Check-In == Add logic to generate the text of email alert messages. (user: drh tags: email-alerts) https://fossil-scm.org/fossil/info/bb30d02efdb768b424b0 == 2018-06-22 15:57:46 Check-In == Generate event report in chronological order for an alert text. (user: drh tags: email-alerts) https://fossil-scm.org/fossil/info/e02892522ecf7f3e7956 == 2018-06-22 17:36:33 Check-In == A new way of computing alert text. (user: drh tags: email-alerts) https://fossil-scm.org/fossil/info/6c06b1c896e9c97f9e3b To unsubscribe: https://fossil-scm.org/fossil/unsubscribe ------ END -- -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] What should email notifications look like?
On 6/22/18, Philip Bennefall wrote: > Would it make sense to have the possibility to supply various email > templates in markdown on an admin page, and have insertable variables? > Of course with a default text for each new repo. That sounds like good idea. Please send an example. Ideally, your example would show us both the original template, and the text that results from apply the template to a specific timeline event. Perhaps use the check-in at https://www.fossil-scm.org/fossil/timeline?n=3=fa83e4b3 to complete your template. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] What should email notifications look like?
You may have noticed that I've been working on adding support for email notifications or alerts to events on a Fossil repository. But I need your help. When an event occurs (such as a check-in, or wiki-page edit) and a user wants a notification of that event, what should the email look like? Please send me examples. Pick a timeline event from the Fossil self-hosting repository and send me the actual text of an email that you think should be dispatched to announce that event. You can reply to this mailing list, or send examples directly to me. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Cloning repository with large files very slow
On 6/21/18, E Cruz wrote: > Is there a way to prevent fossil > from re-applying delta encoding when cloning? Please rebuild your Fossil using the latest trunk check-in, then try your clone using the new --nocompress option. Report back whether or not this solves your problem. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] No rule to make target 'src/email.c', ...
On 6/21/18, Warren Young wrote: > > You might want to change the “sendmail -t” default for Windows as well. I need to get it working first. After I get something working, then we can go back and worry about fine-tuning so that the feature to be convenient for windows. Right now, nothing in the email notification logic works. At all. On any platform. So the fact that the defaults are suboptimal is not a distraction that I want to burn time on. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] No rule to make target 'src/email.c', ...
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. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The legacy of FOSSIL_ENABLE_LEGACY_MV_RM
It ought to be the case that the default action of "fossil rm" and "fossil mv" is to actually change the filesystem, in addition to changing the way files are stored in the repository. But early versions of Fossil did not behave that way. They required you to do it in two steps: fossil rm abc.c rm abc.c We talked about fixing Fossil so that "fossil rm abc.c" actually removed the file. But the feeling was that would break too many legacy scripts. So the less desirable legacy behavior remains, to this day. On 6/20/18, bytevolc...@safe-mail.net wrote: > Hello, > > I am trying to understand the idea behind FOSSIL_ENABLE_LEGACY_MV_RM. > > It has been around for a while, and it is the only compile-time flag that > determines if a setting is hard-coded or if it is obtained from the > repository config. > > It appears that if this is not defined, the "mv" and "rm" commands will > modify the file system under all circumstances. > > Given the "--hard" option in these commands anyway, this seems superfluous. > So what is the idea behind the FOSSIL_ENABLE_LEGACY_MV_RM flag? > -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] No rule to make target 'src/email.c', ...
This was also reported by Andy Goth over on fossil-dev. It is reassuring to know that so many people routinely build Fossil from the trunk sources :-) -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] A fossil library
On 6/19/18, Stephan Beal wrote: > i have _no_ idea what the differences are between sha1 and > sha1-hard, SHA1-hard is a modified SHA1 algorithm that is resistant to the SHAttered attack (https://shattered.io/) against SHA1 that came out about a year ago. SHA1-hard generates the same hashes as SHA1, except in the extremely rare cases where the hash is vulnerable to SHAttered. SHA1-hash works by detecting cases where the hash seems to be exploiting weaknesses in the SHA1 compression function and then it makes the hash "safe" by increasing the number of rounds in those rare cases. I converted from using SHA1 to SHA1-hard within about a day of SHAttered being announced. Git also has converted, but it took them months. I also added SHA3 support at the same time. Git is still SHA1-only, the last time I checked. The SHA1-hard code was stolen from https://github.com/cr-marcstevens/sha1collisiondetection. The only changes I made were to clean it up a little and convert it into a single-file implementation so that it was easier to import into the Fossil source tree. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] SlackBuilds.org GitHub repository and DMCA Takedown notice
On 6/17/18, Andy Goth wrote: > > Am I correct in my understanding that all a Fossil repository need do is > issue shun artifacts for each file in the takedown notice? If the files > had multiple versions (they didn't in this case), shun each version of > them too, right? > I think that is correct, yes. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Backups of deconstructed fossil repositories
On 6/17/18, Thomas Levine <_...@thomaslevine.com> wrote: > As content is added to a fossil repository, files in the corresponding > deconstructed repository never change; they are only added. Most backup > software will track changes to the deconstructed repository with great > efficiency. > > I should thus take my backups of the deconstructed repositories, yes? Fossil itself tracks changes with great efficiency. The best backup of a fossil repository is a clone. The self-hosting Fossil repo at https://fossil-scm.org/ is backed up by two clones, one at https://www2.fossil-scm.org/ and the other at https://www3.fossil-scm.org/site.cgi. Each of these clones is in a separate data center in a different part of the world. The second clone uses a different ISP (DigitalOcean instead of Linode). Both clones sync to the master hourly via a cron job. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Is it possible to revert making a repository private?
On 6/16/18, Zack Scholl wrote: > Hi, > > First of all I love fossil - thank you for all the work that goes into > making it. > > I just tried the feature to make my repository private (Admin -> > Security-Audit). Now my repository is "Completely PRIVATE" which is great, > but I'm thinking I'd like to make it public once I finish coding. > > I don't see an option anywhere to make my repository public again. Is is > possible to make my repository public again? There is not a one-button-click to take it public. Instead, go in and start adding various read permissions to the special "nobody" and/or "anonymous" users. The difference between "nobody" and "anonymous" is that "anonymous" has to log in, using a password provided on-screen, which is an impediment to robots and spiders, whereas "nobody" can do things within any login sequence at all. Everyone who visits the website inherits the permissions of "nobody", regardless of whether or not they are logged in. Anybody who logs in (either as "anonymous" or as any other user) inherits the permissions of anonymous. On the Fossil self-hosting repo, "nobody" has permissions "gjozr" and "anonymous" add permission "h". In addition, on the Admin/Access page, the "Enable hyperlinks for 'nobody' based on User-Agent and Javascript" button is checked. Those settings are sufficient to provide a good public access site. Your question points up the need for us to come up with a new-administrator tutorial of some kind -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, Richard Hipp wrote: > On 6/15/18, Chad Perrin wrote: >> >> This would not technically be a "pull request". It would be a "merge >> request". > > Good point. It should not be called "pull-request" as pulling does > not come into play. > > On the other hand, it is not necessary a request to merge. Often a > merge is implied, but the reviewer instead might prefer to accept the > changes but leave them on a branch. In that case it might be called > "push-request". Once the branch gets pushed, then merging can come > later. Other ideas for what to name this (hypothetical and unimplemented) command: fossil contribute fossil bequest fossil bestow fossil proffer -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, Chad Perrin wrote: > > This would not technically be a "pull request". It would be a "merge > request". Good point. It should not be called "pull-request" as pulling does not come into play. On the other hand, it is not necessary a request to merge. Often a merge is implied, but the reviewer instead might prefer to accept the changes but leave them on a branch. In that case it might be called "push-request". Once the branch gets pushed, then merging can come later. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, Nicola Vitacolonna wrote: >> Git does have its own method (`git am`). > > Sorry, that should be `git request-pull`. From the manpage, it appears that the "git request-pull" command is less automatic than my proposed "fossil pullrequest" command. The git-request-pull expects the upstream reviewer to do a pull of the changes, which implies that the requester must have access to a repository that the reviewer can reach. The "fossil pullrequest" goes ahead and bundles all the changes into a neat self-contained package and sends them upstream, so that the requester does not need to host his own server. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, Ron W wrote: > On Fri, Jun 15, 2018 at 2:58 PM, > > wrote: > >> >> Date: Fri, 15 Jun 2018 13:35:13 -0400 >> From: Richard Hipp >> Subject: Re: [fossil-users] Perception of Fossil >> >> An alternative design sketch: >> >> (4) The pullrequest command creates a "bundle" out of the "anon-patch" >> branch and then transmits that bundle back to the server from which >> the clone originated. >> >> (5) The server accepts the bundle and parks it in a separate holding >> table, but does not merge it or otherwise make it available to average >> passers by. The server then sends email notifications to developers >> with appropriate privileges to let them know that a pull request has >> arrived. >> > > How does the bundle get transmitted to the server? If via a push, making > the bundle seems like extra work.. The user types "fossil pullrequest" and the changes get sent up to the server. Why does it matter what steps Fossil undertakes behind the scenes to make this happen? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, jungle Boogie wrote: > >> Additional notes: >> >> Prior to step (3), Fossil might require Anonymous to provide contact >> information so that developers can get in touch in case there are >> questions or requests for clarification. Anonymous might also be >> asked to sign a contributors agreement to be included in the bundle >> (as an entry in the bconfig table). > > That's a very nice thought. What is another Anonymous person were to > submit a pull request, would it assume it's the same user and use the > same contact info? No. Identification policies would be contained in configuration settings on the server and (automatically) downloaded when the repo is cloned. Then when Anonymous runs "fossil pullrequest", Fossil will check those identification policies and prompt the user to enter the necessary information. The identification information would be included with the bundle in the bconfig table. Of course, Anonymous has complete control over the bundle and might forge information so it is up to the reviewers to ensure that the information is complete, accurate, and acceptable to the project policies. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Perception of Fossil
On 6/15/18, David Mason wrote: > I heartily agree with this... A flag to allow a person (including > Anonymous) to make a commit that would automatically go into a new branch > like "Patch-1" (each one incrementing the branch number) is (a) better than > emailed patches, and (b) better than pull requests. Primarily because it > puts it into Fossil so you can use all your standard workflows. > > The "Patch-?" branches should not be automatically synced, and if you do a > sync with some special flag, it should offer each of the existing patch > branches and allow you to agree to sync it, or not. Then there needs to be > a way to delete the patch branches (whether included into the trunk or not) An alternative design sketch: (1) Anonymous clones repo CoolApp (2) Anonymous makes changes to CoolApp and checks those changes into a branch named "anon-patch" on her private clone. Repeat this step as necessary to get anon-patch working. (3) Anonymous runs the command "fossil pullrequest anon-patch" (4) The pullrequest command creates a "bundle" out of the "anon-patch" branch and then transmits that bundle back to the server from which the clone originated. (5) The server accepts the bundle and parks it in a separate holding table, but does not merge it or otherwise make it available to average passers by. The server then sends email notifications to developers with appropriate privileges to let them know that a pull request has arrived. (6) Developers who receive notification of the pull request can run a command that pulls down the bundle and applies it as a private branch on their own personal clones of the repo. Developers can then either approve of the pull request by publishing it (marking it non-private) and pushing it back to the server. Or they can reject the pull request which erases it from their clone. They might also cause the pull request to be erased from the holding table on the server. Additional notes: Prior to step (3), Fossil might require Anonymous to provide contact information so that developers can get in touch in case there are questions or requests for clarification. Anonymous might also be asked to sign a contributors agreement to be included in the bundle (as an entry in the bconfig table). -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Back on-line. Was: Mailing list shutting down...
On 6/14/18, Richard Hipp wrote: > On 6/14/18, Chad Perrin wrote: >> >> It looks like the mailing list page itself is still down for this list. >> >> >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > It was working earlier today. We've had some sign-ups. And I haven't > changed anything. Trouble-shooting now.... Should be working again now. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Back on-line. Was: Mailing list shutting down...
On 6/14/18, Chad Perrin wrote: > > It looks like the mailing list page itself is still down for this list. > > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users It was working earlier today. We've had some sign-ups. And I haven't changed anything. Trouble-shooting now.... -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [sqlite] Mailing list shutting down...
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. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [sqlite] Mailing list shutting down...
On 6/14/18, Warren Young wrote: > It might > be that the internal developer discussions use this proposed Fossil Forum > feature and the user discussions are held elsewhere. My plan was to set up an entirely new Fossil repo just to host the Forum for SQLite - a repo that was separate from the SQLite source code repo and holds only the forum. Call it https://sqlite.org/forum On the Fossil website, on the other hand, the entire website is just a single Fossil instance. And so on that case it does seem to make more sense to put the forum in the same repo as the source code. A key point here is you get to choose. Easily. Fossil is (or at least should be) so simple to set up that people can and do decide to use Fossil to host just a forum, or just a wiki, or just a ticketing system, without being required to use all the rest of the capabilities. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [sqlite] Back on-line. Was: Mailing list shutting down...
On 6/14/18, Gary R. Schmidt wrote: > > Would you be willing to publish your fix to the mailman list so that > others could make use of it? > I will provide *some* information: I installed a CGI logging system on selected parts of the subscription interface, and I am running "tail -f" on the log file. What I am seeing suggests that the problem is not caused by a single attacker, as there are a wide variety of attacks against the subscription systems. There are many different IP addresses from all over the world, so IP address blocking is of no help. But the differences are deeper than just multiple IP addresses (multiple IP addresses might simply mean that the attacker is using a botnet, for example.) The signatures of the attacks are very different. It is all done by robots, clearly, but it appears that very different code is used for each attack. To describe just one example, some of the attacks are coming in as GET requests, whereas others are coming in as POST. A minor fraction of the attacks seem to be coming from this website: http://185.203.240.97/spam/ So there you have it: If you want to harass someone by sending them thousands of subscription confirmations, there is now a website to assist you. Do we need any further evidence that the heart of man is deceitful above all things, and desperately wicked? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Back on-line. Was: Mailing list shutting down...
On 6/13/18, 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 Mailing lists are now back on-line and once again accepting subscriptions. I have implemented measures to block the subscription robots and to better log subscription activity to better detect future mischief. I consider this to be a stop-gap measure that will buy me some time to implement and test a better log-term solution. The current setup will change. But the temporary measure I implemented this morning do at least get us back to a functional mailing list while work on the improved solution proceeds. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Mailing list shutting down...
On 6/13/18, Warren Young wrote: >> Indeed, there are many advantages to just tacking a forum capability >> onto Fossil. > > Let’s list them: > > 2. Everyone who clones a Fossil project repository would henceforth also get > a clone of the project’s message traffic. This is not necessarily an advantage. We I have found is that forum and ticket traffic far exceeds the amount of source code. Furthermore this kind of traffic does not lend itself well to delta compression. And so what you would likely encounter is that clones would swell uncontrollably with most of the extra space going to extraneous and noisy forum traffic. This is especially true if attachments are allowed on forum posts, because what I have found is that you will quickly accumulate many multi-megabyte incompressible screenshot attachments. It doesn't take too many people attaching screenshots off of their hi-res "retinue" screen to give you 1GB clone bandwidth even for a smaller project. > > 3. Forum posts can show up in the timeline. Yikes. I think I would certainly want that to be turned off by default. > > 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. > These last three are nice ideas. But they depend on (2) which comes with associated bandwidth and storage overhead. My current design does not automatically sync forum content. I might add the ability to sync forum traffic separately, using a separate command, just as one can now optionally sync unversioned content using the "fossil uv sync" command. But that will come later, if at all. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] [sqlite] Mailing list shutting down...
On 6/13/18, Svyatoslav Mishyn wrote: > > Another alternative would be nimforum: > https://github.com/nim-lang/nimforum > It does not appear to have email notification. Unless I overlooked something. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Mailing list shutting down...
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. 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. 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) -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Bug in /finfo not showing Deleted anymore.
On 6/13/18, Svyatoslav Mishyn wrote: > (Wed, 13 Jun 08:49) Andy Bradford: >> I haven't had the time to investigate further, but it seems that with >> this commit, the /finfo timeline no longer shows when a file gets >> Deleted: >> >> http://www.fossil-scm.org/index.html/info/4c268999d5 > > I've reported it before: > https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg27146.html I'm tied up with a mailing-list infrastructure issue, so if you can suggest a patch, that would be helpful. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Mailing list shutting down...
On 6/13/18, Peter Vonča wrote: > If you're going to write your own, are you going to use wapp? Sounds like a > good use case to me. Maybe. 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. In other words, you cannot send email back to the mailing list. Web-form only post and reply makes it much easier to control spam. 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? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Mailing list shutting down...
On 6/13/18, Svyatoslav Mishyn wrote: > > Have you considered/tried mlmmj - http://mlmmj.org/ ? > > At least it's written in C. A am not familiar with mlmmj. But a quick glance at the README shows that it seems to be using a pile-of-files style database. In order to create a new mailing list, you run a script that creates a bunch of directories under /var/spool/mlmmj/mlmmj-LISTNAME. I'd really like to move away from pile-of-files databases and hard-coded magic directories. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
