Re: [fossil-users] Fossil design error and possible ways to fix it
On 11/22/2012 5:05 AM, Richard Hipp wrote: 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. For commit messages, I frequently use a message like See ticket [deadbeef] when the checkin is directly related to a ticket. Personally, I don't think I've ever wanted to use [] in a commit message for anything else. But then, I try hard to use tickets to hold the larger issue discussions and keep commit messages short and to the point. Since the wiki render also displays the links to closed tickets distinctly, this works out nicely. Changing commit messages to a pure text/plain interpretation would break that usage. Unless you consider a ticket or checkin uuid in brackets to also be a valid URL, if the referenced artifact exists. That would have the benefit of providing some visual feedback for mis-typed artifact names by not making those be links. That said, I do support the idea that the commit comment get a very light handed markup treatment. It fits my personal workflow well if the commit comments are expected to be short and largely free of markup. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil design error and possible ways to fix it
On Mon, Nov 26, 2012 at 2:31 PM, Ross Berteig r...@cheshireeng.com wrote: On 11/22/2012 5:05 AM, Richard Hipp wrote: 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. For commit messages, I frequently use a message like See ticket [deadbeef] when the checkin is directly related to a ticket. Personally, I don't think I've ever wanted to use [] in a commit message for anything else. But then, I try hard to use tickets to hold the larger issue discussions and keep commit messages short and to the point. Since the wiki render also displays the links to closed tickets distinctly, this works out nicely. Changing commit messages to a pure text/plain interpretation would break that usage. Unless you consider a ticket or checkin uuid in brackets to also be a valid URL, if the referenced artifact exists. That would have the benefit of providing some visual feedback for mis-typed artifact names by not making those be links. That said, I do support the idea that the commit comment get a very light handed markup treatment. It fits my personal workflow well if the commit comments are expected to be short and largely free of markup. I changed the rendering of commit messages at http://www.fossil-scm.org/fossil (and at http://www.sqlite.org/src and several other places) to only decorate hyperlinks and to leave everything else in the commit message unchanged. This occurred in the middle of last week. Everything seems to continue to work fine. There is some occasional mojibake (see http://localhost:591/fossil/timeline?c=bf67db06 for example) but for the most part all the messages appears the same as before. Nobody has complained yet. So I think what you suggest is probably going to be what we end of going with. The next release will have an option on the Admin/Timeline menu to let you enable/disable plaintext commit messages. The default will be off for legacy repositories and on for new repositories. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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] Fossil design error and possible ways to fix it
IMO this should be resolved per-server configuration. Consider the risk of XSS attacks: simply treating all comments as text/plain automatically mitigates any past XSS attack attempts. Granted, XSS attacks are not very likely given that few users can be expected to have commit access... I would prefer that the UI allow the user to select between HTML, wiki, and text/plain, thus allowing for future markup types (e.g., asciidoc); the default (for new comments) should be text/plain. The format of old comments should be given by a server-side configuration parameter. The available formats for new comments should be constrained by a server-side config param. Nico -- ___ 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
In my workflow each commit is associated with a ticket. This provides me with requirement tracking and traceability from the requirements/tasks/defects stored in tickets to the code or data changes in the repository. So like Ross I would like the functionality using the [hashcode] to be maintained. I would actually like a warning if [hashcode] link doesn't exist. On Mon, Nov 26, 2012 at 11:31 AM, Ross Berteig r...@cheshireeng.com wrote: On 11/22/2012 5:05 AM, Richard Hipp wrote: 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. For commit messages, I frequently use a message like See ticket [deadbeef] when the checkin is directly related to a ticket. Personally, I don't think I've ever wanted to use [] in a commit message for anything else. But then, I try hard to use tickets to hold the larger issue discussions and keep commit messages short and to the point. Since the wiki render also displays the links to closed tickets distinctly, this works out nicely. Changing commit messages to a pure text/plain interpretation would break that usage. Unless you consider a ticket or checkin uuid in brackets to also be a valid URL, if the referenced artifact exists. That would have the benefit of providing some visual feedback for mis-typed artifact names by not making those be links. That said, I do support the idea that the commit comment get a very light handed markup treatment. It fits my personal workflow well if the commit comments are expected to be short and largely free of markup. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ -- Clive Hayward ___ 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 11/22/2012 05:05 AM, Richard Hipp wrote: (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. Could new versions of Fossil assume the old behavior on any repository they encounter... unless this configuration option is set, or another internal-to-the-repository flag is set? And then, the only way this flag will be automatically set is when you issue a 'fossil rebuild' under the new versions? Or is this getting to be too cumbersome, just to maintain some backward compatibility? ___ 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
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
