[fossil-users] friendly reminder: submitting tickets to Fossil
Hi, all, A friendly reminder, prompted by this morning's round of ticket moderation... The following is copy/pasted from the top of the ticket submission page ( http://www.fossil-scm.org/index.html/tktnew): *Discuss your issue on the fossil-users mailing list http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users first. Tickets for issues that have not previously been discussed on the mailing list are very likely to be deleted without comment and without consideration.* So please don't be surprised if one or more of your submissions has been mysteriously deleted. Now the justification, for those who like that kind of thing... In the scope of the Fossil project, the majority of tickets tend to fall into one of the following major categories: a) misunderstands or user error which are easily resolved via a mail thread. Such cases are sometimes caused by lack of (or sub-par) documentation, and posting it to the list ensures that more developers will see it, increasing the chances that it will get resolved and increasing the number of eyes on it (which tends to lead to better solution). b) New feature ideas and RFEs (Requests For Enhancements). Many times simply suggesting a new feature is enough to get it integrated, sometimes even on the same day. (We don't think of all features by ourselves, and quite rely on newcomers to suggest things which have so far been overlooked!) Larger feature ideas should be filtered through the list first, as many suggestions are either not feasible (or are unduly difficult) for architectural or project-level philosophical reasons, or are simply deemed out of scope for the project. Sometimes a new feature idea justifies a ticket, but in practice we tend to use the mailing lists to post/follow development of major new features. c) True bugs, i.e. broken behaviour. Posting to the mailing list will ensure a much quicker response than a ticket will, as all of us subscribe to the mailing list, but we do not all go and check the ticket list very often. (Other than via the ticket moderation queue, i very rarely go through the ticket list.) To be clear: we're NOT saying don't report problems and feature requests, we're just asking that you do so on the mailing list(s) first, and following up with a ticket only if requested to by one of the developers (you'll know they're a developer if they ask you to submit a ticket ;). In practice (for this particular project), this works out better for both the reporter and the developers. One final hint: after submitting a ticket, it's a good idea to post a link to it back to the mailing list thread it originated from. This assists, among other things, users searching through the mail archives (or their own mail clients). Disclaimer: the above applies only to the Fossil project, and is not intended to imply any rules/guidelines/best practices for other projects. Thanks once again for your continued input and support, and Happy Fossiling! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Ah, yes; I forgot about autosync (I'm new to actually using fossil), but I don't think it's a flaw (see below). On 3 October 2014 01:21, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 2, 2014 at 3:35 PM, David Mason dma...@ryerson.ca wrote: fossil update -q fossil update 21 | mail -s 'Fossil update' m...@he.re i've been mulling over this, and there's one fundamental flaw here: if auto-sync is on (which it is by default), then fossil does not know if there's work to be done until after it has done the network sync. In the above operation, it would sync twice, _potentially_ with different results for each (classical race condition). Having the hypothetical -q option disable/bypass autosync doesn't seem like a solution because then its result could very well differ from that of the second update (which would sync, if enabled). When autosync is off, that wouldn't be a problem, but it is on by default and is highly recommended to avoid unintended forks (the reason it's turned on by default, IIRC, was unintended forks in fossil itself early on in Fossil's history). Suggestions for an alternative approach, or concrete semantics, are welcomed. If autosync is on and remote-url is on, then update -q should do the sync, and then check if there is work to do. Of course, if there are changes, but not on the branch the update refers to, then it returns false (this allows for e.g. an in-production branch). 4 points: 1) in my use case, this is the master repository, so has remote-url off so this isn't an issue. 2) this update will run every ?5? minutes,so if the update -q misses a change that the second update would get, it's no biggy... 5 minutes later will do fine (my alternative solution of checking timestamps wouldn't do any better) 3) if the second update finds more to do because of the second auto-sync, so much the better... and if not, the second autosync is a bit of extra network traffic, but again, no biggy 4) autosync on update actually obviates the need for the -q switch on sync (and as I think it through, sync doesn't need it anyway as either it found nothing to do in which case the update would have found nothing to do, or it changed things in which case the update would see the change (or not if the changes were to another branch)) Hope that is clear. Thanks ../Dave ___ 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] Pessimism about CommonMark in fossil
On Thu, 2 Oct 2014 16:07:56 +0200 Stephan Beal sgb...@googlemail.com wrote: That was unfortunately a bit optimistic of me (i tend towards pessimism in most estimates ;), for which i apologize. Wiki topics in general are way, way, way down on my list of eventual todos. OK, no problem. I, somehow, thought that teaching Fossil to just render using JS in the browser should not be so hard... Sincerely, Gour -- Not by merely abstaining from work can one achieve freedom from reaction, nor by renunciation alone can one attain perfection. ___ 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] Pessimism about CommonMark in fossil
On Fri, Oct 3, 2014 at 4:56 PM, Gour g...@atmarama.net wrote: That was unfortunately a bit optimistic of me (i tend towards pessimism in most estimates ;), for which i apologize. Wiki topics in general are way, way, way down on my list of eventual todos. OK, no problem. I, somehow, thought that teaching Fossil to just render using JS in the browser should not be so hard... It can do so already, but... a) it requires the JSON API (which is not on be default) because core fossil will try to parse the wiki pages for you, whereas the JSON API provides an option to serve raw (unparsed) wiki pages. b) the client needs to provide his own JS, set it up in his repo header, etc. c) there isn't currently a mechanism which would allow wiki-generated and such to integrate with that, so it requires a completely custom front-end. The core only knows about one type of wiki like, and would send all generated links to the built-in wiki rendering mechanism. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Pessimism about CommonMark in fossil
On Fri, Oct 3, 2014 at 11:18 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Oct 3, 2014 at 4:56 PM, Gour g...@atmarama.net wrote: OK, no problem. I, somehow, thought that teaching Fossil to just render using JS in the browser should not be so hard... It can do so already, but... ... c) there isn't currently a mechanism which would allow wiki-generated and such to integrate with that, so it requires a completely custom front-end. The core only knows about one type of wiki like, and would send all generated links to the built-in wiki rendering mechanism. It could be as simple as a inbrowser tag that Fossil treats the same as verbatim with the addition of wrapping the raw wiki content with a div class=rawWiki or similar. Maybe Joe's new feature can help with this. Did not have a chance to look at it as my field trip got extended. While some JS would be needed, I think the foundation could be fairly simple: Find the div then feed its content to the user's chosen renderer. The main potential complication being that the contained wiki mark-up might confuse the browser's HTML parser. But, I would think that a mark-up that has a browser-based renderer (JS, Java or other) would already address this issue. ___ 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] Quiet mode for update and sync
Thus said David Mason on Thu, 02 Oct 2014 09:35:50 -0400: I want a script to run every 5 minutes and if there is any update, email me the update log. But I don't want email every 5 minutes that just says everything is up to date. I can figure out using file timestamps etc. if an update is necessary, but that's pretty ugly. Why not use Fossil's RSS feed feature to detect changes? Andy -- TAI64 timestamp: 4000542ece22 ___ 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] Quiet mode for update and sync
On 3 October 2014 12:25, Andy Bradford amb-sendok-1414945537.ohnacbkbmfbammcpp...@bradfords.org wrote: Thus said David Mason on Thu, 02 Oct 2014 09:35:50 -0400: I want a script to run every 5 minutes and if there is any update, email me the update log. But I don't want email every 5 minutes that just says everything is up to date. I can figure out using file timestamps etc. if an update is necessary, but that's pretty ugly. Why not use Fossil's RSS feed feature to detect changes? I looked at it. 3 reasons present themselves to me: 1) I may not be running a server (I'm not right now... this may change). 2) I'd have to parse the XML, at least minimally. It looks like I can parse the fossil stat to find the current checkout and then look for that in the output of: http://localhost:8080/XXX/timeline.rss?y=cin=1tag=trunk but that seems kind of kludgey 3) It seems like a lot more overhead, compared to a local run of fossil That said, if the powers that be (PTB) don't like the idea, rss does provide a fallback, thanks. ../Dave ___ 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] Tab stop width
Stephan Beal schreef op 1-10-2014 19:48: More info, for those interested: http://www.w3schools.com/cssref/css3_pr_tab-size.asp apparently MSIE doesn't support it, but that table might simply be out of date. http://caniuse.com/#feat=css3-tabsize (CanIUse.com is usually better up to date than w3schools). -- Martijn Coppoolse ___ 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] Pessimism about CommonMark in fossil
Note that wiki links are generated in many places, most notably the timeline, and if those links also have to work or the solution is only a partial one. (sent from a mobile device - please excuse brevity, typos, and top-posting) - stephan beal http://wanderinghorse.net On Oct 3, 2014 6:02 PM, Ron W ronw.m...@gmail.com wrote: On Fri, Oct 3, 2014 at 11:18 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Oct 3, 2014 at 4:56 PM, Gour g...@atmarama.net wrote: OK, no problem. I, somehow, thought that teaching Fossil to just render using JS in the browser should not be so hard... It can do so already, but... ... c) there isn't currently a mechanism which would allow wiki-generated and such to integrate with that, so it requires a completely custom front-end. The core only knows about one type of wiki like, and would send all generated links to the built-in wiki rendering mechanism. It could be as simple as a inbrowser tag that Fossil treats the same as verbatim with the addition of wrapping the raw wiki content with a div class=rawWiki or similar. Maybe Joe's new feature can help with this. Did not have a chance to look at it as my field trip got extended. While some JS would be needed, I think the foundation could be fairly simple: Find the div then feed its content to the user's chosen renderer. The main potential complication being that the contained wiki mark-up might confuse the browser's HTML parser. But, I would think that a mark-up that has a browser-based renderer (JS, Java or other) would already address this issue. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Quiet mode for update and sync
Thus said David Mason on Fri, 03 Oct 2014 12:49:17 -0400:
3) It seems like a lot more overhead, compared to a local run of fossil
I'm not sure why you need to parse anything. Here is a low-overhead
script that detects updates to a remote repository:
#!/bin/sh
OLD=$HOME/old.rss
NEW=$HOME/new.rss
touch $OLD
curl -s 'http://www.fossil-scm.org/index.html/timeline.rss?y=citag=trunk' |
sed -e '/pubDate/d' /tmp/new.rss
diff $OLD $NEW /dev/null || {
cp -f $NEW $OLD
echo new check-ins on trunk
exit 0
}
echo no new check-ins on trunk
exit 1
But, this raises the question... if you're just trying to determine when
to update, why not just run ``fossil update'' on a schedule? You
mentioned that fossil knows when it has ``work to do'' but I'm not sure
I understand exactly what you mean by it. Fossil certainly knows when it
should transfer content from the remote side to the local side and vice
versa. It also knows when it should merge files into your working
checkout (because fossil update causes this to happen).
Here was the original example:
fossil update -q fossil update 21 | mail -s 'Fossil update' m...@he.re
Are you simply looking for a way to be notified via email when there are
changes that have been updated into your working checkout? If so, I
think the above script could be substituted for ``fossil update -q'':
shouldiupdate.sh fossil update 21 | mail -s 'Fossil update' m...@he.re
Andy
--
TAI64 timestamp: 4000542ee560
___
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] Pessimism about CommonMark in fossil
On Fri, Oct 3, 2014 at 2:01 PM, Stephan Beal sgb...@googlemail.com wrote: Note that wiki links are generated in many places, most notably the timeline, and if those links also have to work or the solution is only a partial one. I think an example of what I mean would be helpful. If I go to the New Wiki Page page or Edit Wiki Page page, then put the following as the content: verbatim BEGIN_ASCIIDOC *this* is a sample of *asciidoc* END_ASCIIDOC /verbatim Then when I click any Fossil generated link to that wiki page, Fossil will serve up: BEGIN_ASCIIDOC *this* is a sample of *asciidoc* END_ASCIIDOC Then if I have suitable JS code, it can look for BEGIN_ASCIIDOC and END_ASCIIDOC, then feed everything between those 2 line to asciidoc.js While that works, from a user point of view, it is very kludgy. A step better would be if Fossil could accept something like: wiki t=asciidoc *this* is a sample of *asciidoc* /wiki Then serve up something like: div class=wiki_asciidoc *this* is a sample of *asciidoc* /div This would be less kludgy and maybe even have better/simpler JS code to find the content and feed it to the renderer. I don't know whether this would require a new change to Fossil or if Joe's custom page feature could handle this. And, hopefully, there will be at least 1 way to make this even less kludgy. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Cloning repo
Hi all, I've noticed an unexecpected behaviour in fossil when doing a clone. The issue appears when you try clone with a wrong user name and as the result an empty repo is created. I'd rather expect an error on the console and nothing else. The thing is fully reproducible with the latest windows binaries (see below, when asked just type any random password). Even more unexpectedly you can try doing this on http://myfakeu...@www.fossil-scm.org/ I'm not sure why failing to login to fossil-scm still clones the repo or why failing to my repo creates an empty repo. Is this by design? Best, Jacek fossil clone http://myfakeu...@egenome-fossil.cloudapp.net/e-Genome repo.fossil password for MyFakeUser: ** remember password (Y/n)? n Round-trips: 2 Artifacts sent: 0 received: 0 Error: login failed password for MyFakeUser: * remember password (Y/n)? n Round-trips: 3 Artifacts sent: 0 received: 0 Error: login failed Round-trips: 3 Artifacts sent: 0 received: 0 Clone finished with 907 bytes sent, 865 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: 0f5ea9d3c8bb48d8de1f1075b62026a6c7538d1e admin-user: MyFakeUser (password is 6af0d9) dir 04/10/2014 06:3958,368 repo.fossil ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
