[fossil-users] users table photo column
You may remember reading a few weeks back I've been playing around with putting together some management web management scaffolding around my repos to automate certain things (like copying shared settings from one repo to another, because I'm OCD like that, and not all config appear to have global versions). In any case, in the process I was looking at schema and saw there is a photo column in the users table. I imagine it is for a photo of the user, but cannot find anywhere that it is used. Is this something that was added for specific skins/themes to use or is it something that is generally usable/accessible? This is mostly a curiosity based question. At the moment all the photo for all rows is NULL so it's not something I'm worried about copying, per se. Just wondering the rationale/workings of it. -- Scott Robison ___ 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] users table photo column
On Tue, May 27, 2014 at 4:05 AM, Scott Robison sc...@casaderobison.comwrote: You may remember reading a few weeks back I've been playing around with putting together some management web management scaffolding around my repos to automate certain things (like copying shared settings from one repo to another, because I'm OCD like that, and not all config appear to have global versions). In any case, in the process I was looking at schema and saw there is a photo column in the users table. I imagine it is for a photo of the user, but cannot find anywhere that it is used. Is this something that was added for specific skins/themes to use or is it something that is generally usable/accessible? Originally designed for a photo of the user, but not currently used. This is mostly a curiosity based question. At the moment all the photo for all rows is NULL so it's not something I'm worried about copying, per se. Just wondering the rationale/workings of it. -- Scott Robison ___ 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] users table photo column
On Tue, May 27, 2014 at 4:22 AM, Richard Hipp d...@sqlite.org wrote: In any case, in the process I was looking at schema and saw there is a photo column in the users table. I imagine it is for a photo of the user, but cannot find anywhere that it is used. Is this something that was added for specific skins/themes to use or is it something that is generally usable/accessible? Originally designed for a photo of the user, but not currently used. Thanks. BTW, for those who might be curious, it is a pain to get php fossil to cooperate to create a new repo (HOME env var needs to be set and user can't be detected so --admin-user must be specified). I think it was mostly due to the late hour, as the php system function doesn't display stderr by default, and it took me a while to realize I needed to redirect it myself so I could read the useful command line errors fossil was *trying* to display. Once I did that, it was trivial to get everything working. Probably shouldn't work so late. Whatever. My stuff is now working. YAY! Sorry for polluting the mail list with my self congratulatory blather. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Running script on push
Hi, Nowadays tools like Jenkins can run tests on triggers (or hooks), and it works wonderful. But Jenkins is overkilling (Java based :s) to be a match to the tiny but powerful and agile fossil. Even when this fellow ronperrela did a nice job integrating Jenkins: http://ronperrella.blogspot.com/2012/06/using-fossil-scm-with-jenkins-ci.html I was looking for an easier path. My set of tests can be run from command line, and I really like shell scripting, so I was wondering, does fossil has a trigger mechanism (on commit / push) run this command? Do you see any utility on such an idea, or is just me? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Running script on push
I see there is a way to run a TH1 script. But as far as I see the th1 documentation, I can't find a way to invoke a shell script out of it. Any ideas??? 2014-05-27 8:04 GMT-04:30 Abilio Marques amarq...@smartappsla.com: Hi, Nowadays tools like Jenkins can run tests on triggers (or hooks), and it works wonderful. But Jenkins is overkilling (Java based :s) to be a match to the tiny but powerful and agile fossil. Even when this fellow ronperrela did a nice job integrating Jenkins: http://ronperrella.blogspot.com/2012/06/using-fossil-scm-with-jenkins-ci.html I was looking for an easier path. My set of tests can be run from command line, and I really like shell scripting, so I was wondering, does fossil has a trigger mechanism (on commit / push) run this command? Do you see any utility on such an idea, or is just me? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] FYI: doc URLs don't work with filenames that have + in their names
I had a file called README-Visual-C++.txt in one of my repositories and wanted to link to the tip version of it from an outside web page. I discovered the doc URL feature in Fossil, but it didn't work with that file. Apparently there's some kind of data sanitization going on here that turns the +'s into spaces. I say had because I just renamed it to README-Visual-Studio.txt and moved on. Perhaps someone wants to fix this in Fossil, though. ___ 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] FYI: doc URLs don't work with filenames that have + in their names
On Tue, May 27, 2014 at 3:43 PM, Warren Young war...@etr-usa.com wrote: I had a file called README-Visual-C++.txt in one of my repositories and wanted to link to the tip version of it from an outside web page. I discovered the doc URL feature in Fossil, but it didn't work with that file. Apparently there's some kind of data sanitization going on here that turns the +'s into spaces. I say had because I just renamed it to README-Visual-Studio.txt and moved on. Perhaps someone wants to fix this in Fossil, though. I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. If the filename really does contain + symbols, then the URL should have %2b for each plus. ex: http://localhost/doc/trunk/README-Visual-C%2b%2b.txt ___ 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] FYI: doc URLs don't work with filenames that have + in their names
Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400: I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. It certainly handles them correctly when given them, however, there may be a potential buglet in how it publishes the base URL. All of the skins for the header include the following: base href=$baseurl/$current_page / Which results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/file++.wiki; / So it appears that it doesn't preserve the encoding. Should it? Perhaps this should really be something like the following? th1 html base href='$baseurl/[httpize $current_page]' / /th1 This results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href='http://localhost:8080/doc%2Ftip%2Ffile%2B%2B.wiki' / Thanks, Andy -- TAI64 timestamp: 40005384f35f ___ 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] FYI: doc URLs don't work with filenames that have + in their names
Or, maybe $current_page should be HTTP-encoded instead of plaintext. On Tue, May 27, 2014 at 4:19 PM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400: I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. It certainly handles them correctly when given them, however, there may be a potential buglet in how it publishes the base URL. All of the skins for the header include the following: base href=$baseurl/$current_page / Which results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/file++.wiki; / So it appears that it doesn't preserve the encoding. Should it? Perhaps this should really be something like the following? th1 html base href='$baseurl/[httpize $current_page]' / /th1 This results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href='http://localhost:8080/doc%2Ftip%2Ffile%2B%2B.wiki' / Thanks, Andy -- TAI64 timestamp: 40005384f35f -- 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] FYI: doc URLs don't work with filenames that have + in their names
Candidate fix checked into trunk. On Tue, May 27, 2014 at 4:21 PM, Richard Hipp d...@sqlite.org wrote: Or, maybe $current_page should be HTTP-encoded instead of plaintext. On Tue, May 27, 2014 at 4:19 PM, Andy Bradford amb-fos...@bradfords.orgwrote: Thus said Richard Hipp on Tue, 27 May 2014 15:46:30 -0400: I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. It certainly handles them correctly when given them, however, there may be a potential buglet in how it publishes the base URL. All of the skins for the header include the following: base href=$baseurl/$current_page / Which results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/file++.wiki; / So it appears that it doesn't preserve the encoding. Should it? Perhaps this should really be something like the following? th1 html base href='$baseurl/[httpize $current_page]' / /th1 This results in the following output: $ printf 'GET /doc/tip/file%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href='http://localhost:8080/doc%2Ftip%2Ffile%2B%2B.wiki' / Thanks, Andy -- TAI64 timestamp: 40005384f35f -- D. Richard Hipp d...@sqlite.org -- 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] FYI: doc URLs don't work with filenames that have + in their names
Hello, on Tuesday 27 May 2014 at 15:46, Richard Hipp wrote: On Tue, May 27, 2014 at 3:43 PM, Warren Young war...@etr-usa.com wrote: I had a file called README-Visual-C++.txt in one of my repositories and wanted to link to the tip version of it from an outside web page. I discovered the doc URL feature in Fossil, but it didn't work with that file. Apparently there's some kind of data sanitization going on here that turns the +'s into spaces. I say had because I just renamed it to README-Visual-Studio.txt and moved on. Perhaps someone wants to fix this in Fossil, though. I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. If the filename really does contain + symbols, then the URL should have %2b for each plus. ex: http://localhost/doc/trunk/README-Visual-C%2b%2b.txt In mohawk (tiny) webserver project we encountered the same kind of problem, and discovered in the process that major webserver (like apache, nginx and lighttpd, though I don't remember exactly which ones) fall back on not decoding '+' when providing files from disk. I can understand how one could see value in following the most common behavior even when it's technically not the right thing to do. Hoping this helps, Natacha Porté pgpISegVxdCcY.pgp Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Server static files to load JSON APP
Hi fossil-users, I have simple JS app (build with GWT) and these static files are in one folder ./jsout How can I start fossil to serve these files in static mode. I need a comand like that: ./fossil server repo.db --static-dir ./jsout --static-url /jsout And http://localhost:8080/jsout/index.html return ./jsout/index.html file http://localhost:8080/jsout/logo.gif return ./jsout/logo.gif file http://localhost:8080/jsout/myapp.js return ./jsout/myapp.jsfile How we can do that ? I can do that with apache/proxy but, I prefer to use only fossil.exe on my Windows machine. Gerrit http://code.google.com/p/gerrit/ is on client a GWT app (js in browser) and almost all requests to servers a done with JSON-RPC. Thanks, -- Petrica Clement Chiriac (Tica2) CEO, Fluxinternet SRL *petrica_chir...@fluxinternet.ro petrica_chir...@fluxinternet.ro* +40 722 134 009 @Tica2 ___ 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] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 13:46, Richard Hipp wrote: If the filename really does contain + symbols, then the URL should have %2b for each plus. Sorry, I should have mentioned that I did try that. This is with the nginx-proxied configuration that I posted here about on Sunday. I suspect nginx is translating the %2b to + before sending the URL on per http://forum.nginx.org/read.php?2,75231,175761#msg-175761 According to that forum post, nginx only does this when the proxy URL has a trailing slash, but I need that to avoid the redirect issue I mentioned in that Sunday post. Here's the headers for one iteration of the redirect loop: Request by Firefox: GET /code/timeline HTTP/1.1 Host: xx.org Cookie: fossil-blablabla X-Other-Headers: squished Response from Fossil: HTTP/1.1 302 Moved Temporarily Server: nginx/1.4.6 (Ubuntu) Date: Tue, 27 May 2014 22:38:10 GMT Content-Type: text/html; charset=utf-8 Content-Length: 96 Connection: keep-alive Location: http://x.org/code/timeline X-Frame-Options: SAMEORIGIN Cache-Control: no-cache Content-Encoding: gzip Vary: Accept-Encoding As you can see, the 302 sends us right back to the page we requested, so it loops until the browser hits its redirect limit. It seems I can either have URL encoding passed unchanged, or I can have the proxy actually work. I can't have both at once. Rather than make Fossil tolerate unescaped + in URLs as Natacha noticed that the the mainstream web servers do, I'd rather figure out why the redirect loop happens and fix that. I'm willing to test tip-o-trunk versions to help resolve this. I've got this Fossil server running on an in-development site, which is why I've redacted the URLs above. I probably have a month or so to play with it before I'm going to publish the URL. Until then, I can break it any time I want and leave it broken for long periods. Incidentally, I'm bothering with nginx proxying because the SCGI method seems to have broken in 1.28. It was working fine on my site with 1.27 from the Ubuntu repository until I upgraded to 1.28 by building from source. (I wanted the /tree feature.) ___ 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] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 14:37, Richard Hipp wrote: Candidate fix checked into trunk. I just installed [5d4400400a] and it still doesn't work, regardless of %2b or not %2b. (That *was* the query, quoth Hamlet after all.) I get a Document Not Found page back from Fossil, with the body section being No such document: test .txt Yes, just one space, despite the document being called test++.txt. Odd. ___ 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] FYI: doc URLs don't work with filenames that have + in their names
On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com wrote: Incidentally, I'm bothering with nginx proxying because the SCGI method seems to have broken in 1.28. It was working fine on my site with 1.27 from the Ubuntu repository until I upgraded to 1.28 by building from source. (I wanted the /tree feature.) This should work in trunk or when 1.29 comes out, as Richard fixed it post 1.28. ___ 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] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 17:10, Joe Prostko wrote:
On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
Incidentally, I'm bothering with nginx proxying because the SCGI
method seems to have broken in 1.28. It was working fine on my site
with 1.27 from the Ubuntu repository until I upgraded to 1.28 by
building from source. (I wanted the /tree feature.)
This should work in trunk or when 1.29 comes out, as Richard fixed it
post 1.28.
Confirmed. I'm back on SCGI now. Thanks!
(And yes, /code/doc/trunk/test%2b%2b.txt pulls my test file now, even
with nginx in the way.)
I'm still willing to help debug the nginx HTTP proxy case, though.
While on the topic, the SCGI discussion on this page:
http://www.fossil-scm.org/index.html/doc/tip/www/server.wiki
would be better with two changes:
1. You don't need to do regex matching on the URL here. This does the
same thing more efficiently and more clearly:
location /demo_project/ {
nginx does prefix matching by default. Using regex matching (~) just to
pin the match to the start of the path with ^ adds nothing.
(Ref: http://nginx.org/en/docs/http/ngx_http_core_module.html#location)
2. In addition to adding --scgi, the page should also recommend that you
add --localhost. If you're going to proxy fossil server via
nginx+SCGI, you probably don't want to have a public listener that lets
someone bypass nginx.
___
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] FYI: doc URLs don't work with filenames that have + in their names
Is the documentation better now?
http://www.fossil-scm.org/fossil/doc/trunk/www/server.wiki#scgi
Thanks for testing out SCGI for us.
On Tue, May 27, 2014 at 7:31 PM, Warren Young war...@etr-usa.com wrote:
On 5/27/2014 17:10, Joe Prostko wrote:
On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
Incidentally, I'm bothering with nginx proxying because the SCGI
method seems to have broken in 1.28. It was working fine on my site
with 1.27 from the Ubuntu repository until I upgraded to 1.28 by
building from source. (I wanted the /tree feature.)
This should work in trunk or when 1.29 comes out, as Richard fixed it
post 1.28.
Confirmed. I'm back on SCGI now. Thanks!
(And yes, /code/doc/trunk/test%2b%2b.txt pulls my test file now, even with
nginx in the way.)
I'm still willing to help debug the nginx HTTP proxy case, though.
While on the topic, the SCGI discussion on this page:
http://www.fossil-scm.org/index.html/doc/tip/www/server.wiki
would be better with two changes:
1. You don't need to do regex matching on the URL here. This does the
same thing more efficiently and more clearly:
location /demo_project/ {
nginx does prefix matching by default. Using regex matching (~) just to
pin the match to the start of the path with ^ adds nothing.
(Ref: http://nginx.org/en/docs/http/ngx_http_core_module.html#location)
2. In addition to adding --scgi, the page should also recommend that you
add --localhost. If you're going to proxy fossil server via nginx+SCGI,
you probably don't want to have a public listener that lets someone bypass
nginx.
___
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] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 17:41, Richard Hipp wrote: Is the documentation better now? Yes, thanks! ___ 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] FYI: doc URLs don't work with filenames that have + in their names
On 5/27/2014 17:48, Warren Young wrote: On 5/27/2014 17:41, Richard Hipp wrote: Is the documentation better now? Yes, thanks! Ooops, grammar bug: Add one might want... Do you mean Additionally, ...? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] git export bug, and fix.
Using the fossil head, i.e. This is fossil version 1.29 [5d4400400a] 2014-05-27 20:36:33 UTC for a git export on my clone of http://core.tcl.tk/akupries/fx/home I.e. fossil export --git DUMP the resulting DUMP contains lines of the form: % grep -n ^committer DUMP| head 229901:committer Andreas Kupries akupr...@shaw.ca 1367645581 + [...] Note the lone between the user name and the email address in its own The git fast_import chokes on that. Looking at my 'info' the data looks ok, i.e % fx user list Checkout @ /home/aku/Projects/Tools/Fossil2Git/source.fossil +-+-++--++ | Name| Permissions | Contact| Changed | Notes | +-+-++--++ | aku | s | Andreas Kupries akupr...@shaw.ca | Wed Apr 23 22:59:44 PDT 2014 || [...] A quick look at static void print_person(const char *zUser) in fossil/src/export.c which I believe is most likely responsible for the broken output, did not show anything obvious. However the code looks to be a bit complex with searching for , , etc. I suspect I have to single-step it to understand what is going on. ... Looking a bit more I now suspect the line zName = mprintf(%.*s, i, zContact); because if I read the previous search right the i points to the opening of the mail at that point, making it part of the extracted zName. Yes, changing this to i-1 gets rid of the bogus in the output and git fast_import accepts the DUMP file. Notes: * I have no desire to bisect the repository to see where the issue came in ... ... Oh, ok, it seems to have been part of the initial implementation of the git export in 2011. http://www.fossil-scm.org/index.html/info/0f024d3e30741af3403c1c87ee5d689741e5a63c It seems to trigger only for users which have email addresses in their contact info. * The code should possibly trim trailing whitespace from the extracted name. With my small fix there is a trailing space in the name which is placed into the output as well, leading to two spaces between name and email. The fast_import is ok with that, it just offends my tastes re data formatting. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ 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] FYI: doc URLs don't work with filenames that have + in their names
Thus said Richard Hipp on Tue, 27 May 2014 16:37:01 -0400: Candidate fix checked into trunk. Works here, and much nicer than what I suggested: Before: $ printf 'GET /doc/tip/test/test-page%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/test/test-page++.wiki; / After: $ printf 'GET /doc/tip/test/test-page%%2b%%2b.wiki HTTP/1.1\r\nHost: localhost:8080\r\n\r\n' | nc localhost 8080 | grep base base href=http://localhost:8080/doc/tip/test/test-page%2B%2B.wiki; / Andy -- TAI64 timestamp: 400053852743 ___ 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] git export bug, and fix.
Are you planning to check your changes in? On Tue, May 27, 2014 at 7:55 PM, Andreas Kupries andre...@activestate.comwrote: Using the fossil head, i.e. This is fossil version 1.29 [5d4400400a] 2014-05-27 20:36:33 UTC for a git export on my clone of http://core.tcl.tk/akupries/fx/home I.e. fossil export --git DUMP the resulting DUMP contains lines of the form: % grep -n ^committer DUMP| head 229901:committer Andreas Kupries akupr...@shaw.ca 1367645581 + [...] Note the lone between the user name and the email address in its own The git fast_import chokes on that. Looking at my 'info' the data looks ok, i.e % fx user list Checkout @ /home/aku/Projects/Tools/Fossil2Git/source.fossil +-+-++--++ | Name| Permissions | Contact| Changed | Notes | +-+-++--++ | aku | s | Andreas Kupries akupr...@shaw.ca | Wed Apr 23 22:59:44 PDT 2014 || [...] A quick look at static void print_person(const char *zUser) in fossil/src/export.c which I believe is most likely responsible for the broken output, did not show anything obvious. However the code looks to be a bit complex with searching for , , etc. I suspect I have to single-step it to understand what is going on. ... Looking a bit more I now suspect the line zName = mprintf(%.*s, i, zContact); because if I read the previous search right the i points to the opening of the mail at that point, making it part of the extracted zName. Yes, changing this to i-1 gets rid of the bogus in the output and git fast_import accepts the DUMP file. Notes: * I have no desire to bisect the repository to see where the issue came in ... ... Oh, ok, it seems to have been part of the initial implementation of the git export in 2011. http://www.fossil-scm.org/index.html/info/0f024d3e30741af3403c1c87ee5d689741e5a63c It seems to trigger only for users which have email addresses in their contact info. * The code should possibly trim trailing whitespace from the extracted name. With my small fix there is a trailing space in the name which is placed into the output as well, leading to two spaces between name and email. The fast_import is ok with that, it just offends my tastes re data formatting. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ 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] git export bug, and fix.
I can do that. Note that I am about to go home and would do the commit after my arrival there, which should be in about 2 hours (*). (*) Normally 1/2 hour, however nowadays I try to walk a bit longer for exercise. On Tue, May 27, 2014 at 5:20 PM, Richard Hipp d...@sqlite.org wrote: Are you planning to check your changes in? On Tue, May 27, 2014 at 7:55 PM, Andreas Kupries andre...@activestate.com wrote: Using the fossil head, i.e. This is fossil version 1.29 [5d4400400a] 2014-05-27 20:36:33 UTC for a git export on my clone of http://core.tcl.tk/akupries/fx/home I.e. fossil export --git DUMP the resulting DUMP contains lines of the form: % grep -n ^committer DUMP| head 229901:committer Andreas Kupries akupr...@shaw.ca 1367645581 + [...] Note the lone between the user name and the email address in its own The git fast_import chokes on that. Looking at my 'info' the data looks ok, i.e % fx user list Checkout @ /home/aku/Projects/Tools/Fossil2Git/source.fossil +-+-++--++ | Name| Permissions | Contact| Changed | Notes | +-+-++--++ | aku | s | Andreas Kupries akupr...@shaw.ca | Wed Apr 23 22:59:44 PDT 2014 || [...] A quick look at static void print_person(const char *zUser) in fossil/src/export.c which I believe is most likely responsible for the broken output, did not show anything obvious. However the code looks to be a bit complex with searching for , , etc. I suspect I have to single-step it to understand what is going on. ... Looking a bit more I now suspect the line zName = mprintf(%.*s, i, zContact); because if I read the previous search right the i points to the opening of the mail at that point, making it part of the extracted zName. Yes, changing this to i-1 gets rid of the bogus in the output and git fast_import accepts the DUMP file. Notes: * I have no desire to bisect the repository to see where the issue came in ... ... Oh, ok, it seems to have been part of the initial implementation of the git export in 2011. http://www.fossil-scm.org/index.html/info/0f024d3e30741af3403c1c87ee5d689741e5a63c It seems to trigger only for users which have email addresses in their contact info. * The code should possibly trim trailing whitespace from the extracted name. With my small fix there is a trailing space in the name which is placed into the output as well, leading to two spaces between name and email. The fast_import is ok with that, it just offends my tastes re data formatting. -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ 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 -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ 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] git export bug, and fix.
On Tue, May 27, 2014 at 8:26 PM, Andreas Kupries andre...@activestate.comwrote: I can do that. Note that I am about to go home and would do the commit after my arrival there, which should be in about 2 hours (*). We await your fix. -- 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] git export bug, and fix.
Ok. On Tue, May 27, 2014 at 5:28 PM, Richard Hipp d...@sqlite.org wrote: On Tue, May 27, 2014 at 8:26 PM, Andreas Kupries andre...@activestate.com wrote: I can do that. Note that I am about to go home and would do the commit after my arrival there, which should be in about 2 hours (*). We await your fix. -- 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 -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster™ F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ Send mail to tclconfere...@googlegroups.com, by Sep 8 Registration is open. ___ 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] FYI: doc URLs don't work with filenames that have + in their names
On Tue, May 27, 2014 at 11:31 PM, Warren Young war...@etr-usa.com wrote:
On 5/27/2014 17:10, Joe Prostko wrote:
On May 27, 2014 6:58 PM, Warren Young war...@etr-usa.com
mailto:war...@etr-usa.com wrote:
Incidentally, I'm bothering with nginx proxying because the SCGI
method seems to have broken in 1.28. It was working fine on my site
with 1.27 from the Ubuntu repository until I upgraded to 1.28 by
building from source. (I wanted the /tree feature.)
This should work in trunk or when 1.29 comes out, as Richard fixed it
post 1.28.
Confirmed. I'm back on SCGI now. Thanks!
No problem! I reported it some time back, and Richard committed the fix.
1. You don't need to do regex matching on the URL here. This does the same
thing more efficiently and more clearly:
location /demo_project/ {
nginx does prefix matching by default. Using regex matching (~) just to pin
the match to the start of the path with ^ adds nothing.
I always write this as:
location ~ ^/demo_project {
myself. That way, it's a case-sensitive search where I don't have to
worry about the trailing slash, and it stops searching once it finds
/demo_project. I could be mistaken though, but I thought the way you
suggested wouldn't be as flexible.
I guess I'd have to test it to be sure, as anything resembling regex
is kind of like black magic to me. ;)
- joe
___
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] FYI: doc URLs don't work with filenames that have + in their names
Richard Hipp wrote: I think that's an HTTP thing. In a URL, spaces are encoded as +. So fossil is doing the right thing in converting + characters in the URL into spaces. If the filename really does contain + symbols, then the URL should have %2b for each plus. ex: http://localhost/doc/trunk/README-Visual-C%2b%2b.txt It's really an HTML form thing [1] that only applies to the query portion of the URL. In the path component, we technically should be percent-encoding spaces and leaving any instances of + alone, which would then allow you to reference such files normally. That's a much more involved fix that offers very little value, though. Just file this under the more you know. [1] http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1 ___ 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] FYI: doc URLs don't work with filenames that have + in their names
Thus said Joel Bruick on Tue, 27 May 2014 21:55:06 -0400: It's really an HTML form thing [1] that only applies to the query portion of the URL. In the path component, we technically should be percent-encoding spaces and leaving any instances of + alone, which would then allow you to reference such files normally. Does the specification for URIs apply in this case? http://tools.ietf.org/html/rfc3986 If I read the RFC correctly, it seems that 0x2b (+) is allowed in a URI as a sub-delim character unless it conflicts: sub-delims= ! / $ / / ' / ( / ) / * / + / , / ; / = Section 2.2: ... If data for a URI component would conflict with a reserved character's purpose as a delimiter, then the conflicting data must be percent-encoded before the URI is formed. ... The purpose of reserved characters is to provide a set of delimiting characters that are distinguishable from other data within a URI. URIs that differ in the replacement of a reserved character with its corresponding percent-encoded octet are not equivalent. Not sure if this helps ore muddies the implementation. :-) Andy -- TAI64 timestamp: 4000538555eb ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
