Re: [fossil-users] filename contains illegal characters
On Thu, 22 Nov, Jan Nijtmans wrote: Stefan, could you try out [e6a1910fa8]? This sounds very cool. :-) However I still get: $ ~/tmp/fossil addremove [...] /home/bellonsn/tmp/fossil: filename contains illegal characters: str\i\ng.h This is with: $ ~/tmp/fossil version This is fossil version 1.24 [e6a1910fa8] 2012-11-22 09:32:23 UTC I am on a x86_64 Debian GNU/Linux box. And I did the following to build this version of fossil: $ mkdir ~/tmp cd ~/tmp $ fossil clone http://fossil-scm.org/ fossil.fossil $ fossil open fossil.fossil e6a1910fa8 $ ./configure $ make Am I missing something? Greetings, Stefan -- Stefan Bellon ___ 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] filename contains illegal characters
2012/11/22 Stefan Bellon sbel...@sbellon.de: On Thu, 22 Nov, Jan Nijtmans wrote: Stefan, could you try out [e6a1910fa8]? This sounds very cool. :-) However I still get: $ ~/tmp/fossil addremove [...] /home/bellonsn/tmp/fossil: filename contains illegal characters: str\i\ng.h ... Am I missing something? No, you are not missing anything. The backslash is still forbidden, but all other characters should be allowed with this change. It 'could' be possible to do something about backslash as well, but that will need some more clever thinking. I would like this change to be reviewed and accepted first, before trying to do more: Adapting '\' as well could impose security risks I cannot foresee, so it deserves a separate discussion/review. Regards, Jan Nijtmans ___ 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 on QNAP 419, missing utime
I downloaded and built fossil (v 1.24) from source for a QNAP TS419L nas, so that I could access repositories over the network. Although it mostly works, there is a very minor problem in that the footer of generated web pages say: This page was generated in about ERROR: no such command: utime whereas an official build on my local machine displays the time taken (and no error message, obviously). I'm assuming that I am missing a compile time option that I should have used to remove this functionality. Any suggestions? (My apologies if this is the wrong place for this discussion). ___ 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 on QNAP 419, missing utime
On 22 Nov 2012, at 11:33, Julian wrote: I downloaded and built fossil (v 1.24) from source for a QNAP TS419L nas, so that I could access repositories over the network. Oops, minor typo there - I meant a QNAP 469L, which uses an Intel Atom processor, not one of the ones with an Arm processor. Sorry about that. -- Julian ___ 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 on QNAP 419, missing utime
On Thu, Nov 22, 2012 at 6:33 AM, Julian j...@ptolserv.com wrote: I downloaded and built fossil (v 1.24) from source for a QNAP TS419L nas, so that I could access repositories over the network. Although it mostly works, there is a very minor problem in that the footer of generated web pages say: This page was generated in about ERROR: no such command: utime whereas an official build on my local machine displays the time taken (and no error message, obviously). I'm assuming that I am missing a compile time option that I should have used to remove this functionality. Any suggestions? The utime command for the embedded TH1 scripting language was added after the 1.24 release. The script used to generate the footer on Fossil itself is non-standard and uses that command, however. The utime command should not show up in new repositories that you create or in most other repositories. I added it in order to look for performance regressions. Possible solutions: (1) Recompile the latest trunk version of Fossil locally. This is just a matter of doing ./configure; make and then moving the resulting fossil binary onto your PATH. (2) Do fossil ui and go to Admin/Footer and press the Revert To Default button. (3) Ignore the error and wait for another official release. (My apologies if this is the wrong place for this discussion). ___ 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] [gdiff] Recommanded GUI differ for Windows?
On Wed, 21 Nov 2012 20:51:09 -0800, E. Timothy Uy t...@loqu8.com wrote: ExamDiff Pro. http://www.prestosoft.com/edp_examdiffpro.asp On Wed, Nov 21, 2012 at 7:47 PM, Tomek Kott tkott.li...@outlook.com wrote: fwiw I've used kdiff3 (http://kdiff3.sourceforge.net/) on windows with good success. It can do merges as well though I've yet to actually use that functionality Thanks for the links. ___ 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 design error and possible ways to fix it
Fossil understands check-in comments and ticket text to be Wiki/HTML. Let's say that the mimetype is text/x-fossil-wiki. This approach worked well for us on CVSTrac (which was where many of the ideas in Fossil originated) because it allowed hyperlinks to other check-ins, tickets, wiki, etc to be embedded in the check-in comment text. However, using text/x-fossil-wiki as the language of comments and tickets means that characters like and and [ have to be escaped using lt;, amp; and #91;. This is confusing and non-intuitive. People have complained. And I am now moving toward the view that the use of text/x-fossil-wiki for comment and ticket text was a mistake. I'm considering making the default representation of check-in comments and tickets be text/plain. For display on web pages, hyperlinks in [...] would still be decorated using a href=.../a markup, but the text would be unaltered and character-for-character the same as what the user originally typed in. There will probably be a configuration option to determine the default mimetype for check-in comments and ticket text, with options being either text/plain or test/x-fossil-wiki, with the (new) default being test/plain. There would also be options to determine if whitespace in check-in comments is displayed or if is coalesced and the text filled. The question now is how to do this in a backwards compatible way. There exist repositories (such as Fossil itself) with lots of text/x-fossil-wiki check-in comments. Possible solutions: (1) Just change the display format and do not worry about legacy commit-comments. There are not that many check-in comments that look different as text/x-fossil-wiki versus text/plain. If a few cases the use of text/plain is unacceptable, those few comments can be edited. (2) Always assume text/x-fossil-wiki for check-in comments that were entered prior to some cut-off date (say 2012-12-01) and assume text/plain thereafter. Perhaps the cut-off date can be changed for individual repositories using a configuration option, with a default value of 2012-12-01 or 2013-01-01. (3) Add a use text/plain mark to new check-in comments. Check-in comments (and ticket text) are rendered in text/x-fossil-wiki by default but as text/plain if they contain the new mark. There are a couple of possible ways to add the use text/plain mark: (3a) Extend the artifact format by adding optional mimetype fields to the end of C and J cards. (See http://www.fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki for background information on what C and J cards are.) This is the cleanest approach, but it means that new check-ins could not be understood by older versions of Fossil. It would force people to upgrade. (3b) Add text \0P or \0plain to the end of the text in C and J cards that should be displayed as text/plain. The encoding used on the cards themselves interprets the \0 to be a NUL character (ASCII 0x00) which means that nothing after the \0 is actually displayed. And so the P or plain suffix is harmlessly ignored by legacy versions of Fossil. This approach seems more hackish, but is completely backwards compatible. (4) Other ideas? Please fill in your suggestions. Whatever route we go, I'll probably start making changes in a branch over the coming weekend. So your timely feedback is appreciated. 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] Fossil design error and possible ways to fix it
On Thu, 22 Nov 2012 08:05:03 -0500 Richard Hipp d...@sqlite.org wrote: (1) Just change the display format and do not worry about legacy commit-comments. There are not that many check-in comments that look different as text/x-fossil-wiki versus text/plain. If a few cases the use of text/plain is unacceptable, those few comments can be edited. Some one-time converter to migrate 'old' ones to the 'new' ones which would require people to upgrade their Fossil and forget about backward compatibility keeping Fossil clean. I believe that Fossil, by being a single executable easily build-able on so many platforms, already provides for very easy upgrade so one-time converter could do it giving users freedom to choose *when* they want to upgrade. Sincerely, Gour -- As fire is covered by smoke, as a mirror is covered by dust, or as the embryo is covered by the womb, the living entity is similarly covered by different degrees of this lust. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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 design error and possible ways to fix it
2012/11/22 Richard Hipp d...@sqlite.org: Fossil understands check-in comments and ticket text to be Wiki/HTML. Let's say that the mimetype is text/x-fossil-wiki. This approach worked well for us on CVSTrac (which was where many of the ideas in Fossil originated) because it allowed hyperlinks to other check-ins, tickets, wiki, etc to be embedded in the check-in comment text. I think I would fix that in the comment preprocessor. Before being committed, comments already have the pre-processing step that lines starting with '#' are eliminated. So, what of the following processing would be done in addition: - All '', '', '', single and double-quotes are translated to their html equivalent. lt; gt; amp; #39; quot; - All newlines are translated to '\nbr' (newline followed by 'br'), except for the last newline in the comment. - Maybe even all spaces translated to nbsp; and all tabs with multiple nbsp;'es. (I don't really think this is necessary) Then the comment text is valid html, but will look like plain-text when viewed, nothing else needs to be changed. And a configuration option can be introduced whether those two additional proprocessor steps are wanted for the fossil client or not. No changes at all to the fossil server. Advantage: - Fully upwards/downwards compatible. - The main problem of having to html-escape the characters manually is solved: the commit-message preprocessor does it for you. - no new mime-type has to be used. - Older commit-messages are displayed unchanged. - If more elaborate wiki markup is needed, it can always be edited later in the UI. Regards, Jan Nijtmans ___ 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 design error and possible ways to fix it
On 22 November 2012 14:05, Richard Hipp d...@sqlite.org wrote: (3) Add a use text/plain mark to new check-in comments. Check-in comments (and ticket text) are rendered in text/x-fossil-wiki by default but as text/plain if they contain the new mark. There are a couple of possible ways to add the use text/plain mark: (3a) Extend the artifact format by adding optional mimetype fields to the end of C and J cards. (See http://www.fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki for background information on what C and J cards are.) This is the cleanest approach, but it means that new check-ins could not be understood by older versions of Fossil. It would force people to upgrade. Another alternative is to treat cards without mimetype as text/x-fossil-wiki and allow for creating cards without mimetype when the text/x-fossil-wiki is set as default. You can then pick when upgrade to new fossil is required to access a particular repository and have the support for new formats available. The problem is with syncing commits and/or tickets from other repositories. Since there are no commit hooks yet it is not possible to reject artifacts that do not conform to the repository policy. Thanks Michal ___ 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 design error and possible ways to fix it
On 22 November 2012 14:35, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2012/11/22 Richard Hipp d...@sqlite.org: Fossil understands check-in comments and ticket text to be Wiki/HTML. Let's say that the mimetype is text/x-fossil-wiki. This approach worked well for us on CVSTrac (which was where many of the ideas in Fossil originated) because it allowed hyperlinks to other check-ins, tickets, wiki, etc to be embedded in the check-in comment text. I think I would fix that in the comment preprocessor. Before being committed, comments already have the pre-processing step that lines starting with '#' are eliminated. So, what of the following processing would be done in addition: - All '', '', '', single and double-quotes are translated to their html equivalent. lt; gt; amp; #39; quot; - All newlines are translated to '\nbr' (newline followed by 'br'), except for the last newline in the comment. - Maybe even all spaces translated to nbsp; and all tabs with multiple nbsp;'es. (I don't really think this is necessary) Then the comment text is valid html, but will look like plain-text when viewed, nothing else needs to be changed. And a configuration option can be introduced whether those two additional proprocessor steps are wanted for the fossil client or not. No changes at all to the fossil server. Advantage: - Fully upwards/downwards compatible. - The main problem of having to html-escape the characters manually is solved: the commit-message preprocessor does it for you. - no new mime-type has to be used. - Older commit-messages are displayed unchanged. - If more elaborate wiki markup is needed, it can always be edited later in the UI. The major disadvantage is, of course, that this ugly mess will be likely visible in the command line view of the commits and that it does not allow changing the commit message format. And this whole thing is probably about allowing multiple commit formats to exist cleanly in one repo. Thanks Michal ___ 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 design error and possible ways to fix it
On Thu, Nov 22, 2012 at 8:05 AM, Richard Hipp d...@sqlite.org wrote: (1) Just change the display format and do not worry about legacy commit-comments. There are not that many check-in comments that look different as text/x-fossil-wiki versus text/plain. If a few cases the use of text/plain is unacceptable, those few comments can be edited. The Fossil repository at http://www.fossil-scm.org/fossil/timeline has been (temporarily) set up to render check-in comments as text/plain. This does not seem to make too much difference, though you can see some mojibake in check-ins such as http://www.fossil-scm.org/fossil/timeline?c=2012-11-21+16%3A28%3A03 The current setting is for demonstration and to provoke discussion. It can be easily turned off and on in the Admin/Timeline configuration page. -- 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] Questions about using tag
Hello I checked the help section and googled for more infos, but am still a bit unclear at how to use the tag option to add tags to a given check-in: 1. Am I correct in understanding that the tag command can be either used with commit... fossil commit -m Some commit -tag some tags ... or later by calling it with a specific check-in hash? fossil tag add ?--raw? ?--propagate? TAGNAME CHECK-IN ?VALUE? 2. How do I find check-in's so that I can assign it one or more tags? 3. I'm not clear about what --raw does: The option --raw allows the manipulation of all types of tag sused for various internal purposes in fossil. It also showscancel tags for the find and list subcommands. 4. Are tags the right way to locate a given check-in, through the fossil tag find command? Thank you. ___ 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 on QNAP 419, missing utime
On 22 Nov 2012, at 12:30, Richard Hipp wrote: The utime command for the embedded TH1 scripting language was added after the 1.24 release. The script used to generate the footer on Fossil itself is non-standard and uses that command, however. The utime command should not show up in new repositories that you create or in most other repositories. I added it in order to look for performance regressions. Possible solutions: (1) Recompile the latest trunk version of Fossil locally. This is just a matter of doing ./configure; make and then moving the resulting fossil binary onto your PATH. (2) Do fossil ui and go to Admin/Footer and press the Revert To Default button. (3) Ignore the error and wait for another official release. Thank you, I will do (3) then, and just wait for the next release. You are right that it only shows in some repositories - I was testing with a copy of the fossil one whilst I got the thing working. My own ones don't have the utime footer, just the fossil version. -- Julian ___ 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 design error and possible ways to fix it
2012/11/22 Michal Suchanek hramr...@gmail.com: On 22 November 2012 14:35, Jan Nijtmans jan.nijtm...@gmail.com wrote: I think I would fix that in the comment preprocessor. The major disadvantage is, of course, that this ugly mess will be likely visible in the command line view of the commits and that it does not allow changing the commit message format. And this whole thing is probably about allowing multiple commit formats to exist cleanly in one repo. The timeline view already has code to display the comment text without format, that could be used for eventual command-line output as well. It's only comment anyway. Another functionality of fossil is that the commit-message is saved in case the commit fails, as initial value for the next try. This message will have to be saved before the tag replacements. Sometimes the initial commit-message comes from another commit. The formatting would have to be removed then. Hm I'm not sure yet that this is the best solution, but thats - eventually - for Richard to decide. Now it's still brainstorming time. Regards, Jan Nijtmans ___ 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 design error and possible ways to fix it
Comments and tickets are already text only. The point here is that in some very specific contexts (timeline) and under demand (there is a setting), they can be displayed as being wiki text. As this is optional, I do not see the point to make it disappear. However, with some very simple modifications, the possibility of displaying bad a user comment would be greatly reduced. In our daily practice, we use mainly 3 wiki capabilities for the comments and tickets: * bbold/b [link] In my opinion the best option would be to perform the following actions: 1) Improve slightly the wiki syntax: *[space] == [space]*[space] == [space][space]*[space][space] **bold** == bboldb (note: other syntaxes are possible: ''bold'' *bold*, just choose one) 2) Take some care when displaying wiki syntax: a) Any use of [] that does not point a real link, consider it as normal text b) Any use of that is not a recognized html tag consider it as normal text With a wise use of 2a) and 2b) there should be nearly no cases where a text only comment is displayed bad. Regards, Ramon Ribó 2012/11/22 Jan Nijtmans jan.nijtm...@gmail.com 2012/11/22 Michal Suchanek hramr...@gmail.com: On 22 November 2012 14:35, Jan Nijtmans jan.nijtm...@gmail.com wrote: I think I would fix that in the comment preprocessor. The major disadvantage is, of course, that this ugly mess will be likely visible in the command line view of the commits and that it does not allow changing the commit message format. And this whole thing is probably about allowing multiple commit formats to exist cleanly in one repo. The timeline view already has code to display the comment text without format, that could be used for eventual command-line output as well. It's only comment anyway. Another functionality of fossil is that the commit-message is saved in case the commit fails, as initial value for the next try. This message will have to be saved before the tag replacements. Sometimes the initial commit-message comes from another commit. The formatting would have to be removed then. Hm I'm not sure yet that this is the best solution, but thats - eventually - for Richard to decide. Now it's still brainstorming time. Regards, Jan Nijtmans ___ 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] Fossil design error and possible ways to fix it
This is great news! Does this mean commit comments will respect embedded [CR+LF] characters in the Timeline view? Happy Thanksgiving all you American users :) On Thu, Nov 22, 2012 at 11:23 AM, Ramon Ribó ram...@compassis.com wrote: Comments and tickets are already text only. The point here is that in some very specific contexts (timeline) and under demand (there is a setting), they can be displayed as being wiki text. As this is optional, I do not see the point to make it disappear. However, with some very simple modifications, the possibility of displaying bad a user comment would be greatly reduced. In our daily practice, we use mainly 3 wiki capabilities for the comments and tickets: * bbold/b [link] In my opinion the best option would be to perform the following actions: 1) Improve slightly the wiki syntax: *[space] == [space]*[space] == [space][space]*[space][space] **bold** == bboldb (note: other syntaxes are possible: ''bold'' *bold*, just choose one) 2) Take some care when displaying wiki syntax: a) Any use of [] that does not point a real link, consider it as normal text b) Any use of that is not a recognized html tag consider it as normal text With a wise use of 2a) and 2b) there should be nearly no cases where a text only comment is displayed bad. Regards, Ramon Ribó 2012/11/22 Jan Nijtmans jan.nijtm...@gmail.com 2012/11/22 Michal Suchanek hramr...@gmail.com: On 22 November 2012 14:35, Jan Nijtmans jan.nijtm...@gmail.com wrote: I think I would fix that in the comment preprocessor. The major disadvantage is, of course, that this ugly mess will be likely visible in the command line view of the commits and that it does not allow changing the commit message format. And this whole thing is probably about allowing multiple commit formats to exist cleanly in one repo. The timeline view already has code to display the comment text without format, that could be used for eventual command-line output as well. It's only comment anyway. Another functionality of fossil is that the commit-message is saved in case the commit fails, as initial value for the next try. This message will have to be saved before the tag replacements. Sometimes the initial commit-message comes from another commit. The formatting would have to be removed then. Hm I'm not sure yet that this is the best solution, but thats - eventually - for Richard to decide. Now it's still brainstorming time. Regards, Jan Nijtmans ___ 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Add NetSurf to allowed UserAgents
NetSurf [0] is probably a lesser known browser, but I run it on my Lemote Yeeloong, which is mips based and doesn't support larger browsers like Firefox under OpenBSD. It might be nice to have it added. Thanks. [0] http://www.netsurf-browser.org/ -- James Turner ja...@calminferno.net Index: src/login.c == --- src/login.c +++ src/login.c @@ -404,10 +404,11 @@ return 0; } if( memcmp(zAgent, Opera/, 6)==0 ) return 1; if( memcmp(zAgent, Safari/, 7)==0 ) return 1; if( memcmp(zAgent, Lynx/, 5)==0 ) return 1; + if( memcmp(zAgent, NetSurf/, 8)==0 ) return 1; return 0; } /* ** COMMAND: test-ishuman ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
