Re: [fossil-users] Command line access to technotes and attachments
On 14/12/2015 15:20, Richard Hipp wrote: I don't recall anybody ever writing such commands. There is nothing technically difficult about doing so - I just don't think the need has come up before. The technote code is in the event.c source file. You can use the "wiki" command implement in "wiki.c" as a guide for adding similar command-line editing capabilities to technotes in the event.c source file, if you want to do a little hacking. Okay, thanks for confirming that. I'll take a look at source code and see if I can modify it as suggested. Despite my C knowledge being a little rusty (nearly two decades since I last did serious work in C) it doesn't look too difficult - famous last words! David ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Command line access to technotes and attachments
I've just started playing with fossil for my personal projects and I'm considering getting my some of my one-touch builds to create a technote with the build artifacts as attachments. However I don't see an easy command line way to create either technote's or attachments - Am I just missing something obvious? David Vines ___ 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] Command line access to technotes and attachments
On 16/12/2015 15:50, Ron W wrote: Minor issue: While Fossil is inconsistent with this, the common convention for "long options" is --option with 2 dashes. I haven't used the "-mimetype" option so I don't know if it's a documentation error or implementation oversight. In other Fossil commands the double dash, "--", is accepted. The preexisting implementation in find_option allows both single and double dashes for both the long and short forms of the options. I'll make sure my documentation matches the desired double form of the option. In the rest of the documentation there a few inconsistencies, but only a few (the ones I've spotted are in the rss, search and version commands). David ___ 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] Command line access to technotes and attachments
On 15/12/2015 09:55, Stephan Beal wrote: Here's an encouraging anecdote for you: my first C work after 1995[1] was implementing the wiki CLI commands Richard mentioned :). i concur that the wiki commands would be the best starting point for adding Tech Note (formerly "event") CLI support. It has indeed proved quite straightforward! Since I have done enough for a prototype, I'd like to get feedback on my proposed CLI change for technotes before I discard the prototype and redo it into something I'd be prepared send in as a patch: Usage: ../fossil wiki (export|create|commit|list) WikiName Run various subcommands to work with wiki entries or tech notes. ../fossil wiki export ?PAGENAME? ?FILE? [-t|-technote DATETIME ] Sends the latest version of either the PAGENAME wiki entry or the DATETIME tech note to the given file or standard output. One of PAGENAME or DATETIME must be specified. ../fossil wiki (create|commit) PAGENAME ?FILE? ?OPTIONS? Create a new or commit changes to an existing wiki page or technote from FILE or from standard input. Options: -M|-mimetype TEXT-FORMAT The mime type of the update defaulting to the type used by the previous version of the page or (for new pages) text/x-fossil-wiki. -t|-technote DATETIME Specifies the timestamp of the technote to be created or updated. -technote-tags TAGSThe set of tags for a technote. -technote-bgcolor COLORThe color used for the tehnote on the timeline. ../fossil wiki list ?-technote? ../fossil wiki ls ?-technote? Lists all wiki entries, one per line, ordered case-insensitively by name. The -technote flag specifies that technotes will be listed instead of the wiki entries, which will be listed in order timestamp. David ___ 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] Adding attachments via the command line
On 04/01/2016 12:21, Stephan Beal wrote: fossil att[achment] add ... If it's a subcommand of "wiki" then the ability to use any unique short form of it doesn't come for free (that only works for top-level commands). :-? I was unaware of this capability, and it makes sense to me. The length of the command didn't worry me since my main use is from inside an ant script, but I can see the advantage and I'm very happy to make this change. David ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Adding attachments via the command line
I now have a prototype for command line access to add attachments to wiki pages and tech notes. I'd like to ask for any feedback on the command itself before I polish my changes and put the changes up for review: fossil wiki attachment add ?PAGENAME? FILENAME [-t|--technote DATETIME ] Add an attachment to an existing wiki page or tech note. One of PAGENAME or DATETIME must be specified. I made "attachment" as a noun to allow for the later addition of other verbs like list and export. I don't propose to change the ticket since (a) I don't need it myself and (b) the existing ticket command just modifies the metadata for existing tickets and doesn't allow creation of tickets or the addition of text to existing tickets. David ___ 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] Completely untagged commits ?
On 05/01/2016 18:53, bch wrote: How did we end up w/ dave.vines' completely untagged (no branch) commits in the repository (or am I misreading what these are?) ? ref: /info/b208bf75777604dc /timeline?u=dave.vines=2016-01-05+10%3A12%3A56=200 If I've messed this up, I do most humbly apologise and want to fix it ASAP - but I see this as tagged as "technoteattachcli", at least in the fossil-scm.org web ui. One curious aspect I do see is that the web ui has the annotation of "unpublished" against the creation of the branch. I did start by have a private branch which I then published - I do wonder if this might be part of the problem. David ___ 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] Completely untagged commits ?
On 05/01/2016 19:53, Richard Hipp wrote: On 1/5/16, bchwrote: What's incorrect, the documentation, or the implementation ? Both, IIRC. I think you can convert a private branch to public by cancelling the "private" tag. But I don't think that feature is completely operational right now. But it has been over a year since I worked on any of that. And I'm tied up working on SQLite right this moment and can't stop to look. And what I read (and was presumably misled by) was the help text on fossil publish which says "can be used (for example) to convert a private branch into a public branch." Looking at the code in publish.c my current suspicion is that it marks everything as public in the branch except for the branch itself. Hence the branch artifact has a "+private" tag record. David ___ 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] Adding attachments via the command line
On 04/01/2016 14:07, John P. Rouillard wrote: In message <568a7b26.7020...@zombi.eclipse.co.uk>, David Vines writes: On 04/01/2016 12:21, Stephan Beal wrote: fossil att[achment] add ... If it's a subcommand of "wiki" then the ability to use any unique short form of it doesn't come for free (that only works for top-level commands). I was unaware of this capability, and it makes sense to me. The length of the command didn't worry me [...] but I can see the advantage and I'm very happy to make this change. Would this change also make sense for (a future extension) of fossil att[chment] --ticket , to add an attachment to a ticket? It does, though adding an "attachment" subcommand to ticket would have been the corresponding variate. Would adding the capability be of use to you? It's a relatively trivial extension to an attachment command version David ___ 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 amend ----edit-comment
On 22/02/2016 06:28, jungle Boogie wrote: Question: Would one expect server A to pick up the amended timeline entry with the process above, or have I made a mistake with my amending? With autosync enabled, a synchronization happens prior to 'commit' and 'update' operations and after 'commit' and 'pull' operations. (For a commit the sync happens before and after). It doesn't automatically happen for other operations. You should find that your amendment will get pushed onto server A on the next commit, update or pull on server B. Of course, a manual sync or push will also get the amendment to server A. -- David ___ 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 request: syntax highlighting for file, diff and code block rendering
You may need to extend the list of file extensions in ext/syn.js, for example to support js as an extension for javascript I added case "js": t = "javascript"; break; Dave On 24/04/2016 18:04, Marko Käning wrote: Hi Svyatoslav, On 24.04.2016 14:31, Svyatoslav Mishyn wrote: see: http://www.fossil-scm.org/index.html/wiki?name=shjs I tried this out, but unfortunately it didn't highlight anything for me. Greets, Marko ___ 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] some uglifications for diff.tcl
The comment style problem in attach.c is my fault - I'll provide a fix (I'm far too used to the // style of comment :) 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] Support for commonmark markdown in fossil
On 13/03/2017 15:50, Warren Young wrote: A related wish that comes up here now and then is some kind of pretty-printer support, so that common programming languages are colored nicely. Google’s code-prettify JS library would work for this: https://github.com/google/code-prettify Admittedly it only does syntax colouring (and not formatting), but I found the instructions at the link below of how to add syntax colouring to a repository pretty straight forward to follow: https://www.fossil-scm.org/xfer/wiki?name=Cookbook#source-hilight Dave ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users