Re: [fossil-users] What you think about this functionality?
On Jan 26, 2012, at 2:47 PM, Andreas Kupries wrote: I love the ability to make a number of unrelated changes, or a bunch of related changes and then still be able to commit them independently. Or in the case of related stuff as a series of changes showing a nice progression in the implementation. It's not just the ability to do it, sometimes it is natural. For example, I am working on new feature ABC and in the process I discover a new bug. I fix that bug, but it's totally unrelated to the new feature. I like to commit change XYZ as it's own commit and as a bug fix, not as part of the New ABC Feature commit. Jeremy ___ 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] What you think about this functionality?
On Jan 26, 2012, at 2:54 PM, Lluís Batlle i Rossell wrote: On Thu, Jan 26, 2012 at 02:51:04PM -0500, Richard Hipp wrote: On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski http://nuclearsquid.com/writings/git-add/ Any opinions? I'm of the old-fashioned opinion that you ought to test your code before you check it in. Very well explained! I totally agree. I imagine that in git, users are expected to commit wrong untested code (thus, that may not match the commit log), and some minutes later, edit all the history to make up. Also not testing the rewrites, of course. The git workflow. Hm. I don't think that committing a partial file means you have not tested the code. Take for example my previously stated example, a file named math.b func add(a,b) return a * b end func sub(a,b) return a - b end -- New feature, multiplication func mul(a,b) return a * b end While editing I see that add is using multiplication! Doh! I whip up a few unit tests: test_equal(add(1,1), 2) test_equal(add(5,5), 10) Great, all passes. My math expansion, however, is not done. I still need to add the requested division method and other branches can benefit from my add fix, but the new math expansion still needs quite a bit of testing, peer reviews, etc… So, I want to make my add bug fix available as a simple commit that can be pulled. So, I commit just a section of math.b, and math_tests.b. Jeremy ___ 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] Supporting markwon syntax for wiki
Fantastic. Hopefully this makes it into the trunk version of Fossil. Jeremy On Jan 13, 2012, at 6:47 AM, Bill Burdick wrote: Excellent! Bill On Fri, Jan 13, 2012 at 11:18 AM, tin-pot tin-...@gmx.net wrote: Jan Danielsson jan.m.danielsson@... writes: On 05/24/11 08:08, Baptiste Daroussin wrote: [---] Markdown is a really simple format that would imho greatly improve the embed wiki of fossil. Agreed. I'd love to see markdown support in fossil. Good news then :-) I have added the `discount` Markdown implementation into Fossil version 1.21. This is actually pretty simple to do. First, get David L. Parson's `discount` package from the author's site [1]; this is a classical configure/make source tree, so if you are on Windows, you might be interested in my adaptation [2] of it for Windows/MSVC on github. Building should give you a static library `markdown.lib` (rsp. `markdown.a`). The only thing that must be changed in Fossil (besides letting the compiler and linker find the Markdown lib in the Makefile) is the source file `wikiformat.c`. I have put the modified file in my public Dropbox [3], the changes can easily be found by looking for the macro `WITH_MARKDOWN`. If you define it (in your Makefile), all wiki content (and log messages if switched on etc.) will use extended Markdown, while the Fossil-style links still work. See David Parson's page for the details on which syntax extensions are available. This is in an early stage of development and needs testing, and of course the user should have the option to enable Markdown in the web interface, individually for each wiki page rsp artifact would be best ... - but it's a start anyway. Feel free to experiment with that and to proliferate it. Cheers M.H. [1]: http://www.pell.portland.or.us/~orc/Code/discount [2]: https://github.com/tin-pot/discount [3]: http://dl.dropbox.com/u/13455033/wikiformat.c ___ 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
Re: [fossil-users] Supporting markwon syntax for wiki
On Jan 13, 2012, at 7:02 AM, BohwaZ wrote: Le Fri, 13 Jan 2012 06:49:19 -0500, Jeremy Cowgar jer...@cowgar.com a écrit : I personally prefer the github flavored markdown because some things in Markdown are really counter-intuitive, like typing : First line Second line Displays as : First line Second line This feature is also present in actual Fossil wiki syntax, and I dislike it very much as users don't get why a line break doesn't display as a line break. That is standard w/about any markup language, for example what you typed in HTML would also appear as First line Second line. The reasoning is that line breaks are not normal in text. Paragraph breaks are. Thus you take the norm and make it easy, the abnormal (or the exception) is the one that requires you do to something differently. You do, however, have paragraph breaks. That is achieved by 1 blank line in between your paragraphs, just as you would with an email, such as what I just did here. If you wish to specifically format you text with individual lines then you can use the nowiki tag or the pre tag to tell the syntax parser not to touch your text. This, however, most of the times does not achieve a readable text structure. Jeremy ___ 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] Supporting markwon syntax for wiki
Natacha's library is very easy to use and it has always done me right. I've written a Tcl wrapper around it. I'd highly suggest checking it out. Further, Natacha already said that the copyright issue wouldn't be a problem and on top of that a fossil user. Jeremy On Jan 13, 2012, at 10:45 AM, Martin Hofmann wrote: Hello Natacha, Datum: Fri, 13 Jan 2012 16:06:07 +0100 Von: Natacha Porté nata...@instinctive.eu An: fossil-users@lists.fossil-scm.org Betreff: Re: [fossil-users] Supporting markwon syntax for wiki Good, I'm glad to see you are aware of the hard part (yes, you understood correctly what I meant), and that you have even put some thoughts into it. That covers all I was worried about, so congratulations for what you've done and I wish you success for what remains to be done. Yep, there is still the bigger part to be done, d'accord :-) I'm only a bit sad about the duplication of work in including different markdown engines into fossil. However I like to believe I still have a head-start in that I'm already willing to hand over copyright (assuming I can keep it over my own independant copy). Oh, that I grabbed `discount` is rather coincidental: it is one of the few C-only implementations (that I know of, the other one being Fletcher T. Penney's [`multimarkdown`] [1]). Furthermore, it has a BSD- style licence and is intended to be used as a library. Also, according to a private communication from a github employee, they switched from discount to a fork of my library because of several critical security vulnerabilities that are not quite trivial to fix. I haven't been able to gather any further details, but considering how wide wiki-append-permissions seem supposed to be, I wouldn't treat wiki contents as trusted. Didn't know that. On their [website] [2] they (still?) profess to use `Redcarpet`, a wrapper around the `Sundown` library (that I don't know much either). Anyway, I'm not fixated on `discount` and would happily try out your library as well, if that's alright with you. What is needed by me is basically a simple string-in-string-out API. But then again, standard markdown allows raw HTML inclusion, so security issues will eventually be raised (at least for people like me who would not trust wiki contributors with raw HTML). You have point. Maybe it is possible to tame the generated HTML by checking for and removing of elements and attributes that are out of limits ...? Thanks for your support! Martin [1]:https://github.com/fletcher/peg-multimarkdown [2]:http://github.github.com/github-flavored-markdown/ -- Okay, buzzwords only. Two syllables, tops. -- Laurie Anderson ___ 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] C API
Does the JSON interface work via the command line? It'd be a bummer for a user wanting to simply script fossil to have to run a server just to do some local scripting. Jeremy On Jan 8, 2012, at 12:32 PM, Chad Perrin wrote: On Sun, Jan 08, 2012 at 12:36:58PM +0800, Michael Richter wrote: And Ruby has no JSON tools? (Hint: yes it does.) Thank you for your sarcasm. That's very helpful. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Behavior of rm, mv, and changes/extra
I’m in the same boat, doing two actions for every one in other SCM systems, however I do not do it dozens of times a day, so I’ve always just done it with a little gnashing of the teeth. I wonder if an option isn’t in order maybe with a preference? Thus CVS guys can have it their way and normal people can have it the right way? Jeremy From: Richard Hipp Sent: Wednesday, December 21, 2011 12:25 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Behavior of rm, mv, and changes/extra $ fossil rm file1 DELETED file1 $ ls file1 $ rm file1 Is there a reason behind this design decision? Because that is the way CVS works. And Fossil was written to replace CVS as the CM system for SQLite. Oh, you mean a *good* reason for this behavior? Then the answer is no. I fear to change it now, though, since it might really mess up people who are used to the older style. I'm on the verge of creating my own wrapper script around fossil to get this done in one step. Especially at early stages of the project I perform these operations frequently. It just feels wrong to have to say the same thing (as I see it) twice. fossil changes; fossil extra; : These guys I just dont get. I had to write an alias in my bashrc just because it was getting really annoying. I use 'hg status' and 'git status' multiple times before I commit to get an instant look at what im doing: what file have I touched AND what new files have I created that I need to remember to add to source control. With fossil I have to execute two commands to get the same amount of information. If I do just fossil changes, I inevitably forget to 'fossil add' something. Again, this is especially relevant during the early stages of a project where things change much more dramatically (at least in my case.) To recap: Why not perform file system changes when fossil is instructed to delete or rename a file? Why not have a single command that gives you ALL differences between your working tree and the repository? Best, -Nick ___ 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 wlEmoticon-openmouthedsmile[1].png___ 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] Behavior of rm, mv, and changes/extra
So it goes beyond the strict definition of a SCM system, just like every other modern SCM system does. What's the problem (besides saving the user time which is money)? Jeremy -Original Message- From: Dmitry Chestnykh Sent: Wednesday, December 21, 2011 2:36 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Behavior of rm, mv, and changes/extra Fossil have commands to manage your working tree, like checkout/revert/undo/redo/stash/merge. They do things to files in directories. rm/mv are inconsistent with this behavior. ___ 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] Behavior of rm, mv, and changes/extra
fossil rm should not remove a file it doesn't manage or has changes, just like other SCM systems. In this case, the file in question has changes, as it is brand new, the entire file has changed. Thus, if you were to (in the future) do: $ fossil rm #document_manager.php# File has changes, not removing from disk. Jeremy -Original Message- From: Themba Fletcher Sent: Wednesday, December 21, 2011 4:40 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Behavior of rm, mv, and changes/extra Well here's a fun thing that just happened: tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/ site/common/classes/document_manager.php tif@w...:~/Projects/ACSS/project$ fossil extra | grep -v db/ | xargs fossil add ADDED site/common/classes/#document_manager.php# ADDED site/common/classes/document_manager.php So in the time it took me to type up-arrow | xargs fossil add my editor pulled an auto-save, and fossil added (2) files instead of one. Now I've got: 1. a file in my repo that I don't want 2. and it's not under version control, so I can't get it back if fossil deletes it It's a simple fossil rm away from being solved, but ... Assume a destructive fossil rm, and let's say the file is precious rather than just an autosave file. Lots of ways to get around the auto delete, but not necessarily obvious ones and someone, somewhere is going to learn how it works the first time by having fossil delete their file unexpectedly. Nope, I suddenly find myself a fan of the two step process as it stands. ___ 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 version 1.21
There is already an RSS feed, project.org/timeline.rss. As for Twitter being for little girls and housewives, millions of people disagree :-) Jeremy -Original Message- From: Konstantin Khomoutov Sent: Tuesday, December 13, 2011 12:12 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Fossil version 1.21 On Tue, 13 Dec 2011 11:56:42 -0500 Richard Hipp d...@sqlite.org wrote: Point of curiosity: Is there a Twitter feed for Fossil? I was thinking the other day that it might be cool to have a feature whereby a Fossil server would tweet every time it got a new check-in or ticket or wiki edit, etc. Any volunteers to contribute code? Why tweet? This is a proprietary service for little girls and housewives. Providing an RSS feed on relevant pages (timeline, namely) would be just right (some wiki engines do this for their changes page for instance). ___ 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] Automatically enabled hyperlinks
Good point. Jeremy -- Original Message -- From: Ron Wilson ronw.m...@gmail.com To: Jeremy Cowgar jer...@cowgar.com;Fossil SCM user's discussion fossil-users@lists.fossil-scm.org Sent: 11/28/2011 12:52:46 PM Subject: Re: [fossil-users] Automatically enabled hyperlinks On Sat, Nov 26, 2011 at 11:03 AM, Jeremy Cowgar jer...@cowgar.com wrote: I wonder if you cannot use an adaptive technique of checking the last If the rapid request count hits a predefined threshold, say 5 or 10, flip the user to a bot status disabling links... Just an idea. Except that by then the robot already has the links, it would then be necessary to ignore further requests from the same IP address for a period of time. ___ 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] Authentication via URL
That is interesting that it works for cloning. I was under the impression that a CGI application could not even retrieve that information. I will look into the clone code and see how it is retrieved. Thanks for reminding me of that. Jeremy From: Stephan Beal Sent: Tuesday, November 22, 2011 2:32 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Authentication via URL On Mon, Nov 21, 2011 at 11:28 PM, Jeremy Cowgar jer...@cowgar.com wrote: http://user:pass/@... does not work. That is just another way of encoding for HTTP Basic Authentication which fossil does not support, and cannot support w/CGI. Aha - i see now that it works for cloning, but apparently not the HTTP interface. i wasn't aware of that. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Authentication via URL
So we are back to square one on accessing an RSS feed that is protected via a normal RSS reader. There may only be two solutions to this problem: 1. Use allow authuser=johndoeauthpass=secret as a URL parameter 2. Forget accessing secured RSS feeds Any other ideas? Jeremy -Original Message- From: Brian Smith Sent: Tuesday, November 22, 2011 3:10 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Authentication via URL It works because it's not sent as HTTP Basic when cloning. Fossil sends it in it's own 'Card' format. The password is sent hashed and nonced (though I forget the exact details of the exchange.) Which means it's actually a bit better than Basic authentication. -B On Tue, Nov 22, 2011 at 11:38 AM, Jeremy Cowgar jer...@cowgar.com wrote: That is interesting that it works for cloning. I was under the impression that a CGI application could not even retrieve that information. I will look into the clone code and see how it is retrieved. Thanks for reminding me of that. Jeremy From: Stephan Beal Sent: Tuesday, November 22, 2011 2:32 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Authentication via URL On Mon, Nov 21, 2011 at 11:28 PM, Jeremy Cowgar jer...@cowgar.com wrote: http://user:pass/@... does not work. That is just another way of encoding for HTTP Basic Authentication which fossil does not support, and cannot support w/CGI. Aha - i see now that it works for cloning, but apparently not the HTTP interface. i wasn't aware of that. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Authentication via URL
-Original Message- From: Remigiusz Modrzejewski Sent: Tuesday, November 22, 2011 3:43 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Authentication via URL On Nov 22, 2011, at 9:32 PM, Jeremy Cowgar wrote: So we are back to square one on accessing an RSS feed that is protected via a normal RSS reader. There may only be two solutions to this problem: 1. Use allow authuser=johndoeauthpass=secret as a URL parameter 2. Forget accessing secured RSS feeds Any other ideas? Try a smarter RSS reader? I remember having Opera read a few protected feeds... It's not that simple. Most RSS readers will authenticate via Basic Authentication, which most feeds are setup as. Fossil, on the other hand, does not directly support Basic Authentication. In order for you to read a protected Fossil RSS feed you have to login via the Fossil login screen. No RSS reader (that I know of) will do this. It would have to be told where the login screen is, what the input names are for the username and password fields, then how to interpret the results. Jeremy ___ 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] Authentication via URL
Stephan,
That does indeed work, however, how long will that cookie be active? It
should have a time encoded in it as to expire after a period of time.
Otherwise, if someone were to get ahold of the cookie they could use it
indefinitely.
Jeremy
From: Stephan Beal
Sent: Tuesday, November 22, 2011 3:58 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Authentication via URL
On Tue, Nov 22, 2011 at 9:44 PM, Stephan Beal sgb...@googlemail.com wrote:
In theory (though i have not tested it), you can pass the login cookie as
a GET parameter, as fossil internally treats GET/POST/COOKIE data
identically for most purposes. The trick, then, is getting the login cookie.
...
Here's something we can try... it won't work out of the box, but if the
concept can be proven then i'll commit to adding the bits which will make it
work out of the box:
http://fossil.wanderinghorse.net/repos/fossil-sgb/index.cgi/json/login?name=json-demopassword=json-demo
that outputs something like:
{
fossil:013e8ee723fe17c61a74ef9aa69a3032e9aa3e55,
timestamp:1321995094,
command:login,
procTimeMs:2,
payload:{
authToken:2D0E39234B4A945C614C844ECCCE71EC4F05B40751E68A4AB8/CE59BB9F186226D8/json-demo,
name:json-demo,
capabilities:hgjorz
}
}
The missing part there is the (repo-specific) cookie name, which we could
_theoretically_ combine with the above authToken (==the cookie's value) to
produce a login string:
http://.../index.cgi/timeline.rss?fossil-XYZ=the_above_authToken
where XYZ==the project-specific code.
If someone can verify that that would work, i will expand the JSON login
input to provide the project-specific cookie name as part of the output.
From there it should be relatively simple (e.g. using JavaScript) to
construct an RSS pull URL (as shown above).
i'm unfortunately all out of energy for the time being (i was recently
contracted out to a new customer in the TV industry, and they keep me busier
than i'd really like to be!), so i can't commit to the experimentation. If
someone else can verify that this approach would/might be useful, though, i
can extend the JSON API to provide the output data needed for this approach.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
___
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] Authentication via URL
I just thought of another potential solution, I think maybe the best option yet? On the logout page (where you can also change your password, etc...) provide display “RSS” key. The “RSS Key” could be a hash based on various elements inside the fossil repo, the repo name, the user, the password and of course a few other items hashed over multiple times for security. The user could then access the RSS feed without authentication but with the “RSS Key.” The “RSS Key”, if anyone greps the log for it, would grant them access (until your password was changed) to view what has changed but not any detail. Thus, it is much less of a security hazard. With the Cookie name and value on the URL, anyone sniffing the network or watching logs could gain full access to your fossil repo. Not so with the RSS key idea. I could implement the RSS Key in a very short time. In regards to your JSON login problem, you may wish to implement something similar. Give a remote api key. Let the user login with that key and their password. This secures things a bit more and would make it easier to deal with the SSO problem you are having. Jeremy From: Stephan Beal Sent: Tuesday, November 22, 2011 4:29 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Authentication via URL On Tue, Nov 22, 2011 at 10:10 PM, Jeremy Cowgar jer...@cowgar.com wrote: That does indeed work PS: on Thursday morning i'll be leaving town for the back woods of northern Germany for 4 days (without a PC), so i'll get the cookie name added to the JSON output tomorrow (Wednesday) evening before i leave. , however, how long will that cookie be active? It should have a time encoded in it as to expire after a period of time. i'll try to answer that for you by tomorrow night as well. It should be simple to add the expiry time to the JSON output as well, so that the client can know how long the login will be valid for. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] Authentication via URL
Maybe it could be called Remote Key or something and used both for JSON and RSS. Jeremy From: Jeremy Cowgar Sent: Tuesday, November 22, 2011 4:42 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Authentication via URL I just thought of another potential solution, I think maybe the best option yet? On the logout page (where you can also change your password, etc...) provide display “RSS” key. The “RSS Key” could be a hash based on various elements inside the fossil repo, the repo name, the user, the password and of course a few other items hashed over multiple times for security. The user could then access the RSS feed without authentication but with the “RSS Key.” The “RSS Key”, if anyone greps the log for it, would grant them access (until your password was changed) to view what has changed but not any detail. Thus, it is much less of a security hazard. With the Cookie name and value on the URL, anyone sniffing the network or watching logs could gain full access to your fossil repo. Not so with the RSS key idea. I could implement the RSS Key in a very short time. In regards to your JSON login problem, you may wish to implement something similar. Give a remote api key. Let the user login with that key and their password. This secures things a bit more and would make it easier to deal with the SSO problem you are having. Jeremy From: Stephan Beal Sent: Tuesday, November 22, 2011 4:29 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Authentication via URL On Tue, Nov 22, 2011 at 10:10 PM, Jeremy Cowgar jer...@cowgar.com wrote: That does indeed work PS: on Thursday morning i'll be leaving town for the back woods of northern Germany for 4 days (without a PC), so i'll get the cookie name added to the JSON output tomorrow (Wednesday) evening before i leave. , however, how long will that cookie be active? It should have a time encoded in it as to expire after a period of time. i'll try to answer that for you by tomorrow night as well. It should be simple to add the expiry time to the JSON output as well, so that the client can know how long the login will be valid for. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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
Re: [fossil-users] Authentication via URL
IE will do the same thing but it simply relies on the cookie already being present. So, unless I login and stay active and read my RSS feeds in IE, that doesn't work. I guess I am just use to a more conventional RSS reader application :-/ Jeremy -Original Message- From: Remigiusz Modrzejewski Sent: Tuesday, November 22, 2011 5:50 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Authentication via URL On Nov 22, 2011, at 9:46 PM, Jeremy Cowgar wrote: Try a smarter RSS reader? I remember having Opera read a few protected feeds... It's not that simple. Most RSS readers will authenticate via Basic Authentication, which most feeds are setup as. Fossil, on the other hand, does not directly support Basic Authentication. In order for you to read a protected Fossil RSS feed you have to login via the Fossil login screen. No RSS reader (that I know of) will do this. Well, I've mentioned one already: Opera. I've never seen a http basic auth protected feed. The ones I've mentioned were forums where you had to login using customizable by templates login pages. I had to log in at that page and set feed syncing to an interval smaller than session expire time. Worked flawlessly. It would have to be told where the login screen is, what the input names are for the username and password fields, then how to interpret the results. I'm pretty sure that should not be a problem. This procedure can be replicated in something like 5 lines of Python. Compared to what I believe is the codebase of a typical rss reader, this does not look too bad... Kind regards, Remigiusz Modrzejewski ___ 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] Authentication via URL
I would like to use my RSS reader to monitor a few timeline RSS feeds of mine from Fossil (tickets mainly). The problem is that on a few of the work projects, all repos are locked down. I cannot access the RSS feed without authenticating. I do not wish to duplicate all the username/passwords into a htpasswd setup and use REMOTE_USER because of the duplicate efforts. Thus I have made a change to fossil’s login_check_credentials method to accept the query parameters authuser and authpass. If found, it attempts to authenticate off this string. Thus, I can do: https://myrepo/index.cgi/timeline.rss?authuser=johndoeauthpass=secret This works great, however, when thinking it through, it is not entirely secure even across https because the query string will be recorded in the access.log file which non-devs could gain access to and retrieve usernames and passwords. One could use a base64 encoding like basic http authentication, but this causes the average joe to not be able to benefit from the change because who knows to take the username and password, concat them with a : and then base64 encode them? Not very user friendly. One could encode the authuser and authpass into a POST query, but then RSS readers would not be able to take advantage of this. How do others deal with this problem? I assume it is a legit problem? I believe that encoding on the URL may be the best solution, but open for suggestions. Jeremy ___ 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] ignore list
On 5/25/2010 8:43 AM, Richard Hipp wrote: On Tue, May 25, 2010 at 8:40 AM, zacht...@cis-partners.com mailto:zacht...@cis-partners.com wrote: I am thinking about taking a stab at implementing an ignore-list feature similar to git's .gitignore to prevent pesky and unwanted files from making it into commits. If this feature already exists in Fossil I have overlooked it. See the ignore-glob setting. I placed this setting in the Web Admin page once it was added. You can find it in Admin Behavior Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] On the wiki
I just want to throw this out there... Since I began using Fossil, I've tried to evangelize it because I know that the more users, the greater tool support, the longer life, the greater the product. Do you know how many people I've got to use Fossil for any length of time? 2 and one of them is my brother! The conversation goes something like this. DSCM? Integrated Wiki? Integrated Ticket System? Wow! Dude, I can replace my trac (others redmine) install with one binary? It works w/o issues on Windows and Unix variants? Wow! That's awesome, I'm going to download it now. A bit later, hey Jeremy, how do I make the wiki work? I can only make list items work but *bold*, //italic// doesn't work and how do I include a block of code as an example? I respond, in Fossil you use, bbold/b, iitalic/i and precode/pre. Um, ok. is there response. Later, how do I do nested lists? My response is, fossil only supports the first depth for lists. If you want to use nested lists, fossil supports HTML in it's wiki. Response = Really? Hm. Then it comes to some other formatting, maybe tables.. as the conversation continues, they say I think I'll stick with Trac/Redmine. This is not an isolated occurrence. I have had at least 10 of these conversations, so, 20% (really 10% because I forced my brother to use it) of the people I've tried to convert have used it for at least one project, the rest say no way, that wiki stinks. One person stated it well, It's not a wiki, it's just editable HTML pages, and that's more true than saying fossil has a wiki system, IMHO. As time goes on and I see such a strong stance against any formal wiki syntax I get less and less excited about using Fossil. For my main project, Josl, I am just about to the point of dropping Fossil and using Git|Darcs and Remine myself. I may be announcing this in this upcoming week, why? 100% because of the wiki. It's funny because people complain that why use Creole? Why use Markdown? Neither are a standard, yet they are happy with the **very** unstandard Fossil wiki markup, because it is a very weird mixture between HTML and Wiki syntax, thus it's yet ANOTHER format that is NOT shared between ANY wiki system. At least Creole and Markdown ARE shared between MANY of wiki systems. So in the name of no standard wiki system, instead of helping to solve the problem, Fossil seeks to further divide. It's very, very, very discouraging to me. The more I think about it, the more I think I'll be using git/darcs with trac/redmine. I'm very sorry to report this, I like Fossil quite a bit but cannot deal with the wiki. I can't deal with telling others about it. Why not just use Fossil as the SCM and include a diff wiki system? How do the two integrate? Now I have to setup themes in both? Now I have to mirror user accounts? How can I reference a ticket number from the wiki? How can I reference a SCM REV # from the wiki? How do I easily reference a ticket number from Fossil? A wiki page? It's a mess. The integration of Redmine/SCM or Trac/SCM is fantastic and it's what Fossil could be but has clearly said it doesn't want to be. Jeremy ___ 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] On the wiki
Oh, one more thing I wanted to say Fossil is awesome with not just it's integrated ticket and wiki system but it's integrated and DISTRIBUTED ticket and wiki system. That's huge. Other SCM's can't touch it even with Redmine/Trac. One suggested just using a distributed ticket system that stores it's tickets in the repo. That works for the developers, but what if some user comes along on the web interface and adds a new ticket? No one has been able to achieve that (yet). But, for all that, the lack of a complete wiki syntax (i.e. wiki = quick quick, not HTML!) still kills it for others and has just about killed it for me. I still have about 2% of my heart in continuing with Fossil, but that's not much. Fossil has the potential to be a fantastic piece of software but is shooting itself in the foot with a huge canon with it's so-called, non-standard wiki syntax. Again, I'm not saying there is ONE wiki syntax that EVERYONE uses, but I am saying there ARE a few STANDARD wiki formats, of which Fossil wants nothing to do with for some reason that's far beyond me. Jeremy ___ 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] On the wiki
On 5/16/2010 12:49 PM, Ron Aaron wrote: On Sunday 16 May 2010 19:23:07 Jeremy Cowgar wrote: Oh, one more thing I wanted to say Fossil is awesome with not just it's integrated ticket and wiki system but it's integrated and DISTRIBUTED ticket and wiki system. That's huge. Yes. But, for all that, the lack of a complete wiki syntax (i.e. wiki = quick quick, not HTML!) still kills it for others and has just about killed it for me. I still have about 2% of my heart in continuing with Fossil, but that's not much. I don't understand this at all. Documentation is one use, but currently for one project I have over 450 pages of documentation, tables, references, footnotes, lists, indents, code formatting, italic, bold, etc... There is no way under the sun I want to format that using HTML! Wow, what a mess. HTML is NOT a human language and it was NEVER intended on being so. It's a markup language. A wiki syntax is so much easier than HTML that I cannot understand how anyone would say they don't understand why you would want to use a wiki syntax. If you want to use the wiki for documentation, you can. HTML gives you all the flexibility you could possibly desire, without requiring one learn Yet Another Markup Language. As an example of what's possible, just take a look at a work-in-progress of mine: http://accord-sys.com/ -- (it's VERY much 'in progress', but you get the idea). Um, HTML can do anything, no one said it's limited. It's verbose, that's the complaint. And no, you cannot do everything with HTML in Fossil. It strips different attributes/style tags/ class tags, etc... Thus, in situations where you want your typewriter to display a menu entry to be different than when you display a key sequence (which is standard in computer documentation), you cannot do it with Fossil's HTML markup. You can with a wiki markup. Thus, in that case, Wiki is more powerful than HTML, but that's not the point. that EVERYONE uses, but I am saying there ARE a few STANDARD wiki formats, of which Fossil wants nothing to do with for some reason that's far beyond me. Exactly for the reason you mention: just what syntax should be used, or what subset of that syntax? MediaWiki? Twiki? Joe's-excellent-wiki? Who cares which one it is? Any is better than Fossil-Wiki (tm). Wiki syntaxes are so simple I can't imagine there is anyone here that can't learn it if they want. Further, if you don't want to use it, don't use it! Right now there is an option that says Use HTML syntax for rendering instead of wiki syntax. It's a checkbox. With the addition of a wiki format, I imagine this would just change to a drop down selection: Wiki Syntax: HTML, FossilWiki, Markdown. Then if you want to stick with the verbose HTML, you can, if you wanted limited support for lists only, then use Fossil Wiki, if you want a full featured format, then use Markdown for your project. I agree there are things in the wiki syntax which are odd or unusual -- but any additional wiki code adds to the complexity and size of Fossil (and makes it more prone to problems). Not really. Once the wiki syntax is created, it should remain pretty stable. Initially there will be some bugs to work through, I'm sure, but once done, it's not as though the wiki syntax changes often. Jeremy ___ 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] On the wiki
On 5/16/2010 1:27 PM, Ramon Ribó wrote: Hello, As I see that the wiki problem is becoming a hot topic, I would also give my opinion. I do not have a strong point here, as we use the wiki pages only for short notes, so it is not very important the wiki language to be used. This is simply your opinion as to what a wiki is used for. Look at the Tcl wiki, the Emacs wiki, Wikipedia, c2.com, clearly none of those are short notes yet they are all valid uses of a wiki. Each project may use the wiki differently. However, I understand that there are other usage patterns that give more importance to it. In my opinion, the solution is very easy: use the creole syntax. It is already inside fossil, in a branch. Make it the default for wiki pages and use some kind of compatibility mode for the old wiki format. Or just let creole also support the old syntax. Are them really incompatible? I'd suggest changing the checkbox option that exists right now Use HTML as the Wiki format to a drop down, HTML or Fossil Wiki or Creole. Jeremy ___ 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] ticket assignment
On 5/9/2010 11:27 AM, zacht...@cis-partners.com wrote: I have continued work on ticket assignment. Tickets can now be assigned by administrators. Users have a My Tickets report, and an Assigned column now exists in the ticket listings. I would like to give users the ability to assign and unassign themselves. What does everybody think? I would make it a simple security attribute that can be controlled per project. i.e. in many projects, I'd allow any developer to assign to any other developer. Maybe John is stuck and wants to give this bug to Jane. I, as the administrator, do not want to have to deal with these changes. Now, on other projects this may not be the case. I may want to handle these type of changes as the admin. Jeremy ___ 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] Deleting a wiki page?
On 5/7/2010 1:11 AM, Gour wrote: On Wed, 17 Mar 2010 20:22:14 -0400 Jeremy == Jeremy Cowgar wrote: Jeremy People are going to be attracted to fossil as an all in one Jeremy package and if it can not provide the functionality needed in Jeremy the wiki, then people will say why use Fossil for SCM and then Jeremy have to interface in with another Wiki system? I now have to Jeremy piece together a system, thus, why not just piece together a Jeremy different SCM as well. The above point nicely expresses why I became interested to have more usable (or Markdown) wiki. Seeing your Josl site, I'm curious if you're using Asciidoc since it's obvious it does not use default wiki? For the manual I am using Docbook. For the wiki, I am using Fossil, but it has HTML enabled and is only editable by me, thus, defunct as a wiki. I'm actually going to be removing it from the tab group and doing without a wiki for a while. I did have the wiki enabled for a while and some contributors just about fell over when they had to type in HTML and they simply didn't, so it is defunct anyway. I'm a strong supporter for any standard wiki format. Sure, not everyone is going to agree on the standard but that's a choice that has to be made. Not everyone agrees with what exists now. The point is, without a more usable wiki, it's not usable as a wiki to me. I gave up. Jeremy ___ 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] ticket assignment
On 5/6/2010 11:30 AM, Erik Lechak wrote: Hello, Thumbs up from me. I would like to see an assigned-to feature added to Fossil. It would be great if it was available right out of the box. Some interesting features might be: * Only admins can assign tasks to others * Non admins can assign tasks to themselves * Non admins can un-assign themselves from a task * For admins the list of people that can be assigned a task comes from the list of users not a separate list that needs to be maintained If something like this were to be created, I think a new security attribute should be created, can assign or something. Therefore, you could give the can-assign attribute to an admin or to anonymous if you wish. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Why not fossil?
http://www.reddit.com/r/programming/comments/bxcto/why_not_fossil_scm/ Jeremy ___ 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] Compiling fossil under windows
On 4/11/2010 6:46 AM, Rene de Zwart wrote: Having had my way with fossil compiling under windows. I was looking for new challenges by compiling with other free compilers. I tried digital mars c compiler. Which promptly said unistd.h is for unix systems (The smart little bugger :-) Do I correctly infer from this that native windows compilers are not tested/used/supported? I compile Fossil with MinGW all the time. I have not tried any other Windows compiler. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Editing a tag causes confusion on branches?
I created a new branch on as 0.2.0. I then however, realized I goofed. I wanted the branch to be 0.2. I would later create a tag for the 0.2.0 release of the 0.2 branch (expecting 0.2.1, 0.2.3, etc... which would all be tags in the 0.2 branch). So I edited it via the web UI. This, however, changed the properties but did not change the branch display: http://fossil.josl.org/brlist You can see 0.2.0 listed (which I just closed this evening). Now, clicking on it, you do not see any checkins tagged with 0.2.0. http://fossil.josl.org/timeline?t=0.2.0 (which you could get to also by clicking on the 0.2.0 branch link). I assume this is because I change 0.2.0 to be 0.2. So, if you manually change the URL to read: http://fossil.josl.org/timeline?t=0.2 Then you will see 0.2 checkins (well, checkin). Or, you can browse the timeline and find the checkin as well: http://fossil.josl.org/info/0bc11bf7ae I looked in source code and was unable to solve this problem. Any thoughts? Jeremy ___ 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] Hyperlinks Disabled
On 3/29/2010 2:45 PM, Daniel Clark wrote: Or IMHO even better, change what is and isn't linked as nobody to be a admin setting. (In my case, specifically with tickets I'd actually like search engines to index them). I have not spent much time in the security sections of Fossil, obviously. You simply enable history for nobody. Zip download is a different security permission. Thus, indexing bots can index tickets, commits, etc.. nobody users can click on history links, browse files, etc... but they will still have to auth for the zip download. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Hyperlinks Disabled
When you are not logged in to Fossil, you get the message in many areas: Many hyperlinks are disabled. Use anonymous login /login?anon=1g=/timeline to enable hyperlinks. Is it really a problem? I just have assumed so since the message was there, but it's a bit of a roadblock for new users to fossil when they see this message and try to navigate around. I understand the intent is to cause bots not to index your repo, but is that a problem? Can a robots.txt not just be used instead of disabling hyperlinks? Jeremy ___ 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] Hyperlinks Disabled
On 3/29/2010 8:43 AM, D. Richard Hipp wrote: The problem robots all ignore robots.txt. For example, some users think it is a good idea to run wget -r on http://www.sqlite.org/ in order to download the entire site, and were it not for the disabled hyperlinks in Fossil, that would result in pulling down a ZIP archive for all 7424 historical check-ins of SQLite as well has every historical version of every file in the source tree, in both binary and hex, with its diff, and its annotation. Didn't think of that. I wonder about enabling everything but the zip download, require at least an anonymous user to download the .zip archive? Jeremy ___ 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] Hyperlinks Disabled
On 3/29/2010 11:28 AM, Stephan Beal wrote: On Mon, Mar 29, 2010 at 2:49 PM, Jeremy Cowgar jer...@cowgar.com mailto:jer...@cowgar.com wrote: Didn't think of that. I wonder about enabling everything but the zip download, require at least an anonymous user to download the .zip archive? Then you've still got the problems that: a) the anonymous user can't reach the ZIP link if the hyperlinks are disabled. ZIP links are hidden down in the timeline info. (Of course, you could link to the trunk in your main menu, or wherever.) b) a bot (if it can get to the ZIP link at all) will proceed to download every zipped version of your repo. Every commit generates, in effect, a new ZIP, so the amount of bandwidth wastage due to robots goes with each commit. I don't understand or I didn't explain myself well enough. Currently, *all* links are disabled for visitors that did not at least authenticate themselves via the anonymous login. So, they cannot get to the zip links, timeline links or anything (except wiki) without first authenticating themselves to at least the anonymous level. What I am suggesting is that all links become enabled to everyone (nobody role included) except the zip links. If the user wants to access the zip links, then they will have to authenticate to at least the anonymous level just as it currently is. So, a human can still get to everything except that 99% of the items they can get to without having to authenticate. Only the zip download will they have to authenticate on. Jeremy ___ 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] Deleting a wiki page?
On 3/18/2010 6:42 AM, D. Richard Hipp wrote: If you update to the latest experimental Fossil (specifically version http://www.fossil-scm.org/fossil/info/012d5e4f23 or later) and do fossil all rebuild then if you change the content of a wiki page to be empty, that wiki page will not show up on the list of wiki pages (unless you select the All option, in which case the wiki page name will be withins../s). Is that sufficient for deleting a wiki page? I believe that will work just fine. Thank you! I didn't mean it had to be an urgent task, just wanted to put it on the table as something needed, but thank you for making it! Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Deleting a wiki page?
Is there a way to delete a wiki page? Maybe by issuing SQL? Jeremy ___ 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] Deleting a wiki page?
On 3/17/2010 5:09 PM, D. Richard Hipp wrote: You could shun all the wiki artifacts associated with that page. There is no other way at present. Because the design of Fossil is to save everything forever, it is not clear would could be down to delete a wiki page. There has to be a way as we can delete a file from the SCM. We can also rename a file. I guess I am not talking about removing it entirly as if it had never existed. I am simply talking about removing it so it's no longer active and no longer appears in the /wcontent list. Jeremy ___ 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] Deleting a wiki page?
On 3/17/2010 6:44 PM, Michael Barrow wrote: There is no such thing as a non-active Wiki page per se. You could remove links to said page if you want to keep it around and then edit the page to say Hey -- we're just keeping this for archival purposes. Otherwise, 'shun' is the tool to use. I've done in on some of my installations for pages that I really wanted to go away. If this is the case then I would say the Fossil wiki has to be changed to be a usable wiki. No one is going to create a perfect wiki structure the first time around and no one wants old pages listed in their Index page. All wiki's have a delete function and if Fossil wants to be considered seriously as a replacement for other project wiki's, it has to support delete and rename. People are going to be attracted to fossil as an all in one package and if it can not provide the functionality needed in the wiki, then people will say why use Fossil for SCM and then have to interface in with another Wiki system? I now have to piece together a system, thus, why not just piece together a different SCM as well. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New --ignore option
For my fossil checkout, I do: mkdir build cd build make -f ../Makefile So, from my root fossil directory, I do fossil extras --ignore build but still wind up with everything under the build directory. I can do --ignore *.o and get rid of the .o files in the build directory but it still shows up with all the .c and .h files, which of course I cannot ignore. Also, once this problem is fixed, does it make sense to store this option in the database? Maybe in the Behavior section of the setup web page? Jeremy ___ 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] New --ignore option
Hm, weird. It works under cmd.exe, but not the MinGW bash shell. $ fossil extras --ignore 'build/*' CHANGES.txt build/VERSION.h build/add.o build/add_.c build/allrepo.h build/allrepo.o build/allrepo_.c I couldn't come up with any combination to make that work. The shell is bash, I am assuming this works on other bash shells in Linux? Jeremy On 3/16/2010 8:30 AM, D. Richard Hipp wrote: On Mar 16, 2010, at 8:22 AM, Jeremy Cowgar wrote: For my fossil checkout, I do: mkdir build cd build make -f ../ Makefile So, from my root fossil directory, I do fossil extras --ignore build but still wind up with everything under the build directory. fossil extra --ignore 'build/*' I can do --ignore *.o and get rid of the .o files in the build directory but it still shows up with all the .c and .h files, which of course I cannot ignore. Also, once this problem is fixed, does it make sense to store this option in the database? Maybe in the Behavior section of the setup web page? Jeremy ___ 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...@hwaci.com ___ 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] New --ignore option
On 3/16/2010 8:39 AM, D. Richard Hipp wrote: fossil setting ignore-glob MinGW's bash must be expanding the asterisk for some reason: $ fossil setting ignore-glob 'build/*' Usage: c:\Development\Tools\Fossil\fossil.exe setting ?PROPERTY? ?VALUE? However: $ fossil setting ignore-glob 'build/*,*.o' $ fossil setting ignore-glob ignore-glob (local) build/*,*.o So... at least there is a work around for MinGW's bash. Jeremy ___ 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] New --ignore option
On 3/16/2010 8:39 AM, D. Richard Hipp wrote: fossil setting ignore-glob BTW... Thank you for this change! This has always been the most annoying thing for me when using fossil. It's a great addition. Thanks again! Jeremy ___ 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: commit a ticket
On 3/13/2010 7:32 PM, Jacek Cała wrote: fossil commit -t ticket_id -m comment [-r resolution_type] I like the idea. Only one problem, as I see it though. Maybe discussion can bring about it's resolution. Maybe it's just a change of my workflow, don't know. I'll get a few minor bug's submitted then sit down to a coding session. Often times a bug is just a one word/line change. I'll fix the minor bugs and commit a message such as: * Fixed [384938]. Blah Blah Blah * Fixed [2939283]. Blah Blah Blah. Does everyone do the same or does everyone fix one bug per commit? Jeremy ___ 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] What is the process for getting changes applied
I recently found fossil and have made a few changes to the source that ... - remove hardcoded styling from some html tags - add class=... to the html tags This allows greater flexibility for skins. The plan is to make as much as possible skinable. This sounds like a valuable patch, thanks! What is the best approach for getting code changes applied? Sending a patch file to the list? Right now, the best method is to create a ticket and include the diff in the comments. That way it can be tracked from start to finish. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Linking directly to a file on tip?
I have a source file, docextract.tcl, in my repo, http://jeremy.cowgar.com/misctcl/ and I would like to be able to let people easily download just that one file. How can I make a link in the wiki (or externally, i.e. send an email with the link) to docextract.tcl as found in the latest revision? The problem is they are anonymous and when I direct them to the file browser or something, links are disabled by default (and for a good reason). So, I need the ability to send them to the direct file content. Any thoughts? Jeremy ___ 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] Linking directly to a file on tip?
http://jeremy.cowgar.com/misctcl/index.cgi/doc/tip/docextract.tcl does work. Yes, it does... I just didn't know what URL. Jeremy ___ 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] Extra files and new files
Hello, What about? fossil ignore file1 file2 ... In this case, fossil would store the names of the files in the repository. These files would not appear in fossil extras and would give an error if fossil add fossil ignore directory1 ... directory2 ... the same, but would apply to all files inside that directories (fossil would only store the directory name) ignored files could be considered again by using fossil rm file1 or fossil unignore file1 Another interesting addition to fossil would be a fossil extras that only gave the extra files inside current directory I wrote this already but ran into a few problems, i.e. fossil ignore *.bck I want it to ignore just that, all .bck files but the shell was always expanding it. I tried quotes and ^ w/o luck. On windows here. My interface was something along the lines of: fossil ignore add filea fileb ... fossil ignore remove filea fileb ... fossil ignore list Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Escaping HTML on artifact viewing?
Should HTML be escaped? http://jeremy.cowgar.com/misctcl/index.cgi/artifact/192df1e147 Jeremy ___ 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] Escaping HTML on artifact viewing?
I guess to me, the default should be As Text. I'd venture to say most of the HTML included in peoples repos will not render correctly anyway embedded inside of a fossil web page. Thus, you would still have an HTML link at the top, but by default it would show the text. HTML in today's day in age almost always relies on style sheets. Put in a code repo, they probably depend on dynamic code expansion of templates/variables as well. Further, images linking in, etc... I'd guess that showing rendered HTML by default, a lot of people are going to have some really messed up HTML displays when just trying to browse the repo. To me, the SCM tool should be managing the source, not really trying to interpret what the source means and in a way, that's what is happening by allowing the HTML code to display as it is. Jeremy On Feb 8, 2010, at 8:57 AM, Jeremy Cowgar wrote: What would be the purpose of displaying the HTML there? I guess I always thought of the repo browser to be browsing source code, not for creating links to rendered HTML pages for people to read? If you want to see an artifact rendered as HTML, how else would you see it? I, for one, sometimes like to see specific artifacts rendered as HTML. Jeremy On Feb 8, 2010, at 8:47 AM, Jeremy Cowgar wrote: Should HTML be escaped? http://jeremy.cowgar.com/misctcl/index.cgi/artifact/192df1e147 I don't think so. http://www.fossil- scm.org/fossil/artifact/d4951ef603 There is a Text link in the sub-menu if you want to see the raw text. D. Richard Hipp d...@hwaci.com ___ 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 D. Richard Hipp d...@hwaci.com ___ 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] New Timeline... Internal Server Error.
I gave it a try, however, when view the Timeline link, I get an Internal Server Error. This is on my misctcl repo, http://jeremy.cowgar.com/misctcl/ Everything else seems to work just fine. Jeremy ___ 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] Removing the directory named javascript from the repo
Wilson, Ronald rwils...@harris.com wrote: I don't think fossil versions directories. You have to fossil rm each file in the directory individually. That may be true, but ou can do fossil add javascript and it will add everything under it. dir /s reports 242 files in 311 directories. It's basically tiny mce. I'm sure I could whip up some shell script to do the dirty work, but fossil rm javascript should just work? I didn't spelunk the code, but I don't think that is implemented. Sounds like a feature request to me. Or you could volunteer to implement it. This is done and in the repo. Jeremy ___ 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] Graphical display of fork/merge actions in timeline
Hm, in what way is IE giving you fits? It's *almost* working for me. If you resize the window, the graph does not resize, but at least it's displaying now :-) Jeremy On Feb 8, 2010, at 1:41 PM, verizon wrote: Looking at it with Firefox 3.6 and Safari 4.0.4 (on OS X 10.6.2) I don't see any difference in the presentation. vertical and horizontal alignment appear identical on both browsers. --jim Tnx, Jim; I fixed the Safari thing. And I fixed it so that the graph regenerates when you resize the browser. (Same fix, really.) IE is still given trouble, of course... On 8 Feb, 2010, at 13:23, Brett Schwarz wrote: On Mon, Feb 8, 2010 at 9:28 AM, Jeremy Cowgar jer...@cowgar.com wrote: So the updated score is: * Firefox, Opera, Chrome and Konqueror all work * IE does not work at all (at least versions 6 and 8, so we can *assume* 7 as well) * Safari has some issues I have IE 8. I got it to work by changing the Document Mode to IE8 Standards. There's probably someway around this programmable...I just haven't looked yet... ___ 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 D. Richard Hipp d...@hwaci.com ___ 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] Removing the directory named javascript from therepo.
Clark Christensen cdcmi...@yahoo.com wrote: I don't think fossil versions directories. You have to fossil rm each file in the directory individually. Or simply fossil rm javascript/* javascript contains another directory (tiny_mce) which contains 242 files in 311 directories. Jeremy ___ 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] Removing the directory named javascript from therepo.
javascript contains another directory (tiny_mce) which contains
242
files in 311 directories.
Sorry, I read where you said that, and didn't quite get it
(obviously).
I misread things all the time, over and over again, NP :-)
For this time around, I used MSYS and just used find javascript -type f -exec
fossil rm {} \; then just rm -r javascript but that shouldn't be required. I'll
see what I can do about recursive removes in the code.
Jeremy
___
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] Removing the directory named javascript from therepo.
Wilson, Ronald rwils...@harris.com wrote: I don't think fossil versions directories. You have to fossil rm each file in the directory individually. That may be true, but ou can do fossil add javascript and it will add everything under it. dir /s reports 242 files in 311 directories. It's basically tiny mce. I'm sure I could whip up some shell script to do the dirty work, but fossil rm javascript should just work? Jeremy ___ 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] Repository-dependant cookies
D. Richard Hipp d...@hwaci.com wrote: On Feb 1, 2010, at 7:24 AM, Wilson, Ronald wrote: I wish it served a page at the root that listed all hosted repositories. Would it be a security problem to do that? I thought it would be. Perhaps not in every instance, but I can envisions scenarios where a user would not want that listing to appear. Maybe that could be a command line option, so if they want it, they can give -list or something. You could even make it fancy, -list abc,def,xyz which will leave out 123 and 456. Just thinking out loud. Jeremy ___ 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] Repository-dependant cookies
wrote: I wish it served a page at the root that listed all hosted repositories. Would it be a security problem to do that? I thought it would be. Perhaps not in every instance, but I can envisions scenarios where a user would not want that listing to appear. The standard solution of web servers is to see if index.html exists in the directory and if so, serve that page; if not a 404 results. Many servers have the option to do a listing, but that is just that: an option. Hm, an index.html is a great suggestion! (sent mine before reading this one). Jeremy ___ 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] Interesting use for Fossil: notes
Quoting Stephen De Gabrielle stephen.degabrie...@acm.org: Agreed, it probably counts as the easiest issue/bug tracker to setup in the universe, despite the TCL-like embedded language. I was thinking that it's TCL-like embedded language was what made it usable and so configurable. It's simplicity is a plus, but it's configurability is the real benefit :-) Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Cross-site request forgery attempt?
I put into my application the ability to automatically post errors from the application. i.e. the app is a TclTk app and if something goes wrong, I have overridden bgerror. My bgerror presents the information in a nice format and has a button named Report. When the user presses that button, a http request is fired with a properly formatted POST request. However, the data is never added. Looking at the content of the result from the post, I see: pfont color=redCross-site request forgery attempt/font/p How can I get around this? I really want my application to be able to submit bug tickets. As it exists now, it is able to search the existing ticket database to see if there is a ticket already submitted for the problem. If so, it tells the user about it and allows them to view the ticket. If not, it submits the bug (except for this minor problem). Any thoughts? Jeremy ___ 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] Cross-site request forgery attempt?
Never mind, I figured out how to do it w/o issue. Thanks. Jeremy Jeremy Cowgar jer...@cowgar.com wrote: I put into my application the ability to automatically post errors from the application. i.e. the app is a TclTk app and if something goes wrong, I have overridden bgerror. My bgerror presents the information in a nice format and has a button named Report. When the user presses that button, a http request is fired with a properly formatted POST request. However, the data is never added. Looking at the content of the result from the post, I see: pfont color=redCross-site request forgery attempt/font/p How can I get around this? I really want my application to be able to submit bug tickets. As it exists now, it is able to search the existing ticket database to see if there is a ticket already submitted for the problem. If so, it tells the user about it and allows them to view the ticket. If not, it submits the bug (except for this minor problem). Any thoughts? Jeremy ___ 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] patch to give pull and sync an --update option
On Tuesday 19 January 2010 19:33:54 D. Richard Hipp wrote: What if we changed autosync such that instead of being just on or off there was an addiitonal state, pull-only? Would that solve the problem? Yes, I think that would work What about when you change to different branches? i.e. fossil update branch-abc fossil update branch-def Will that not cause a pull even when disconnected? Or maybe I am misunderstanding the original problem. Jeremy ___ 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] Please contribute Fossil skins or themes
Altu, That's a nice skin! Jeremy altufa...@mail.com wrote: Request to add Shiny Fossil theme (http://dev.codingrobots.org/p/shiny-theme) to default set of themes. Attached is a derived version with some recent changes for menu order / permission. ___ 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] My Tickets type ticket report?
Brian Theado brian.the...@gmail.com wrote: I little while back, I ported over some of the sql functions from cvstrac, including the 'user()' function. I think that will do what you want. The code change can be seen at: http://tkoutline.sourceforge.net/cgi-bin/fossil/ci/f41358e7ca Or the whole branch: http://tkoutline.sourceforge.net/cgi-bin/fossil/timeline?t=sql-func Brian, I have committed your cgi() function. Thank you. Jeremy Cowgar ___ 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] Passwords stored in cleartext in 'user' table
I noticed this the other day. I am not on a shared server and it makes me a bit nervous. Also, it's not really fair to people working on your project as many people have a common password (good or bad). Jeremy Ron Aaron r...@ronware.org wrote: I didn't see an option, perhaps it's not even on the list of requests... but when I look at the 'user' table, the user's password is stored in cleartext. Having my fossil file on a shared server, this makes me a bit nervous. Anyone who has access to that file can read all the user passwords. It would be trivial to change the password stored to sha1(login+pw). In that case it would also be difficult to hack, since different users with the same password would have wildly different values saved in the user table. -- Sending me something private? Use my GPG public key: AD29415D ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New changes allowing ticket search screen (round 2)
Ok,
It's now easier than ever to create your own search screen. I just committed
code that allows for a user defined TH1 report list view page. You know, the
view that looks like:
Enter a new ticket:
1. New Ticket
Choose a report format from the following list:
2. All Tickets[copy] [edit] [sql]
3.
That is now a template that you can edit for yourself via Admin Tickets
Report List Page. This means you can do about anything. It initializes your
common code as well. So, to create a search screen, simply create a ticket
report as described before. A simple example may be:
SELECT title, severity FROM ticket
WHERE
title LIKE '%'||cgi('title')||'%'
AND severity LIKE cgi('severity')
Get the report number from the URL (something like rptedit?rn=20). Then edit
your report list page and do something like:
form method=GET action=$baseurl/rptview
input type=hidden name=rn value=20/
Title: input type=text name=title /br /
Severity: th1combobox resolution $resolution_choices 1/th1br /
input type=submit /
/form
That's it!
Now, if your are CSS savy, the new template also opens up the possibility of
better themeing of the report list. The report list is still built in fossil
but it is placed into a variable and it uses only li.../li tags. This means
you can use ol or ul surrounding tags, you can turn them into menu entries,
horizontal lists, etc...
Jeremy
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] tbody, thead, tfoot in wiki
I attempted to allow tbody, thead and tfoot in wikiformat.c but failed. I am not understanding something. These elements are not really important to me but using the cookbook setup for TinyMCE, it insists on inserting tbody tags which are denied by the wiki format, thus, the TinyMCE integration with fossil is impossible if you have any tables in your wiki. Richard, could you give me a pointer on what I may be doing wrong? I added MARKUP_THEAD,TBODY,TFOOT tags, I added it to the AllowedMarkup structure (in order) but the MUTYPE_ stuff I was a bit confused about. As for the allowed attributes I just used 0 (none). What happened when I compiled things was that tbody was accepted but the tr's and td's in the tbody were not. They were escaped. If it's something I'm totally missing and just a 5 second job, a commit would be nice also, but don't want to make any demands :-) Thanks for any input. Jeremy ___ 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] My Tickets type ticket report?
Brian Theado brian.the...@gmail.com wrote: On Thu, Dec 31, 2009 at 5:34 PM, Jeremy Cowgar jer...@cowgar.com wrote: The cgi function can only be used by someone with report edit permissions. So if no calls to the cgi function are added to any reports, fossil is just as secure as without the cgi function implementation. I was thinking about this. Two things, it can only be inserted by someone with report edit permissions but it can be used by anyone executing that report. Thus, everything would have to be escaped properly otherwise you just opened all your internals to the world via SQL injection: http://repo?rptview?m=5cgi_param=';DELETE FROM users; Or, they could change the password of an existing user (admin user even). But... if these security precautions are handled properly, then it could be pretty powerful. I don't care for the typical Tickets page that lists reports in alphabetical order, so I changed my main theme to point Tickets to a specially crafted Wiki page that gives users instructions on finding existing bugs and also notes on how to write a good bug report, etc... If we had the ability to accept CGI parameters into the SQL, then I could also create a user driven search page. That's pushing the limits of what can be done (actually, I'm not sure form elements are valid HTML in the wiki, so it may not be able to be done) but, it begins to make a much more user friendly system. It would be nice to have permissioned wiki pages, i.e. admin. Then when an admin permission, fore go the security checks on HTML elements, also include the ability to use TH1 scripting. That would open the world. Jeremy ___ 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 case for Markdown (yes, I rtfm)
This is kind of funny. We have been debating this and the end result was something to the effect of: Yeah, it may be good, but who will program it? It's already done and has been by Robert... http://fossil-scm.org/index.html/timeline?t=creole So, no dependencies, the code is written and Creole is a format that many wiki systems are now supporting. Jeremy ___ 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] Security Changes to Timeline
D. Richard Hipp d...@hwaci.com wrote: On Dec 31, 2009, at 10:28 AM, Jeremy Cowgar wrote: This change makes it so that it is impossible to see the timeline without first logging in as anonymous. I consider that unacceptable. The purpose of the history capability is to turn off hyperlinks - nothing more. The idea is that for user nobody (which is the user that all spiders will have) none of the hyperlinks will be visible and so msnbot and Googlebot won't burn through gigabytes of bandwidth downloading diffs of every historical version of a project. User nobody should be able to see the timeline. They just shouldn't have any hyperlinks on the timeline page. Ok, I see what you are saying. I wonder if the history capability would be better named as show links or something along those lines? To me the timeline shows history. The current use of history doesn't seem to be intuitive. I see you made some changes in a more recent commit, what does your method do? Alternative implementation of timeline security changes - this implementation always shows the timeline link if it is applicable, even if the history capability is disabled. Specifically, what do you mean always show the timeline link if it is applicable? The final result I was after was to allow someone to view the timeline but not a certain part of it, mainly source code. In my particular situation I use fossil with some open source projects and also at work. I've not used the ticket system built into fossil with my work because I did not want other employees/co-workers to have access to the source code. So, with my change (and probably yours also) you have enough security control to show the timeline but depending on your security you may not see checkin history, wiki history or ticket history. From reading your diff it seems that yours does the same (and more eloquently) but I don't understand what you mean always show the timeline. Jeremy ___ 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] Security Changes to Timeline
D. Richard Hipp d...@hwaci.com wrote: On Dec 31, 2009, at 3:46 PM, Jeremy Cowgar wrote: The Timeline link on the menubar is moved to the left so that it is now the second from the left. This seems a better place, to me. I also arranged for the File menubar option to only appear if the user has both history and check-out privileges. The Timeline menubar link appears if the user has any of check-out, read-wiki, or read-ticket. Only those lines of the timeline that are appropriate for the user's capabilities are shown. So if you set up a user to have read-ticket capability, but not check-out, they will only see tickets in the timeline, and not check-ins. That's what you wanted, right? Yes. The thinking is that if they do not have access to the source they probably shouldn't be able to view it in the fossil ui either. I updated my local tree and your updates are working great. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Searchable Timeline
I just committed code that allows one to search for text in the comment and brief fields of the web timeline. The parameter is s, for string search. For instance: http://repo/timeline?s=search%20string This can be handy for fixed things as well. For instance, on the ticket view, I show a link now to associated checkins: th1 set shortUuid [string range $tkt_uuid 0 9] /th1 a href=/timeline?s=$shortUuidy=ciassociated checkins/a Now, when I commit, I always include [shortUuid] in my commit comments of any ticket that I am working on or have fixed. Thus, I can easily link my commit to a ticket and now my ticket to a commit. Just to let others know of the new feature. I am sure you'll find uses for it as well. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] My Tickets type ticket report?
Is it possible to use $login inside the SQL of the ticket reports? I tried a few things but it doesn't look so. It would be pretty handy :-) Jeremy ___ 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] wiki link to tip zip archive
D. Richard Hipp d...@hwaci.com wrote: http://www.projectname.org/fossil/zip/name-of-download.zip?uuid=trunk The trick is that the uuid= query parameter can specify a branch or a tag in addition to a specific check-in. Is there a way to make the name-of-download.zip dynamic? For instance, I can make it mailroom-trunk.zip, but which trunk? It would be nice to have a link such as /fossil/zip?uuid=trunk that would download and give the client the name such as mailroom-0bca30de.zip by itself so that the user would be able to identify the .zip file. Possibly something like /fossil/zip?uuid=trunkbasename=mailroom-snapshot- even would be nice. Jeremy ___ 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] tree checksum does not match
Eric e...@deptj.eu wrote: What I'd expect if I had deleted a file from the file system without doing a fossil rm is that a fossil update would simply assuming that it was missing and restore it. This is what CVS and SVN do, and I can't see any reason why a DVCS should be different in this regard. (I'm quite willing to be enlightened if anyone can provide with one. :-) Will What should happen if you had removed the file on purpose? In any case, it is a merge of the file from the repository with the no-file in the checkout, so if it is restored fossil should report it as it does for a conventional merge. Then you should see that fossil thinks it's missing and do a fossil rm file.txt, to let fossil know you meant for it to be removed. Idealy, fossil rm file.txt should remove it from the repo and disk as discussed in another thread. Same for fossil mv file.abc file.def Jeremy ___ 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] tree checksum does not match
Will Duquette w...@wjduquette.com wrote: On Dec 15, 2009, at 5:58 PM, D. Richard Hipp wrote: (Third thing that needs to be fixed - there ought to be an easier way to revert many files. Or, maybe if files are missing they out to be automatically rm-ed. Or maybe that there is an option to automatically rm missing files. Thoughts? What do other DVCSes do?) Richard, What I'd expect if I had deleted a file from the file system without doing a fossil rm is that a fossil update would simply assuming that it was missing and restore it. This is what CVS and SVN do, and I can't see any reason why a DVCS should be different in this regard. (I'm quite willing to be enlightened if anyone can provide with one. :-) I wonder if revert wouldn't be better. What I am thinking is that I may not want to update my source tree right now. Maybe I am in the middle of some big changes, autosync is on, etc... Just as if I were to edit abc.txt and blank the content, I could do a fossil revert to get the content back. If I accidentally removed a file, revert it. That will allow me to get it back without fancy trickery (autosync off, or update to my given version). Jeremy ___ 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 mv bug. Reproduction script provided.
Benjohn Barnes benj...@fysh.org wrote: I described this a few days ago, but not very coherently. Here's another try. I'm happy to bung this in a tracker somewhere if someone hands me a url. Benjohn, Maybe file a ticket at: http://www.fossil-scm.org/index.html/tktnew Jeremy ___ 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] Commit failing... retyping commit message
Stephan Beal sgb...@googlemail.com wrote: On Fri, Dec 11, 2009 at 2:11 PM, Jeremy Cowgar jer...@cowgar.com wrote: I thought he was working on a method of my #1 item, i.e. saving the commit message when a commit had failed. I didn't think he was working on anything in regards to #2... loading the commit message from a file. (I'm also waiting :-D) Here it is: http://www.fossil-scm.org/index.html/vinfo/9517cc7486cb68df5de66ae7000337ea2d718574 Yeah! Thanks for that change Stephan. Jeremy ___ 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] Commit failing... retyping commit message
Stephan Beal sgb...@googlemail.com wrote: i'm with Jeremy on this one: -M/--message-file. That said, Richard's been interestingly quiet throughout this conversation, which leads me to suspect that he's hacking away at some clever alternative which will make all this moot :). SVN uses -F and --file BZR uses -F and --file HG uses -l and --logfile CVS uses -F Git uses -F Monotone uses --message-file Darcs uses --logfile ... now, one side note... all these tools support the loading of a commit log message via a file. I did not look at the other 100 tools, only the ones that I have used in the past for any length of time. We already have on the commit command: --comment|-m COMMENT-TEXT --branch NEW-BRANCH-NAME --bgcolor COLOR --nosign --force|-f --private So, if we were to use -F, we'd be overloading --force. That's probably not a good idea as it will not err out, I wouldn't think, on a CAPS lock error (has anyone ever done that or are we programming around a 1 in a million case? i.e. -m vs. -M. HG using --logfile|-l seems OK, but I think I like --message-file|-M better still. One thing to think about is we don't *have* to have a short option. My guess is that we will not be using --message-file from the command line that often. It's probably going to be used mainly from other tools, but that's just a guess, no real data backing that thought other than my own usage. Jeremy ___ 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] 3 Feature requests - globbing using the repository.
Will Duquette w...@wjduquette.com wrote: I was unclear, apparently. Suppose fossil rm *.foo deletes the files from the file system and from Fossil. If I then do rm *.foo when I meant to do fossil rm *.foo I can then do fossil update which will give me my *.foo files back. Then, I can do fossil rm *.foo Note that I'd expect fossil rm *.foo only to remove files from the file system that it can remove from the repository, i.e., if I had an extra file, not_added.foo, I'd expect fossil rm *.foo to live it alone. What's wrong with that? I would expect that to be good behavior? Jeremy ___ 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] Commit failing... retyping commit message
=?ISO-8859-1?Q?Ramon_Rib=F3?= ram...@compassis.com wrote: If there is an option that a user has no interest in using, why would the user attempt to remember what it was? I recently had to read the cvs manual to find an option of one subcommand. I assure you that it was not a pleasant task to surf between the thousands of stupid options that cvs has gained with the years. Hm, I just browsed the man pages of many VCS systems (CVS included) to find examples of parameters for the message file. I had no problem locating their pages, browsing the manual and finding them for 6 VCS systems in about 3 minutes. I personally like -M / --message-file and would value any features that make fossil easier to integrate I have recently integrated fossil inside a GUI tool in RamDebugger (is it the first integration?), and have not missed at all the -message-file option. Why? It is fairly easy from an external tool to massage the log message to fit in the -m option. Some tools it would not be a problem, you are right. Currently I am trying to integrate with one tool and it provides a simple macro recorder, nothing really more. So, what you can type with your keyboard, it will record. I suppose I could figure out some crazy regexp to do what I want, or we could do like every other VCS under the sun and provide a -M/--message-file option. I *really* fail to see why an option like this should even be debated or why one would deny a helpful feature to make our job easier just because there are already 6 options, that as said, are very easy to get help on. Jeremy ___ 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] Commit failing... retyping commit message
Stephan Beal sgb...@googlemail.com wrote: i've just added -M/--comment-file which does #2. If there are no objections to using -M/--comment-file for this, i will commit it. Where are we at with this? I've been looking forward to seeing a commit message :-D Jeremy ___ 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] Numbered list syntax?
Kees Nuyt k.n...@zonnet.nl wrote: I don't get it. We never had to number the list ourselves. What was wrong with : Numbered list 0 Number one 0 Number two 0 Number three Nothing, except it's not documented anywhere or readily noticable in the code. I must have skipped right over it! In the wiki_rules, I see: Enumeration Lists. An enumeration list item is a line that begins with one or more digits optionally followed by a . and is surrounded on both sides by two or more spaces or by a tab. The number is significant and becomes the number shown in the rendered enumeration item. Only a single level of enumeration list is supported by wiki. For nested enumerations or for enumerations that count using letters or roman numerials, use HTML. I do, however, by far prefer # over 0 as in many web browsers the default font of 0 looks like an O. Also, in keeping with the idea that The wiki markup used by fossil, though limited, is common to most other wiki engines, # is much more common, I've never run into using 0 before in a wiki system. People will intuitively use * and #. As proof, look at how many people never knew Fossil did numeric lists! Also, the purpose of a wiki is to make the text both human readable and able to be formatted by a computer at the same time. So, when reading a numbered list, compare these two items: John Doe had many pets as a child: 0 Dog 0 Cat 0 Fish 0 Rabbit 0 Horse or. John Doe had many pets as a child: # Dog # Cat # Fish # Rabbit # Horse Also, I wanted to make note that even in the fossil wiki where numeric lists are used, I see the syntax of: 1. Dog 2. Cat 3. Fish 4. which is the defined syntax. Jeremy ___ 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] Numbered list syntax?
Kees Nuyt k.n...@zonnet.nl wrote: I don't get it. We never had to number the list ourselves. What was wrong with : Numbered list 0 Number one 0 Number two 0 Number three With this new information, value=0 only working on IE and the value= attribute being depreciated, I have committed the # list change to fossil. The old syntax is still intact and can be used if you like to order your own lists, however, I would highly suggest converting over to the new syntax of using # for your ordered lists. Jeremy ___ 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] Numbered list syntax?
Michael Richter ttmrich...@gmail.com wrote: Ahhh ... in my Fossil wiki it gives me: 1. Number one 2. Number two 3. Number three Try for yourself in the Fossil wiki's sandbox ... I did before I posted. But pay attention: Every number enclosed in *two* Blanks! Yes, I know this. I got a list of 0. (Note the period in my list there?) It's not your syntax or fossil, it's the web browser. So far, it looks like only IE will turn value=0 into a numbered list. The rest give 0... but do not fear, I just committed the # list change. Jeremy ___ 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] Numbered list syntax?
Kees Nuyt k.n...@zonnet.nl wrote: Using Google Chrome browser v3.0.195.33 and Internet Explorer 8.0.6001.18865. But indeed, Firefox v3.5.5 shows the zeroes! You can download: http://api.browsershots.org/screenshots/091209-075848-jeremy.cowgar.com-4005547.zip and see the results in 53 different browsers. IE, Avant, Safari and Chrome all show 1. 2. 3. The rest show 0. 0. 0. Further, all text based browsers I've found show 0 0 0. Ok, Jeremy has a point in adding a non-digit as a token for a automatically numbered list, and seeding the enumeration value only if an explicit digit is given. I committed the change, however, it does not seed anything. It just uses normal HTML syntax. For instance: # Red # Green # Blue is output as: ol liRed/li liGreen/li liBlue/li /ol The old syntax of: 12. Red 98. Green 3. Blue still exists and still outputs: ol li value=12Red/li li value=98Green/li li value=3Blue/li /ol Jeremy ___ 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] 3 Feature requests - globbing using the repository.
Michael fos...@autosys.us wrote:
I find myself having removed files sometimes for which I have not
yet done 'fossil rm'. I do not have any missing files right now
so I cannot double check the following, but I think this is what
works for me in those situations (GNU/Linux) ...
$ for arg in $( fossil ls | egrep ^MISSING | awk '{print $2}' ) ;
do
fossil rm ${arg} ;
done
I usually run 'echo fossil rm ${arg}' first just to make sure
it looks good before I commit to the 'fossil rm'.
'fossil changes' probably works as well as the 'fossil ls'
One thing that we need to remember is that Fossil is cross platform and that
means, in our case, Windows, which has an inferior shell. Aside from that, I
wouldn't want to make someone learn awk just so they can use our SCM system.
There are many tricks that can be done but none should really be required for a
daily task.
Jeremy
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Commit failing... retyping commit message
In the 3 features... thread, I read from Michael: Secondly, I always get bit with my commit failing and then having to type in my comment again (after the monkeying around with 'fossil rm'). It seems that fossil is in need of two things: 1. Save the commit message to a file when the commit failed 2. Provide a means of making fossil read the commit message from a file i.e. $ fossil commit (enter your message in the editor that was loaded) ... ERROR ... ... Your commit message was saved to fossil-commit.a493bd8 ... $ # fix error $ fossil commit -cf fossil-commit.a493bd8 ... SUCCESS ... This would also make it easier to integrate into various editors/IDEs, i.e. being able to ask a commit message, save it to a file then call the appropriate fossil command. Jeremy ___ 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] 3 Feature requests - globbing using the repository.
Andreas Kupries andre...@activestate.com wrote: Michael wrote: Attached a few helper functions (bash) I use when working with fossil ... Mostly to shorten the command line I wonder if it wouldn't be helpful to provide a fossil config option for file based operations. i.e. it would allow fossil rm, fossil mv to actually perform those actions on the file system as well, if enabled. Jeremy ___ 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] 3 Feature requests - globbing using the repository.
Stephan Beal sgb...@googlemail.com wrote: IMO, duplicating the shell functionality is the wrong approach, mainly because there will be behavioural differences between fossil's and the shell's globbing. i agree it would be convenient for us users, but it technically could not be guaranteed to behave the same as the user's shell, and therefore could cause confusion or even data loss (e.g. accidental removal or even purging by using an incompatible glob pattern). While I agree that we should not get into globbing and making the user do '*.c' I do think we should allow the option of making fossil mv and fossil rm actually move or remove the file. That is 'semi-shell' functionality added. Almost every single time I use fossil rm or fossil mv, I do: C:\Development\MyProject fossil rm abc.c DELETED abc.c C:\Development\MyProject del abc.c C:\Development\MyProject If it were a config option, then there wouldn't be troubles like this (I don't think). The user should be able to override the default option via a command line argument, maybe: $ fossil rm --no-action abc.c def.xyz $ fossil mv --no-action abc.d 123.789 Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Login/Logout while on localhost
In another discussion, I read: i noticed a similar problem a couple days ago - it is impossible to log out when connecting to a local fossil server over the localhost IP. i wanted to test the anonymous captcha filler and had to log in over the IP my NIC gets from my WLAN router in order to be able to log in and out. Any connections over localhost were automatically my admin account, and i couldn't log out. If you turn on the Require password for local access option found under AdminAccess, then you will be able to login/logout while connecting via localhost. Jeremy ___ 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] 3 Feature requests - globbing using the repository.
Joshua Paine jos...@letterblock.com wrote: On Wed, 2009-12-09 at 19:49 +, Jeremy Cowgar wrote: If it were a config option What kind of config option are we talking about here? This isn't the sort of thing that makes sense to be per-project or per-repo. If I want `fossil rm` to delete files too, I want it all the time. It could be an environment variable, I guess, but I can't say I like that option either--it means remembering to set a fossil-specific env variable on every virtual private server I use. What about fossil rm --do foo.bar fossil mv --do foo.bar foo.baz or fossil rm --force foo.bar fossil mv --force foo.bar foo.baz I am thinking of a config option that is per repo, much like the Require password for local access, Automatically synchronize with repository or Sign all commits with GPG. Although it's the default behavior of many SCM systems, I'm afraid some will not like it all of a sudden removing their files when it never did before. I'd like to see the option be defaulted to on and then for that one in a million time when you don't actually want to remove the file, you can override it via the command line. Jeremy ___ 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] Commit failing... retyping commit message
Stephan Beal sgb...@googlemail.com wrote: Theoretically (i haven't tried it) you could use a workaround like this: a) Put your commit in a file, e.g. msg.txt. b) type: EDITOR=cat msg.txt fossil commit foo.c whether or not that works depends largely on how the EDITOR arg is passed on to the system (as a single arg via execvp() and friends or as part of a concated string passed to system()). Hm, I just relized how your EDITOR= example works. That will not work with Fossil, as the way the EDITOR= variable works is: $ export EDITOR=nano $ fossil commit --- Here fossil see's that no message has been supplied on the command line so it generates a unique filename and then writes something like: # All text below this line will be ignored. # ADDED abc.xyz # DELETED def.123 # MODIFIED john.doe It then does a system call something like: nano unique-filename.txt You are then presented with the editor editing unique-filename.txt. You add your comment, quit the editor (saving of course) and fossil continues. If fossil sees that you have not added any content to the file (i.e. didn't save it), then it will say Empty commit message, continue? [yN]. So, fossil already writes/reads from a commit message, it just doesn't expose the functionality to the user. Jeremy ___ 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] 3 Feature requests - globbing using the repository.
Stephan Beal sgb...@googlemail.com wrote: On Wed, Dec 9, 2009 at 10:09 PM, Jeremy Cowgar jer...@cowgar.com wrote: I'd like to see the option be defaulted to on and then for that one in a million time when you don't actually want to remove the file, you can override it via the command line. i would recommend the flag name --keep for that. Yes, that's good, however, what about for mv ? I guess --keep would work as well and if you mv with a --keep, then it turns into a copy, as far as the file system is concerned. That said, presumably when you rm a file, it already exists in the repo, and the chance of a significant loss due to an unwanted unlink() on the file seems to be small. :-? Yes. I am sure that we can do a check such as the one when calling revert. In this case it could be: remove file 'abc.txt'? this file has changed since last commit [yN]? So, the chances of loss go down further. Now, if no changes were made, then obviously no message would appear. We would then also have to provide a --force to both the mv and rm options so that a rm/mv could be scripted (not get the prompt). Jeremy ___ 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] Commit failing... retyping commit message
D. Richard Hipp d...@hwaci.com wrote: It seems to me that a better approach would be to improve the commit command so that it does a better job of detecting problems *before* it asks you to type in the commit message. In other words, if the commit is going to fail, have it fail early. Yes, that does make sense, but I believe the suggested functionality still has merit, especiallt for being able to script/integrate fossil into other products easily. i.e. reading a commit message from a file instead of on the command line. What is it that is causing your commits to fail so frequently? What can we do to get fossil to detect these problems before you type in your commit message? I'm not so sure that I have had commit's fail frequently. It has happened to me but I can't remember why. I was simply providing possible solutions to fix the retyping issue of the original author. I did spawn this thread from the 3 features request thread. Michael wrote: Secondly, I always get bit with my commit failing and then having to type in my comment again (after the monkeying around with 'fossil rm'). in: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01012.html Jeremy ___ 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] Commit failing... retyping commit message
Stephan Beal sgb...@googlemail.com wrote: On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar jer...@cowgar.com wrote: It seems that fossil is in need of two things: 1. Save the commit message to a file when the commit failed 2. Provide a means of making fossil read the commit message from a file i've just added -M/--comment-file which does #2. If there are no objections to using -M/--comment-file for this, i will commit it. I like this functionality and think it's very necessary for the ability to easily script fossil. Jeremy ___ 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] Commit failing... retyping commit message
D. Richard Hipp d...@hwaci.com wrote: On Dec 9, 2009, at 5:00 PM, Stephan Beal wrote: On Wed, Dec 9, 2009 at 6:39 PM, Jeremy Cowgar jer...@cowgar.com wrote: It seems that fossil is in need of two things: 1. Save the commit message to a file when the commit failed 2. Provide a means of making fossil read the commit message from a file i've just added -M/--comment-file which does #2. If there are no objections to using -M/--comment-file for this, i will commit it. I was looking into storing the commit comment in the local _FOSSIL_ database and automatically reinitializing the commit message to the old comment on the second attempt to commit after the first attempt failed. In other words, make it fully automatic. Check back tomorrow and see if I don't have something working I don't think that the -M/--comment-file really has much to do with a failing commit or the previous commit message. It would help with this problem, of course, but your solution is equally as well. The place that I really see -M/--comment-file working is with scripting and integration of fossil into 3rd party products. Many editors/IDE's provide the ability to commit from the editor. They will bring up a dialog or query the user in some manner, write the message to disk and call svn, cvs, hg or whatever withe the commit message file. We too should provide that option if we want to see fossil become more widely accepted. Now, on another note (a bit more personal to my work flow)... I will keep a file open in my editor that is changes. I'll document my changes in that file. Then, when I commit, I simply pass it on the command line. Thus, I never forget what I did between commits. Once I commit, I clear the file and start the process over again. On both accounts, the -M/--comment-file are necessary and a good idea, apart from the problem being discussed. Jeremy ___ 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] Commit failing... retyping commit message
Stephan Beal sgb...@googlemail.com wrote: On Thu, Dec 10, 2009 at 12:48 AM, Wilson, Ronald rwils...@harris.comwrote: I like DRH's idea but I agree with others that a --comment-file|-M feature is needed for integration applications. However, I think --comment-file could be less verbose and -M is begging for caps-lock confusion. I suggest --infile|-i COMMENT-FILE-NAME. i apologize to all - i didn't mean to open up a can of worms. i'll wait on DRH's vote/veto, and commit (or not). If i do, i'll change it to --infile/-i unless there are strong objections. For those of you who want it now, the diff is in one of the previous posts. I personally would be confused looking at just an option list: fossil commit [-m|--message commit-message] [-i|--infile filename] [...] [file] Infile what? I wouldn't worry about --comment-file, it may seem a bit verbose but who's going to use that directly? tools for clarity, but for users, they would use -M (or whatever it winds up being). Actually, thinking about it, I'd keep both -M and --commit-file. If they mess up and type fossil commit -M Commit Message they will get an error: File 'Commit Message' could not be opened. Now, look at: fossil commit -m|--message commit-message] [-M|--message-file filename] [...] [file] It makes sense with no further help information. Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] File List via the Files Menu... Listing old files?
I do not use the Files link much, at all, however today I noticed that the File List via the main toolbar's Files link shows files that are no longer in the repo. Well, in any current leaf that is. They are obviously there in old revisions. Is this the designed behavior? You can see this on: http://jeremy.cowgar.com/mailroom/index.cgi/dir See the files combobox.tcl and notebook.tcl ? Those were removed a while ago from a commit. You can see via the Leaves link http://jeremy.cowgar.com/mailroom/index.cgi/leaves that there is only one active leaf and viewing it's files link you can see that the two mentioned files are no longer part of the project. http://jeremy.cowgar.com/mailroom/index.cgi/dir?ci=a3ee17ca11 Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] RSS feed times off?
You can look at: http://jeremy.cowgar.com/mailroom/index.cgi/timeline and see: 2009-12-08 17:20:15 * [d2dfbefa0e] Leaf Modified message_insert to accept parameterized arguments including -fromfetch which will trigger the use of logging. (user: jnc, tags: trunk) 17:10:24 * Changes to wiki page mailroom (user: jnc) Now, looking at the RSS feed, I see: item titleModified message_insert to accept parameterized arguments including -fromfetch which will trigger the use of logging./title pubDateTue, 8 Dec 2009 21:20:15 GMT/pubDate /item item titleChanges to wiki page [mailroom]/title pubDateTue, 8 Dec 2009 22:10:24 GMT/pubDate /item I snipped out some long elements, the important ones are of course the date and title so you can see the difference. The RSS feed URL is: http://jeremy.cowgar.com/mailroom/index.cgi/timeline.rss I have not dove into the time conversion side of fossil yet. Any one have a quick idea about the problem? Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] RSS times off?
I believe this is something not right with the RSS times. If you look at the timeline for Mailroom (http://jeremy.cowgar.com/mailroom/index.cgi/timeline), you see: 2009-12-08 18:04:21 * [6837669f52] Leaf Fixed the argument handling to message_insert (user: jnc, tags: trunk) 17:20:15 * [d2dfbefa0e] Modified message_insert to accept parameterized arguments including -fromfetch which will trigger the use of logging. (user: jnc, tags: trunk) 17:10:24 * Changes to wiki page mailroom (user: jnc) Notice the 17:20 and 17:10 enties. Now if you look at the RSS source (some items trimmed that were long): item titleFixed the argument handling to message_insert/title pubDateTue, 8 Dec 2009 22:04:21 GMT/pubDate /item item titleModified message_insert to accept parameterized arguments including -fromfetch which will trigger the use of logging./title pubDateTue, 8 Dec 2009 21:20:15 GMT/pubDate /item item titleChanges to wiki page [mailroom]/title pubDateTue, 8 Dec 2009 22:10:24 GMT/pubDate /item The two listed in the timeframe are 17:20 and 17:10 but in the rss feed those two same items are 21:20 and 22:10. The 17:20 and 17:10 are correct. Now, their are two problems with the RSS feed. It seems like it's converting again to GMT and secondly, somehow one item is ahead 1 hour. Any thoughts on this? Jeremy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
