[fossil-users] The future of markdown-in-fossil
Hello, I don't want to look impatient, and I personally hate to be constantly reminded about something that hasn't actually left my mind, so I'm a bit reluctant to send e-mails like this one. All my apologies if I'm doing it wrong. So my point is only to remind you all that I'm still committed to make the fossil-in-markdown thing going forward, and I'm eagerly waiting any instructions on what to do about it next. Currently the code is in a new branch off a clone of the official fossil repository, available at http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown There is also a live demo (dedicated repository served using a fossil compiled off this branch) at http://fossil.instinctive.eu/markdown-examples/doc/tip/README.mkd What is done: + complete and seamless integration of the markdown engine into fossil (e.g. using fossil blobs as dynamic buffers), + support of markdown embedded documentation (.markdown and .mkd extensions), using current fossil style, + regular merge of latest changes from trunk. What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. I'm still willing to perform any maintenance needed on the markdown library code and/or the glue between it and fossil, for as long as I can. I would also gladly handle any knowledge-transfer needed to prevent myself from being a single point of failure in the maintenance of that code. Thanks for your interest, Natacha Porté pgpTIxNrHgoYg.pgp Description: PGP signature ___ 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] newbie questions - rollback a single file and checkin/checkout/rollback of a whole directory
On Thu, Jul 26, 2012 at 10:02 PM, Stephan Beal sgb...@googlemail.comwrote: On Thu, Jul 26, 2012 at 9:15 PM, Marc St. Onge ston...@gmail.com wrote: changes. We realize that some other aspect of File A corrupted at some point over that week and wish to rollback just File A to the beginning of the week, but retain all changes to other files that were committed during the week. A workaround, because i don't know the [or if there is a] command to do this: fossil co oldtag mv file1 ~/tmp/. fossil co trunk mv ~/tmp/file1 . Primitive, but it will work. I think this is what the revert command do. fossil revert -r commit id file name Fossil seems to detect all of these changes just fine. My problem is more about how to roll back such a directory. How can you roll back an entire directory at once, without having to go get individual files? (there could potentially be hundreds of files...) See above. :/ Maybe fossil can do this, but in my years with it i can't say i've tried, and i don't see anything in the 'help' which looks like it might do this. I don't know if the revert command works for a full directory. -- David Bariod ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] List of private branches
Hi, Is there a way to get a list of private branches in a repository? 'fossil branch list' shows all open branches, and there is no '--private' option. 'fossil tag find private' doesn't show branches created with --private, and 'fossil tag find --raw private' shows artefact IDs. I can't see a way to do this via 'fossil leaves' either. Regards, Twylite ___ 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] The future of markdown-in-fossil
On Mon, Jul 30, 2012 at 10:41 AM, Natacha Porté nata...@instinctive.euwrote: What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. i will be happy to offer my 0.0163 Euros, but i won't be able to do so until later in the week. Richard is, from what i understand, swamped for the foreseeable future. Of course, anyone else is encouraged to help :). While i don't personally use MD i'd like to see it added if only because people keep asking about it ;). Maybe then some of the religious wars can end ;). i will post back once i have looked over it. Would you prefer that i send comments regarding it to the list or to you directly? Thanks for your interest, And thank you for your contribution and persistence. To be clear: the final decision about what goes in to the trunk belongs to Richard and Richard alone. The other contributors, such as a myself, are here to assist, but the final decision rests with him. For what i'd worth, i'd like to see it included (but would like to look at the code first ;). Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] newbie questions - rollback a single file and checkin/checkout/rollback of a whole directory
On Mon, Jul 30, 2012 at 12:39 PM, David Bariod davidr...@googlemail.comwrote: I think this is what the revert command do. fossil revert -r commit id file name As the Germans say, again what learned! i can't believe i never tried that (it's how svn does it, IIRC). Maybe fossil can do this, but in my years with it i can't say i've tried, and i don't see anything in the 'help' which looks like it might do this. I don't know if the revert command works for a full directory. Apparently not: it treats them as files as says: [stephan@host:~/cvs/fossil/cwal]$ f stash save -m test REVERTED: cwal.c REVERTED: include/wh/cwal/cwal.h [stephan@host:~/cvs/fossil/cwal]$ f revert -r c5d9755013 include UNMANAGE: include (man, i love having the stash!!!) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] custom commands: two questions/RFCs
On Sun, Jul 22, 2012 at 5:49 AM, Stephan Beal sgb...@googlemail.com wrote: The CLI command, as i [currently] envision it, would look something like: fossil [fossil flags] custom [command flags] -- [args passed to the script, ignored by Fossil] The -- marker is the conventional end of args flag, used by several tools to indicate that what comes after it should be ignored by the app and/or passed on to a subordinate process. Actually -- is end of options. Everything after the -- is to be interpreted as parameters. See http://linux.die.net/man/3/getopt - The special argument '--' forces an end of option-scanning regardless of the scanning mode Your proposal sounds like a very useful idea. ___ 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] The future of markdown-in-fossil
I'd like to see it included, as well! On Mon, Jul 30, 2012 at 11:53 AM, Stephan Beal sgb...@googlemail.comwrote: On Mon, Jul 30, 2012 at 10:41 AM, Natacha Porté nata...@instinctive.euwrote: What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. i will be happy to offer my 0.0163 Euros, but i won't be able to do so until later in the week. Richard is, from what i understand, swamped for the foreseeable future. Of course, anyone else is encouraged to help :). While i don't personally use MD i'd like to see it added if only because people keep asking about it ;). Maybe then some of the religious wars can end ;). i will post back once i have looked over it. Would you prefer that i send comments regarding it to the list or to you directly? Thanks for your interest, And thank you for your contribution and persistence. To be clear: the final decision about what goes in to the trunk belongs to Richard and Richard alone. The other contributors, such as a myself, are here to assist, but the final decision rests with him. For what i'd worth, i'd like to see it included (but would like to look at the code first ;). Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] The future of markdown-in-fossil
2012/7/30 Bill Burdick bill.burd...@gmail.com I'd like to see it included, as well! I'd like it too, it will be easier for beginnes (like me!). ___ 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] custom commands: two questions/RFCs
On Mon, Jul 30, 2012 at 7:21 PM, Ron Wilson ronw.m...@gmail.com wrote: On Sun, Jul 22, 2012 at 5:49 AM, Stephan Beal sgb...@googlemail.com wrote: The -- marker is the conventional end of args flag, used by several tools to indicate that what comes after it should be ignored by the app and/or passed on to a subordinate process. Actually -- is end of options. Everything after the -- is to be interpreted as parameters. See http://linux.die.net/man/3/getopt - Oops - i've been using it the way i described above in my own apps for years :(. Oh, well. The special argument '--' forces an end of option-scanning regardless of the scanning mode Your proposal sounds like a very useful idea. It's the only idea i could think of :/. Another would be something like gdb's --args, which allows us to pass args to the app being debugged (but fossil already has an --args to read in arguments from a file). But i like -- better, and it currently has no meaning in Fossil, so there are no compatibility issues or risks of argument name collisions. i've been quite distracted lately from hacking on fossil (i _do_ have other projects ;), but custom commands are the next thing on my fossil-specific TODO list. i've got carried away the past few weeks with code which grew out of the custom pages effort (first th1, then a custom scripting mini-engine[1]), but some day soon i'll get back to adding this. The th1-query-api branch contains the current code and adds the new th1 command which i use to write/test this support (and tinker with different templating ideas). So far i'm fairly happy with what th1 can give us. It's not as convenient as, say, JS, but it does the job and it has a couple surprisingly useful features (like how it handles break/continue/return and the catch command). Plus we know the author, so we get great support for it ;). Thanks for the feedback - keep it coming. [1] http://fossil.wanderinghorse.net/repos/cwal/ -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] newbie questions - rollback a single file and checkin/checkout/rollback of a whole directory
On Mon, 30 Jul 2012 03:39:57 -0700, David Bariod davidr...@googlemail.com wrote:I don't know if the revert command works for a full directory.It doesn't, but if you happen to be on linux (or at least have grep and xargs in your path) this should work:$fossil ls | grep 'path/to/directory/' | xargs fossil revertI'd definitely recommend doing a sanity check after the first pipe though, at least until you're pretty sure everything is working as you expect:$ fossil ls | grep 'path/to/directory/'-- Themba FletcherDescription/Entity .. (tif@)descriptionentity.com209-591-8096 .. cell 317-435-6970___ 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] The future of markdown-in-fossil
On 2012-07-30 10:41, Natacha Porté wrote: Hello, I don't want to look impatient, and I personally hate to be constantly reminded about something that hasn't actually left my mind, so I'm a bit reluctant to send e-mails like this one. All my apologies if I'm doing it wrong. So my point is only to remind you all that I'm still committed to make the fossil-in-markdown thing going forward, and I'm eagerly waiting any instructions on what to do about it next. Currently the code is in a new branch off a clone of the official fossil repository, available at http://fossil.instinctive.eu/fossil-scm/timeline?r=markdown There is also a live demo (dedicated repository served using a fossil compiled off this branch) at http://fossil.instinctive.eu/markdown-examples/doc/tip/README.mkd What is done: + complete and seamless integration of the markdown engine into fossil (e.g. using fossil blobs as dynamic buffers), + support of markdown embedded documentation (.markdown and .mkd extensions), using current fossil style, + regular merge of latest changes from trunk. What remains to do: + review my code to ensure it meets fossil level of quality, + format it using fossil code style if needed, + any other code change that comes up during the review. I'm still willing to perform any maintenance needed on the markdown library code and/or the glue between it and fossil, for as long as I can. I would also gladly handle any knowledge-transfer needed to prevent myself from being a single point of failure in the maintenance of that code. Thanks for your interest, Natacha Porté Are we going to move all the wikipages to markdown? I converted the attached file to markdown it wasn't to difficult with bit of sed, awk and pandoc. What do you see as an advantage of markdown compared to the current wiki syntax? -- Reneadd --- The often used `add` command is how you tell **fossil** to include a (usually new) file in the repository. **fossil** is designed to manage artifacts whose role is being source for something, most probably software program code or other text. One can imagine all kinds of ways to let fossil know just what constitutes a source; the simplest and most direct way it *actually* finds out is when you give it the ` fossil add path ` command. It's reasonable to think of the [`import`](./cmd_import.wiki) and [`clone`](./cmd_clone.wiki) commands as very high-powered versions of the `add` command that are combined with system level file movement and networking functions. Not particularly accurate, but reasonable. Typing `fossil add myfile` causes fossil to put *myfile* into the repository at the next `commit`provided you issue it from within the source tree, of course. By contrast, `fossil add mydirectory` will add ***all*** of the files in *mydirectory*, and all of its sub-directories. In other words, adding a directory will recursively add all of the directory's file system descendants to the repository. This was an oft-requested feature, recently implemented. It is very flexible. Only when you add a directory do you get the recursive behavior. If you are globbing a subset of files, you won't get the recursion. Realize that the repository is not changed by the `add` command, but by the `commit` command. `add` *myfile* tells **fossil** to mark *myfile* as part of the repository. Only commands which actually manipulate the content of the repository can physically put source artifacts into (or remove them from) the repository. Just to keep things symmetric, there are also commands that can manipulate the repository without affecting the checked-out sources (see [fossil pull](./cmd_pull.wiki), for instance.) It's worthwhile reiterating that **fossil** is storing the content of source artifacts and the names of the artifacts in their native habitat, a sequence of temporal slices (aka versions) of the state of the whole system, and a set of unique identifiers. When you add a file to a repository, the *path* to the file is a part of the *name* of the file. There is a mis-match between the file system's idea of a directory (a file containing pointers to files) and fossil's idea (a substring of the name of the artifact.) The names of the artifacts specify their relative locations because of the way the file system interprets them. If you don't keep this in mind, you may fool yourself into thinking **fossil** somehow stores directories. It doesn't, and believing it does will eventually confuse you. See also: [fossil rm](./cmd_rm.wiki), [fossil import](./cmd_import.wiki), [fossil clone](./cmd_clone.wiki), [fossil commit](./cmd_commit.wiki), [fossil pull](./cmd_pull.wiki), [fossil setting](./cmd_settings.wiki) (async), [Reference](./reference.wiki) ___ 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] The future of markdown-in-fossil
On Mon, Jul 30, 2012 at 9:29 PM, Rene renew...@xs4all.nl wrote: Are we going to move all the wikipages to markdown? The main repo doesn't use wiki pages any more - the embedded docs feature is preferred because it's versioned along with the rest of the site. Wikis _are_ versioned but there is no UI for traversing specific versions or referencing them from [wikiLinks], etc., so they don't tend to get used much. i use them a bit in my own sites, but half of those are running a custom Google Code syntax renderer on top of a fossil back-end, using the JSON API to transport it, e.g.: http://fossil.wanderinghorse.net/wikis/cson/ that's a fossil back-end with a completely custom front-end which reveals only the wiki to the user. I converted the attached file to markdown it wasn't to difficult with bit of sed, awk and pandoc. What do you see as an advantage of markdown compared to the current wiki syntax? Here's a similar script for fossil-to-GoogleCode format can probably be re-used a bit for markdown: http://whiki.wanderinghorse.net/?page=fossil2whiki.sh Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] The future of markdown-in-fossil
Looks like it's using wiki pages, to me, just not stored in the Fossil wiki -- at least, that what the Editor button tells me... :) On Mon, Jul 30, 2012 at 5:52 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jul 30, 2012 at 9:29 PM, Rene renew...@xs4all.nl wrote: Are we going to move all the wikipages to markdown? The main repo doesn't use wiki pages any more - the embedded docs feature is preferred because it's versioned along with the rest of the site. Wikis _are_ versioned but there is no UI for traversing specific versions or referencing them from [wikiLinks], etc., so they don't tend to get used much. i use them a bit in my own sites, but half of those are running a custom Google Code syntax renderer on top of a fossil back-end, using the JSON API to transport it, e.g.: http://fossil.wanderinghorse.net/wikis/cson/ that's a fossil back-end with a completely custom front-end which reveals only the wiki to the user. I converted the attached file to markdown it wasn't to difficult with bit of sed, awk and pandoc. What do you see as an advantage of markdown compared to the current wiki syntax? Here's a similar script for fossil-to-GoogleCode format can probably be re-used a bit for markdown: http://whiki.wanderinghorse.net/?page=fossil2whiki.sh Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] The future of markdown-in-fossil
Very slick front-end, BTW! On Mon, Jul 30, 2012 at 5:58 PM, Bill Burdick bill.burd...@gmail.comwrote: Looks like it's using wiki pages, to me, just not stored in the Fossil wiki -- at least, that what the Editor button tells me... :) On Mon, Jul 30, 2012 at 5:52 PM, Stephan Beal sgb...@googlemail.comwrote: On Mon, Jul 30, 2012 at 9:29 PM, Rene renew...@xs4all.nl wrote: Are we going to move all the wikipages to markdown? The main repo doesn't use wiki pages any more - the embedded docs feature is preferred because it's versioned along with the rest of the site. Wikis _are_ versioned but there is no UI for traversing specific versions or referencing them from [wikiLinks], etc., so they don't tend to get used much. i use them a bit in my own sites, but half of those are running a custom Google Code syntax renderer on top of a fossil back-end, using the JSON API to transport it, e.g.: http://fossil.wanderinghorse.net/wikis/cson/ that's a fossil back-end with a completely custom front-end which reveals only the wiki to the user. I converted the attached file to markdown it wasn't to difficult with bit of sed, awk and pandoc. What do you see as an advantage of markdown compared to the current wiki syntax? Here's a similar script for fossil-to-GoogleCode format can probably be re-used a bit for markdown: http://whiki.wanderinghorse.net/?page=fossil2whiki.sh Happy Hacking! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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
