Re: [fossil-users] Tags in comment document
Thus said Philip Bennefall on Sun, 07 Sep 2014 19:39:40 +0200: However, non-propagating tags added with tag add do not show up. So even though both tags are non-propagating, one of them shows up but not the other. fossil tag modifies artifacts *AFTER* they have been created. fossil checkin --tag causes the checkin to add a tag to the new artifact's manifest. This also means that when you use fossil checkin --tag, that this tag will only ever show up once during that very checkin that you are about to commit. Try this; modify a file (test repository if needs be): fossil ci --tag newtag You see it in your editor for the commit message, right? Complete the checkin. Then modify a file and make another commit: fossil ci Do you see newtag in the comment document in your editor? Why? Andy -- TAI64 timestamp: 4000540d4831 ___ 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] Tags in comment document
Thus said Andy Bradford on 08 Sep 2014 00:09:18 -0600: fossil tag modifies artifacts *AFTER* they have been created. Minor technicality... it doesn't modify the artifact per se, it generates a control file artifact that applies to the artifact. Andy -- TAI64 timestamp: 4000540d4a51 ___ 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 for web site maintenance [was how to use git to lose data]
On 06/09/14 17:03, Richard Hipp wrote: I'll let Scott answer the specific question. But I just want to remind Miles of the Embedded Documentation feature of Fossil (http://www.fossil-scm.org/fossil/doc/tip/www/embeddeddoc.wiki) and that the main Fossil website including all of the on-line documentation is really just a running instance of Fossil serving the Fossil self-hosting repository. (All of the main website, except the Download page, that is.) I have a related kind of setup at https://www.kitten-technologies.co.uk/ The top-level site is static HTML (but generated via scripts from master content in a fossil repo). However, there are a number of fossil repos for different projects, which are invoked via fossil-as-cgi. https://www.kitten-technologies.co.uk/project/kitten-technologies is the project that generates the master site, which includes the cgi thingies! Eg, /project/kitten-technologies itself comes from https://www.kitten-technologies.co.uk/project/kitten-technologies/artifact/cdeb6789a25bed09afebb6c4f8577a5fc00ad349 And I've hacked the CSS around like crazy to all refer to the central stuff. Per-repo stuff like the skin gets rolled out from the central configuration by a script. It... works! And keeps down the maintenance cost for me of a heap of fossil repos for my crazy open-source outpourings. ABS -- Alaric Snell-Pym http://www.snell-pym.org.uk/alaric/ signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Checkboxes for tickets
Hi fossilers,
I'm trying to implement checkboxes within tickets using TH1. First question --
has anyone managed to do this?
In common I have:
set status_choices {New
Features
Uninteresting}
While the database column is status. I've tried the following:
th1
for {set i 0} {$i [linecount $status_choices 50 0] } {set i [expr $i+1]} {
html input type=\checkbox\ name=\status\ value=\[lindex $status_choices
$i]\
if {[string compare [lindex $status_choices $i] status ] eq 0} {
html checked
}
html /[lindex $status_choices $i]
}
/th1
Which doesn't work because upon submission, only the first checkbox is ever
recorded. So I thought I might get clever and get around this with the
preview button by using intermediate variables for each checkbox. I.e.,
checkbox 0 has name status_0, which ALMOST works, but I can't dynamically
call my variable... so I would be stuck hardcoding. Is dynamic variable calling
possible in TH1?
th1
if { ![info exists status] } {set status }
for {set i 0} {$i [linecount $status_choices 50 0] } {set i [expr $i+1]} {
if { [info exists status_$i] } { set status $status \n $status_$i }
}
html Status: $status.
set status_regexp [lindex $status 0]
for {set i 1} {$i [linecount $status 50 0] } {set i [expr $i+1]} {
set status_regexp $status_regexp|[lindex $status $i]
}
if {![info exists status]} {set status New}
for {set i 0} {$i [linecount $status_choices 50 0] } {set i [expr $i+1]} {
html input type=\checkbox\ name=\status_$i\ value=\[lindex
$status_choices $i]\
if {[ regexp $status_regexp [lindex $status_choices 0] ]} {
html checked
}
html /[lindex $status_choices $i]
}
/th1
Any help would be appreciated! Even if it is to tell me that what I'm doing
can't be done in TH1.
Maybe the HTML parser for the form submission could simply append multiple
instances of the same name either as new lines or as commas?
Thanks,
Tomek
___
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] Tags in comment document
On 9/7/2014 17:10, Will Parsons wrote: I have to admit that I *hate* to mistype a commit message and have it frozen for all time. Using an editor just seems so much easier... Fossil lets you edit commit messages. In true Fossil fashion, the old message isn't overwritten, just *overridden*, so someone can still dig up your errors, but at least they don't show up by default in the timeline any more. I'll put in my vote for always using $EDITOR, by the way. Sometimes one of my commit messages actually stretches to the point of needing paragraphs, either because the problem it fixes is particularly complex or because the solution/feature is. That brings up a Fossil nit: the timeline compresses whitespace in commit messages, so you can't see paragraph breaks without digging down into the individual checkin. I wish it would not collapse double newlines. I'm fine with it joining lines separated by only a single newline, so that my max-72-column wide commit messages fill the window width in the browser, but if I put in a double newline, fossil ui should show a paragraph break. I will say that I treat a multi-paragraph commit message as a warning sign. I ask myself if the commit message is getting long because either the checkin is overly complex, or because I don't really understand what's going on. Sometimes I can simplify or clarify the change or its checkin comment, but not always. Sometimes the act of composing such a long checkin comment clues me into a better fix, which I would never have discovered if I didn't try to thoroughly explain the whys of each change. ___ 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] Tags in comment document
On Mon, Sep 8, 2014 at 10:49 AM, Warren Young war...@etr-usa.com wrote: the timeline compresses whitespace in commit messages, so you can't see paragraph breaks without digging down into the individual checkin. I wish it would not collapse double newlines. Have you tried selecting the Allow block-markup in timeline option on the Admin/Timeline 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] Tags in comment document
On Mon, Sep 8, 2014 at 10:49 AM, Warren Young war...@etr-usa.com wrote: Sometimes one of my commit messages actually stretches to the point of needing paragraphs, either because the problem it fixes is particularly complex or because the solution/feature is. On the problem description side, I use tickets - even for my personal projects. Doing it for work got me in to the habit. And when I don't use a ticket, I put the details in the source comments (which may be a better place, anyway, On the fix description side, I put any detail commentary in the source comments and include a reference to the ticket. Even if you are putting the details in the commit comment, they still need to be in the source comments where the fix was made. If a fix requires changes in widely separated parts of the code, I pick one place as the epicenter and have the satellites reference that (of course, the satellite comments still need and get localized details). Almost always, I can keep commit comments down a few lines ___ 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] Tags in comment document
On Mon, Sep 8, 2014 at 6:26 PM, Ron W ronw.m...@gmail.com wrote: On the fix description side, I put any detail commentary in the source comments and include a reference to the ticket. Even if you In my experience a ticket number is the longest-lasting/maintainable approach (though _all_ of my colleagues complain when i do it, i refuse to remove ticket numbers from code, and i re-add them and raise a ruckus if a fellow coder removes them during review). A ticket can be indefinitely extended with new information, which is particularly useful for big (large scope/impact) bugs/changes. It also provides the history (including political decisions) of a particular fix/RFE, and doesn't require updating the source code comments every time the specifics of the ticket change. -- - 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] Tags in comment document
On 9/8/2014 08:51, Richard Hipp wrote: On Mon, Sep 8, 2014 at 10:49 AM, Warren Young war...@etr-usa.com mailto:war...@etr-usa.com wrote: I wish it would not collapse double newlines. Have you tried selecting the Allow block-markup in timeline option on the Admin/Timeline page ? Beautiful, thanks! That mostly does what I want. It didn't cope with a packed bullet list: - item 1 - item 2 - item 3 I had to put a blank line between each. I don't think I will ask you to add a Markdown option for comment formatting to fix this, however. :) ___ 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] Tags in comment document
On Mon, Sep 8, 2014 at 12:32 PM, Stephan Beal sgb...@googlemail.com wrote: In my experience a ticket number is the longest-lasting/maintainable approach (though _all_ of my colleagues complain when i do it, What don't they like about putting ticket IDs in the code comments? ___ 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] Tags in comment document
On Mon, Sep 8, 2014 at 7:14 PM, Ron W ronw.m...@gmail.com wrote: On Mon, Sep 8, 2014 at 12:32 PM, Stephan Beal sgb...@googlemail.com wrote: In my experience a ticket number is the longest-lasting/maintainable approach (though _all_ of my colleagues complain when i do it, What don't they like about putting ticket IDs in the code comments? i haven't the slightest clue, and not one of them has been able to explain it to me, despite offering them thought/role-playing experiments such as: You are venturing through some deep, dark code and come across the following runes written on the wall: /* PRT-123 */ What do you do? The answer, invariably (and correctly), is go look up that ticket number in Jira. RIGHT! But they still don't like seeing it. Seems to be just a force of habit. -- - 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] Tags in comment document
On Mon, Sep 8, 2014 at 1:18 PM, Stephan Beal sgb...@googlemail.com wrote: The answer, invariably (and correctly), is go look up that ticket number in Jira. RIGHT! But they still don't like seeing it. Seems to be just a force of habit. I think perhaps your experimental subjects are expecting that to be the answer. I think a better experiment might be to find a complex change one of them made, then ask them to explain to you what they were trying to do. Or, maybe, pick a complex issue then, after you devise the real fix, devise a bizarre version of the fix - without any reference to the issue - then let them try to review that. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] wysiwyg editing of ticket
I recently upgraded to Fossil version 1.29 and I love both the ability to do wysiwyg editing of wiki pages and the flexibility to use Markdown as well. However, I would like to see this capability applied to the ticket description field as well - is there any hope for this? Or is it already there and I am just missing it? :: paul ___ 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] wysiwyg editing of ticket
On Mon, Sep 8, 2014 at 6:56 PM, Paul Higham pa...@janmedical.com wrote: I recently upgraded to Fossil version 1.29 and I love both the ability to do wysiwyg editing of wiki pages and the flexibility to use Markdown as well. However, I would like to see this capability applied to the ticket description field as well - is there any hope for this? Or is it already there and I am just missing it? I think it could probably be accomplished already, with a creative ticket setup. But I'm not certain. I don't recall anybody having ever tried it before. -- 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] Tags in comment document
On Tue, Sep 9, 2014 at 12:17 AM, Ron W ronw.m...@gmail.com wrote: I think perhaps your experimental subjects are expecting that to be the answer. Very possibly. I think a better experiment might be to find a complex change one of them made, then ask them to explain to you what they were trying to do. Or, maybe, pick a complex issue then, after you devise the real fix, devise a bizarre version of the fix - without any reference to the issue - then let them try to review that. LOL! That's not a bad idea, especially if they wait until 4 weeks after the commit to review it, in which case i can answer any questions with, how should i know? That was four weeks ago! Did nobody write a ticket number in the comments? ;) -- - 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
