Re: [fossil-users] SSL certificate verification problem
On Thu, 17 Oct 2013 06:01:51 +0200, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Tue, 15 Oct 2013 19:08:30 +0200: [stephan@host:~/cvs/fossil/fossil/src]$ grep 'server does not respond' *.* The actual error is: Accept certificate for host fossil (a=always/y/N)? y server did not reply $ grep 'server did not reply' *.* http.c:fossil_fatal(server did not reply); To cause this error message I just killed the remote fossil process that was running before answering y. I suspect that something like a dropped connection may have been the cause of this, but it's hard to say without more details (and reproducibility). I'm sorry, I don't have any of these details right now. I propose to ask my colleague to try to reproduce the error. I might take a bit of time, though. is this of interest? for the record, what I do now is: -- the problem occurred during the initial clone attempt of an essentially empty new repo (might have been 100kB) -- if this makes a difference: it was a cgi-served repo and https -- yes, there is a firewall involved I've thought about a possible time-out problem but I would presume he (the colleague in the US) did just follow the provided recipe (he has no previous experience with fossil) step by step (type fossil clone https:username@server repo.fossil and provide password...) and it seems quite unlikely that he walked away for coffee at that point w/o answering the question). Andy -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 message empty
Using a marker line would allow for commit messages to contain any content For example: == [commit message goes here, any character accepted] ### End comment Enter comments on this check-in. Lines below the last '### End comment' are ignored user: user tags: trunk EDITED ... Thanks Steve On Thu, Oct 17, 2013 at 1:30 AM, Matt Welland estifo...@gmail.com wrote: 1. Until today, '#' fell into the category of extremely unlikely to cause a problem ;) = I've hit this limitation a couple times. It seemed a little silly to me to use a single hash in this context but since I could go into the UI and fix things I didn't consider it important enough to report. 2. I think that's too long, especially when you un-comment lines to include them (unless your editor supports rectangular selection). = Make it shorter, how about #fsl#? Any decent modern editor has rectangular selection I'm sure. Us antiquated vi and (x)emacs users are covered of course :) When I have a multi-line comment to enter I just put my -m at the end of line and use quotes however I generally prefer succinct one line comments. On Wed, Oct 16, 2013 at 11:51 AM, Ron Wilson ronw.m...@gmail.com wrote: On Wed, Oct 16, 2013 at 2:43 PM, Matt Welland estifo...@gmail.comwrote: Simply make the ignore prefix something extremely unlikely to collide such as: ##-fossil-## Enter comments on this check-in. ##-fossil-## Lines beginning with ##-fossil-## are ignored. ##-fossil-## ##-fossil-## user: matt ##-fossil-## tags: v1.55 ##-fossil-## ##-fossil-## EDITED db.scm ##-fossil-## EDITED tests/Makefile I think that's too long, especially when you un-comment lines to include them (unless your editor supports rectangular selection). ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] commit message empty
On Thu, Oct 17, 2013 at 3:14 PM, Stestagg stest...@gmail.com wrote: Using a marker line would allow for commit messages to contain any content i can't say that i would like commit messages to be able to contain any content. They're not intended to be general purposes documentation, but _brief_ descriptions of changes made in the context of the current commit. A commit message field is not intended to hold a whole changelog for a release nor a combined list of all changes from commits imported en masse from another SCM (for such uses, just keep the change list as a separate file and check it in along with the commit). IMO the whole thing is far more trouble than it's worth and introduces many corner cases and bugs where we currently don't have any (or only have very old, well-understood ones which we can blame on the other systems which were emulated ;). If it ain't broke, don't touch it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit message empty
On Thu, Oct 17, 2013 at 3:55 PM, j. van den hoff veedeeh...@googlemail.comwrote: `FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what somebody else already proposed). I'd say that will work better than `#' (i.e. accidentally names clash very very unlikely) and sufficiently stands out on the respective lines due to the capitalization. Historical note (i don't think you've been on the list long enough to have seen this): here's the summary from some code comments in fossil: /* ** Locate the root directory of the local repository tree. The root ** directory is found by searching for a file named _FOSSIL_ or .fslckout ** that contains a valid repository database. ** ** For legacy, also look for .fos. The use of .fos is deprecated ** since fos has negative connotations in Hungarian, we are told. ... A user made us aware at some point that fos is an ugly/inappropriate word in his language (i concur with the code comment that it was Hungarian). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit message empty
On Thu, 17 Oct 2013 15:59:45 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 3:55 PM, j. van den hoff veedeeh...@googlemail.comwrote: `FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what somebody else already proposed). I'd say that will work better than `#' (i.e. accidentally names clash very very unlikely) and sufficiently stands out on the respective lines due to the capitalization. Historical note (i don't think you've been on the list long enough to have seen this): here's the summary from some code comments in fossil: /* ** Locate the root directory of the local repository tree. The root ** directory is found by searching for a file named _FOSSIL_ or .fslckout ** that contains a valid repository database. ** ** For legacy, also look for .fos. The use of .fos is deprecated ** since fos has negative connotations in Hungarian, we are told. ... A user made us aware at some point that fos is an ugly/inappropriate word in his language (i concur with the code comment that it was Hungarian). well, there are _towns_ having offending names http://en.wikipedia.org/wiki/Fucking,_Austria :-) so I presume the hungarian users will probably don't take real offense but anyway FOSSIL: would be fine to. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 message empty
On Thu, Oct 17, 2013 at 4:03 PM, j. van den hoff veedeeh...@googlemail.comwrote: well, there are _towns_ having offending names lol! There's a bus line (from Germany) which has got a nearly identical name. FOSSIL: seems reasonable to me, but i'm not going to volunteer to change it for the simple reason that have only used the $EDITOR feature one time ever (across all SCMs, going back about 16 years), and that was to test the comment/message change you submitted a few days ago. For those who don't know about it: fossil supports a -M (big emm) option which reads the commit message from a file and doesn't not apply any #-related special handling to the content (or it didn't at the time it was implemented, and i'm assuming that hasn't changed), e.g.: fossil commit -M messagefile file1 file2... -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit message empty
I also take exception to this being only a recent phenomena. I have been burned several times now, but as you say, this is not a mission critical error. However, me and my users cherish the timeline view and are confused by random omissions of '#'this or '#'that. So I do not feel the comments are trivial. I would really appreciate any of the other suggestions. Multi-char lead being less onerous. #Thanks for fossil! On Thu, Oct 17, 2013 at 10:03 AM, j. van den hoff veedeeh...@googlemail.com wrote: On Thu, 17 Oct 2013 15:59:45 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 3:55 PM, j. van den hoff veedeeh...@googlemail.com**wrote: `FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what somebody else already proposed). I'd say that will work better than `#' (i.e. accidentally names clash very very unlikely) and sufficiently stands out on the respective lines due to the capitalization. Historical note (i don't think you've been on the list long enough to have seen this): here's the summary from some code comments in fossil: /* ** Locate the root directory of the local repository tree. The root ** directory is found by searching for a file named _FOSSIL_ or .fslckout ** that contains a valid repository database. ** ** For legacy, also look for .fos. The use of .fos is deprecated ** since fos has negative connotations in Hungarian, we are told. ... A user made us aware at some point that fos is an ugly/inappropriate word in his language (i concur with the code comment that it was Hungarian). well, there are _towns_ having offending names http://en.wikipedia.org/wiki/**Fucking,_Austriahttp://en.wikipedia.org/wiki/Fucking,_Austria:-) so I presume the hungarian users will probably don't take real offense but anyway FOSSIL: would be fine to. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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 message empty
For those who don't know about it: fossil supports a -M (big emm) option which reads the commit message from a file and doesn't not apply any #-related special handling to the content (or it didn't at the time it was implemented, and i'm assuming that hasn't changed) - stephan beal Whoa, I didn't know that? If this is true, why couldn't fossil collapse that same effect for a manual commit step? My commit use model is I always select all and delete all predefined comments and paste in my own. Unless I am doing a merge and then I take advantage of the autogenerated sha1 artifact specified. But, then I have to remember to delete the dang '#' symbol!! :( It is more work to specify a message file, since my history/commit documents are appended and not isolated or new per commit. On Thu, Oct 17, 2013 at 10:23 AM, sky5w...@gmail.com wrote: I also take exception to this being only a recent phenomena. I have been burned several times now, but as you say, this is not a mission critical error. However, me and my users cherish the timeline view and are confused by random omissions of '#'this or '#'that. So I do not feel the comments are trivial. I would really appreciate any of the other suggestions. Multi-char lead being less onerous. #Thanks for fossil! On Thu, Oct 17, 2013 at 10:03 AM, j. van den hoff veedeeh...@googlemail.com wrote: On Thu, 17 Oct 2013 15:59:45 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 3:55 PM, j. van den hoff veedeeh...@googlemail.com**wrote: `FOSSIL:' or even `FOS:' as the unique identifier (which mostly is what somebody else already proposed). I'd say that will work better than `#' (i.e. accidentally names clash very very unlikely) and sufficiently stands out on the respective lines due to the capitalization. Historical note (i don't think you've been on the list long enough to have seen this): here's the summary from some code comments in fossil: /* ** Locate the root directory of the local repository tree. The root ** directory is found by searching for a file named _FOSSIL_ or .fslckout ** that contains a valid repository database. ** ** For legacy, also look for .fos. The use of .fos is deprecated ** since fos has negative connotations in Hungarian, we are told. ... A user made us aware at some point that fos is an ugly/inappropriate word in his language (i concur with the code comment that it was Hungarian). well, there are _towns_ having offending names http://en.wikipedia.org/wiki/**Fucking,_Austriahttp://en.wikipedia.org/wiki/Fucking,_Austria:-) so I presume the hungarian users will probably don't take real offense but anyway FOSSIL: would be fine to. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/** fossil-usershttp://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ 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 message empty
On Thu, Oct 17, 2013 at 4:37 PM, sky5w...@gmail.com wrote: If this is true, why couldn't fossil collapse that same effect for a manual commit step? i'm not sure what you mean by that? My commit use model is I always select all and delete all predefined comments and paste in my own. Mine is always to use -m ... ;). Unless I am doing a merge and then I take advantage of the autogenerated sha1 artifact specified. But, then I have to remember to delete the dang '#' symbol!! :( It is more work to specify a message file, since my history/commit documents are appended and not isolated or new per commit. AFAIK, nobody really uses the -M option (probably because it's too tedious to use for most purposes, maybe unless you're auto-importing lists of changes from another SCM). It was added back in December 2009, and IIRC it was because someone on the list proposed it and i thought i'd be interesting (but then i never used it myself). As far as the other changes go regarding the # symbol - i'm still waiting for someone else to volunteer :). As a general rule, i don't like to change features which have survived the test of time (even if they're not 100% ideal, so long as their limitations are well understood and not generally problematic). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit message empty
On Thu, Oct 17, 2013 at 5:01 PM, sky5w...@gmail.com wrote: If this is true, why couldn't fossil collapse that same effect for a manual commit step? i'm not sure what you mean by that? me - I'm asking why can't I perform a manual commit without comments being ignored, but not using -M. So you want a manual commit _with_ comments? Sorry, the quadruple negation here is confusing me: can't... without ... ignored ... not using. If you want to use '#' in your commit message, either use -M or type them in using -m: fossil commit -m '# part 1 # part 2 # part 3' file file2 file3 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] choice of default user for fresh clone
why is it that after fossil clone http://k...@enterprise.us/path_to_project project.fossil it still is the user name of the local account doing the clone that is defining the initial default user? I've stumbled over this a few times. it would seem wiser to automatically create and set the default user to kirk in this example (i.e. to the specified user name, if any (and only fall back to local user name if this is not the case). otherwise, if I forget to do fossil user add kirk fossil user default kirk (and at least `fossil user capabilities kirk v', I believe) the next checkin will unintentionally use my local user name (which I even might want not be broadcasted and ending up in the timeline display of the server repo). am I missing some important point here? -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] choice of default user for fresh clone
On Thu, Oct 17, 2013 at 5:34 PM, j. van den hoff veedeeh...@googlemail.comwrote: why is it that after fossil clone http://k...@enterprise.us/**path_to_projecthttp://k...@enterprise.us/path_to_projectproject.fossil it still is the user name of the local account doing the clone that is defining the initial default user? I've stumbled over this a few times. it would seem wiser to automatically create and set the default user to kirk in this example (i.e. to the specified user name, if any (and only fall back to local user name if this is not the case). otherwise, if I forget to do That looks like a classic case of historical usage. i suspect most of those who hack on Fossil itself tend to use the same login names across systems (i know that's true for me and Richard, in any case). It of course would make better sense to use the name provided in the URL. Could i convince you to open a ticket for this? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2-way sync between Git Fossil
On Oct 15, 2013, at 17:34 , Matt Welland wrote: I have done what Ron suggests before and it works well but it is initially complicated to set up. A generic script or tool to do this would be very nice to have available. I created vendor branches, one for each system, the git branch in fossil would track the git master and the fossil branch in git would track fossil. I use rsync to mirror the add/remove/change of files and then script up the commit to capture the comment, time stamp, user etc. of the incoming data. After rsync'ing in the change and committing it the script merges the change to the trunk. It is very complicated but once set up it works great. BTW, I've done this for other systems but never tried it with git. I'm not sure if there are any git related gotchas. One important question: what is wrong with fossil import --git and fossil export --git? 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
Re: [fossil-users] choice of default user for fresh clone
On Thu, 17 Oct 2013 17:39:23 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 5:34 PM, j. van den hoff veedeeh...@googlemail.comwrote: why is it that after fossil clone http://k...@enterprise.us/**path_to_projecthttp://k...@enterprise.us/path_to_projectproject.fossil it still is the user name of the local account doing the clone that is defining the initial default user? I've stumbled over this a few times. it would seem wiser to automatically create and set the default user to kirk in this example (i.e. to the specified user name, if any (and only fall back to local user name if this is not the case). otherwise, if I forget to do That looks like a classic case of historical usage. i suspect most of those who hack on Fossil itself tend to use the same login names across systems (i know that's true for me and Richard, in any case). It of course would make better sense to use the name provided in the URL. Could i convince you to open a ticket for this? convinced... should be there in a few minutes. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 message empty
On Thu, Oct 17, 2013 at 11:01 AM, sky5w...@gmail.com wrote: I'm asking why can't I perform a manual commit without comments being ignored, but not using -M. Maybe a command option or a config option. The underlying idea of providing and ignoring instructions to the user is still sound and is in line with Fossil's philosophy of making it easy to use out-of-the-box. Also, for what it's worth, my team currently relies on Fossil doing this. Yes, sometimes ignoring lines starting with # is inconvenient, but it's no big deal to hide the #. Again, for what it's worth, when we were still using MS Windows (because of tools being tied to MS Windows), we used CodeWright as our IDE, which had good support for command line tools. We configured the Check In command as fossil addremove; fossil commit -M %Q:Enter brief commit message%. For this, CW would pop-up a text entry dialog with the title Enter brief commit message, Then CW would would create a temporary file with the the entered text and run the command, replacing the %Q:...% with the file name. Once libfossil is far enough along, we might consider making plug-ins for the IDEs we currently use. ___ 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] choice of default user for fresh clone
I think the following patch will resolve the issue:
Index: src/clone.c
==
--- src/clone.c
+++ src/clone.c
@@ -131,10 +131,11 @@
}
zDefaultUser = find_option(admin-user,A,1);
url_parse(g.argv[2], URL_PROMPT_PW|URL_ASK_REMEMBER_PW);
+ if( zDefaultUser==0 g.urlUser!=0 ) zDefaultUser = g.urlUser;
if( g.urlIsFile ){
file_copy(g.urlName, g.argv[3]);
db_close(1);
db_open_repository(g.argv[3]);
db_record_repository_filename(g.argv[3]);
Can somebody apply the patch above and test it out for me?
On Thu, Oct 17, 2013 at 11:39 AM, Stephan Beal sgb...@googlemail.comwrote:
On Thu, Oct 17, 2013 at 5:34 PM, j. van den hoff
veedeeh...@googlemail.com wrote:
why is it that after
fossil clone
http://k...@enterprise.us/**path_to_projecthttp://k...@enterprise.us/path_to_projectproject.fossil
it still is the user name of the local account doing the clone that is
defining the initial default user? I've stumbled over this a few times.
it would seem wiser to automatically create and set the default user to
kirk in this example (i.e. to the specified user name, if any (and only
fall back to local user name if this is not the case). otherwise, if I
forget to do
That looks like a classic case of historical usage. i suspect most of
those who hack on Fossil itself tend to use the same login names across
systems (i know that's true for me and Richard, in any case). It of course
would make better sense to use the name provided in the URL.
Could i convince you to open a ticket for this?
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Since tyranny's the only guaranteed byproduct of those who insist on a
perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] choice of default user for fresh clone
On Thu, Oct 17, 2013 at 5:51 PM, Richard Hipp d...@sqlite.org wrote: + if( zDefaultUser==0 g.urlUser!=0 ) zDefaultUser = g.urlUser; Works for me! [stephan@host:~/tmp]$ f clone http://192.168.1.59:8080 x.fsl Round-trips: 2 Artifacts sent: 0 received: 3 Clone finished with 471 bytes sent, 1161 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: e7e284b800fba80fea27a00bdb67352a82584f24 admin-user: stephan (password is 6c5901) [stephan@host:~/tmp]$ f clone http://other:other@192.168.1.59:8080 y.fsl Round-trips: 2 Artifacts sent: 0 received: 3 Clone finished with 536 bytes sent, 1162 bytes received Rebuilding repository meta-data... 100.0% complete... project-id: e7e284b800fba80fea27a00bdb67352a82584f24 admin-user: other (password is 79c800) -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit message empty
On Thu, Oct 17, 2013 at 5:46 PM, Ron Wilson ronw.m...@gmail.com wrote: Once libfossil is far enough along, we might consider making plug-ins for the IDEs we currently use. sidebar/status update: i'm currently in one of my slow phases. i tend to develop in bursts of 3-5 months or so and then run out of steam for a couple months. If history repeats itself as predicted, i'll get back into it full speed around Christmas time (where i otherwise have little or nothing to do because Germany basically shuts down from the 3rd week of December until the 2nd week of January). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit message empty
Thus said Stephan Beal on Thu, 17 Oct 2013 16:49:53 +0200: As far as the other changes go regarding the # symbol - i'm still waiting for someone else to volunteer :). As a general rule, i don't like to change features which have survived the test of time (even if they're not 100% ideal, so long as their limitations are well understood and not generally problematic). I don't think changes are required: $ f ci -M - file EOF This is a test #this EOF New_Version: a037b79c0b552ac0a2c60b6530f19ae5f4022155 $ f stat repository: /tmp/new/../new.fossil local-root: /tmp/new/ config-db:/home/amb/.fossil checkout: a037b79c0b552ac0a2c60b6530f19ae5f4022155 2013-10-17 16:04:45 UTC parent: 950f43a6f0812dfb7b2a9b894b8bccb1aa056585 2013-10-17 16:04:20 UTC tags: trunk comment: This is a test #this (user: amb) Notice that it preserved my comment. Fossil FTW! Andy -- TAI64 timestamp: 400052600b14 ___ 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] choice of default user for fresh clone
On Thu, Oct 17, 2013 at 5:56 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 5:51 PM, Richard Hipp d...@sqlite.org wrote: + if( zDefaultUser==0 g.urlUser!=0 ) zDefaultUser = g.urlUser; Works for me! please try: http://fossil-scm.org/index.html/info/64aa75260f if that works let us know and i'll close your ticket (Richard had it fixed a few seconds before your ticket landed, i think!). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2-way sync between Git Fossil
On Thu, Oct 17, 2013 at 11:33 AM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: One important question: what is wrong with fossil import --git and fossil export --git? I tried that about a year ago. Fossil's export command lacks an option to specify which branches to export and marking all branches but the to git branch would have caused other problems for me. Was just easier to checkout exactly what I wanted to commit in git in a work area, then commit to git. But, if you want/need all the commits duplicated, then export/import would be worth setting up. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] CGI and REQUEST_URI
Hello, I've just tried upgrading from fossil 1.25 to fossil 1.27 on my server, which uses Jetty as the CGI server. I just see an error: Bad Request: missing REQUEST_URI and of course, Jetty isn't sending a REQUEST_URI. This environment variable isn't part of the CGI 1.1 spec, so I suppose we can excuse Jetty for not sending it: http://tools.ietf.org/html/rfc3875 It looks like the addition of SCGI support in http://www.fossil-scm.org/fossil/info/a2e7472d0fa04132 added the requirement for REQUEST_URI. Which one of fossil or Jetty needs fixing? Thanks, Ben -- http://bens.me.uk ___ 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] CGI and REQUEST_URI
On Thu, Oct 17, 2013 at 6:37 PM, Ben Summers b...@fluffy.co.uk wrote: and of course, Jetty isn't sending a REQUEST_URI. This environment variable isn't part of the CGI 1.1 spec, so I suppose we can excuse Jetty for not sending it: http://tools.ietf.org/html/rfc3875 It looks like the addition of SCGI support in http://www.fossil-scm.org/fossil/info/a2e7472d0fa04132 added the requirement for REQUEST_URI. Which one of fossil or Jetty needs fixing? i don't have a definitive answer (i'd never heard of SCGI before those patches arrived) but do have a tiny bit more info which might help someone else... http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface shows an example which implies that REQUEST_URI is indeed required by SCGI. As Ben says, though, it's not part of CGI. My suspicion is that Fossil needs to be fixed but that this hasn't yet been seen because Apache and friends provide REQUEST_URI even in CGI mode. i'll see if i can get an SCGI environment running here to try this out (apache appears to have a mod_scgi... let's see what that does...). i can't make any promises, but i'm looking into it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CGI and REQUEST_URI
On Thu, Oct 17, 2013 at 6:59 PM, Stephan Beal sgb...@googlemail.com wrote: My suspicion is that Fossil needs to be fixed but that this hasn't yet been seen because Apache and friends provide REQUEST_URI even in CGI mode. i'll see if i can get an SCGI environment running here to try this out (apache appears to have a mod_scgi... let's see what that does...). i can't make any promises, but i'm looking into it. Setting up mod_proxy and friends for this is going to take more effort than i can commit to tonight, but i'll give it a go after work tomorrow. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CGI and REQUEST_URI
On Thu, Oct 17, 2013 at 12:59 PM, Stephan Beal sgb...@googlemail.comwrote: On Thu, Oct 17, 2013 at 6:37 PM, Ben Summers b...@fluffy.co.uk wrote: and of course, Jetty isn't sending a REQUEST_URI. This environment variable isn't part of the CGI 1.1 spec, so I suppose we can excuse Jetty for not sending it: http://tools.ietf.org/html/rfc3875 It looks like the addition of SCGI support in http://www.fossil-scm.org/fossil/info/a2e7472d0fa04132 added the requirement for REQUEST_URI. Which one of fossil or Jetty needs fixing? i don't have a definitive answer (i'd never heard of SCGI before those patches arrived) but do have a tiny bit more info which might help someone else... http://en.wikipedia.org/wiki/Simple_Common_Gateway_Interface shows an example which implies that REQUEST_URI is indeed required by SCGI. As Ben says, though, it's not part of CGI. My suspicion is that Fossil needs to be fixed but that this hasn't yet been seen because Apache and friends provide REQUEST_URI even in CGI mode. i'll see if i can get an SCGI environment running here to try this out (apache appears to have a mod_scgi... let's see what that does...). i can't make any promises, but i'm looking into it. Apparently we construct REQUEST_URI by appending PATH_INFO to SCRIPT_NAME. The three are related. Currently, Fossil requires REQUEST_URI and SCRIPT_NAME at a minimum, and will construct PATH_INFO from those two if it is missing. I'm working on a patch to construct REQUEST_URI from SCRIPT_NAME and PATH_INFO if REQUEST_URI is missing instead. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CGI and REQUEST_URI
On Thu, Oct 17, 2013 at 7:17 PM, Richard Hipp d...@sqlite.org wrote: Currently, Fossil requires REQUEST_URI and SCRIPT_NAME at a minimum, and will construct PATH_INFO from those two if it is missing. I'm working on a patch to construct REQUEST_URI from SCRIPT_NAME and PATH_INFO if REQUEST_URI is missing instead. i think the requirement on REQUEST_URI is in general a mistake (though one which appears to mostly work). There's no mention of REQUEST_URI in the CGI spec, though many CGI examples/howtos i'm looking at do use this (and some even imply that they are standard (e.g. http://www.cgi101.com/book/ch3/text.html), but i can find no proof of that). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] choice of default user for fresh clone
On Thu, 17 Oct 2013 18:09:38 +0200, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 5:56 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 5:51 PM, Richard Hipp d...@sqlite.org wrote: + if( zDefaultUser==0 g.urlUser!=0 ) zDefaultUser = g.urlUser; Works for me! please try: http://fossil-scm.org/index.html/info/64aa75260f if that works let us know and i'll close your ticket (Richard had it fixed a few seconds before your ticket landed, i think!). it does. very very good. thanks a lot for fixing this. hoping for a fast next release (so that users not compiling themselves can get hold of it). -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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 message empty
Thus said sky5w...@gmail.com on Thu, 17 Oct 2013 13:06:02 -0400: Understood, but the point was to not create a message file. My example does not create a message file but instead tells fossil to read the commit message from stdin (using a here document): $ f ci -M - file EOF This is a test #this EOF New_Version: a037b79c0b552ac0a2c60b6530f19ae5f4022155 No editor is used in this case (except the command line editor) so it isn't exactly as interactive as using your favorite EDITOR but you don't have to supply a filename. Probably not exactly what you were looking for though. Andy -- TAI64 timestamp: 400052601e90 ___ 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] CGI and REQUEST_URI
On Thu, Oct 17, 2013 at 1:21 PM, Stephan Beal sgb...@googlemail.com wrote: On Thu, Oct 17, 2013 at 7:17 PM, Richard Hipp d...@sqlite.org wrote: Currently, Fossil requires REQUEST_URI and SCRIPT_NAME at a minimum, and will construct PATH_INFO from those two if it is missing. I'm working on a patch to construct REQUEST_URI from SCRIPT_NAME and PATH_INFO if REQUEST_URI is missing instead. i think the requirement on REQUEST_URI is in general a mistake (though one which appears to mostly work). There's no mention of REQUEST_URI in the CGI spec, though many CGI examples/howtos i'm looking at do use this (and some even imply that they are standard (e.g. http://www.cgi101.com/book/ch3/text.html), but i can find no proof of that). I've checked in a potential fix. The fix changes Fossil to require SCRIPT_NAME and one of REQUEST_URI or PATH_INFO. CGI should always supply PATH_INFO. SCGI should give us REQUEST_URI. Either way, Fossil will be happy now. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CGI and REQUEST_URI
On Thu, Oct 17, 2013 at 7:40 PM, Richard Hipp d...@sqlite.org wrote: The fix changes Fossil to require SCRIPT_NAME and one of REQUEST_URI or PATH_INFO. CGI should always supply PATH_INFO. SCGI should give us REQUEST_URI. Either way, Fossil will be happy now. @Ben: FWIW, i've deployed this to my Apache-based CGI host and it seems happy there. http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/json/version?indent=2 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] commit message empty
On Thu, Oct 17, 2013 at 8:25 PM, Ron Wilson ronw.m...@gmail.com wrote: $ cat fci #! /usr/bin/bash echo tmp$$.txt $EDITOR tmp$$.txt fossil ci -M tmp$$.txt $* rm tmp$$.txt If you want to go one further you can protect against ctrl-c leaving a temp file laying around by adding: trap rm -f tmp$$.txt 0 somewhere near the top (e.g., right after the first echo bit). OTOH, you might want to keep the temp file if the user Ctrl-C's out in an untimeline fashion. This will create a temporary file using the process number of the running script, then delete it after the commit is done. With the trap in place it's removed regardless of how the script exits. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CGI and REQUEST_URI
On Thu, Oct 17, 2013 at 01:40:28PM -0400, Richard Hipp wrote: Hi there, The fix changes Fossil to require SCRIPT_NAME and one of REQUEST_URI or PATH_INFO. CGI should always supply PATH_INFO. SCGI should give us REQUEST_URI. Either way, Fossil will be happy now. CGI only requires SCRIPT_NAME. If PATH_INFO would be non-empty, then it should be set for CGI. But an empty PATH_INFO and an absent PATH_INFO are equivalent. (And in that case, I guess that REQUEST_URI should have the same value as SCRIPT_NAME, if REQUEST_URI is wanted.) I think thttpd only sets PATH_INFO when non-empty. It sets SCRIPT_NAME, but not REQUEST_URI. f -- Francis Dalyfran...@daoine.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] 2-way sync between Git Fossil
On Thu, Oct 17, 2013 at 8:33 AM, Remigiusz Modrzejewski l...@maxnet.org.plwrote: On Oct 15, 2013, at 17:34 , Matt Welland wrote: I have done what Ron suggests before and it works well but it is initially complicated to set up. A generic script or tool to do this would be very nice to have available. I created vendor branches, one for each system, the git branch in fossil would track the git master and the fossil branch in git would track fossil. I use rsync to mirror the add/remove/change of files and then script up the commit to capture the comment, time stamp, user etc. of the incoming data. After rsync'ing in the change and committing it the script merges the change to the trunk. It is very complicated but once set up it works great. BTW, I've done this for other systems but never tried it with git. I'm not sure if there are any git related gotchas. One important question: what is wrong with fossil import --git and fossil export --git? If incremental import works reliably at both ends then yes, import/export would likely be the best option. The only other reasons why the brute force method might sometimes be better is if you have very large repositories and full import and export generate very large amounts of data or, as Ron says in another message, if you wish to keep only specific branches in sync. 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] how to edit All Tickets presentation
I've been using fossil for some of my private projects for a few months now, and at least on one of them there is no use for the subsystem field for tickets. I can see where to edit the schema to delete the field from the database, but for the life of me I can't figure out how to edit the All Tickets page to get rid of the subsystem column, and without that I will get an error when I display the page. -- Will ___ 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] how to edit All Tickets presentation
On Thu, Oct 17, 2013 at 6:14 PM, Will Parsons varro@nodomain.invalidwrote: I can't figure out how to edit the All Tickets page to get rid of the subsystem column, and without that I will get an error when I display the page. You can edit the default default report from the Admin-Ticket Setup page. For the existing All Tickets report, there is an Edit button on the tickets main menu for each report in the report list. ___ 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] how to edit All Tickets presentation
Ron Wilson wrote: On Thu, Oct 17, 2013 at 6:14 PM, Will Parsons varro@nodomain.invalidwrote: I can't figure out how to edit the All Tickets page to get rid of the subsystem column, and without that I will get an error when I display the page. You can edit the default default report from the Admin-Ticket Setup page. What? I don't see any default default report from the Admin-Ticket Setup page. For the existing All Tickets report, there is an Edit button on the tickets main menu for each report in the report list. Yes, but how does that help with changing the format of the All Tickets page? -- Will ___ 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] how to edit All Tickets presentation
Admin-Tickets-Report Template We use the subsystem field, so I created a summary report with out the subsystem and comments fields. Fossil then auto-generated only columns for the selected fields. On Thu, Oct 17, 2013 at 8:18 PM, Will Parsons varro@nodomain.invalidwrote: Ron Wilson wrote: On Thu, Oct 17, 2013 at 6:14 PM, Will Parsons varro@nodomain.invalid wrote: I can't figure out how to edit the All Tickets page to get rid of the subsystem column, and without that I will get an error when I display the page. You can edit the default default report from the Admin-Ticket Setup page. What? I don't see any default default report from the Admin-Ticket Setup page. For the existing All Tickets report, there is an Edit button on the tickets main menu for each report in the report list. Yes, but how does that help with changing the format of the All Tickets page? -- Will ___ 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] how to edit All Tickets presentation
Ron Wilson wrote: We use the subsystem field, so I created a summary report with out the subsystem and comments fields. Fossil then auto-generated only columns for the selected fields. I'm sorry, but I am completely at a loss to understand this. You *use* the subsystem field, but create a summary report without it? Why? And how? On Thu, Oct 17, 2013 at 8:18 PM, Will Parsons varro@nodomain.invalidwrote: Ron Wilson wrote: On Thu, Oct 17, 2013 at 6:14 PM, Will Parsons varro@nodomain.invalid wrote: I can't figure out how to edit the All Tickets page to get rid of the subsystem column, and without that I will get an error when I display the page. You can edit the default default report from the Admin-Ticket Setup page. What? I don't see any default default report from the Admin-Ticket Setup page. For the existing All Tickets report, there is an Edit button on the tickets main menu for each report in the report list. Yes, but how does that help with changing the format of the All Tickets page? -- Will ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
