Re: [fossil-users] Support for Zscaler proxy...
Update: fossil does work through the proxy. Problem seems to be with the proxy, it gives 'bad request' error when user@ is added to URL in POST method. I'll work with IT folks for fixing it. - Original Message - From: altufa...@mail.com Sent: 05/15/12 03:57 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Support for Zscaler proxy... It seems fossil sends POST method to proxy server (I tried fossil pull ...). I tested git through proxy (socat - proxy:wwwproxy:$1:$2,proxyport=80) and it works, using CONNECT method. I'll look at ssl code to see if non-ssl can also use CONNECT method. - Original Message - From: Gé Weijers Sent: 05/14/12 11:31 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Support for Zscaler proxy... Connecting to an HTTPS server through a proxy uses the connect method, if your IT dept. even bothers to route HTTPS through Zscaler. -- Gé ___ 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] Support for Zscaler proxy...
Be aware that fossil uses cgi mode, even when in standalone server mode, and that cgi does not support all request types (e.g. PUT and DELETE iirc). - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal On May 15, 2012 12:28 PM, altufa...@mail.com wrote: It seems fossil sends POST method to proxy server (I tried fossil pull ...). I tested git through proxy (socat - proxy:wwwproxy:$1:$2,proxyport=80) and it works, using CONNECT method. I'll look at ssl code to see if non-ssl can also use CONNECT method. - Original Message - From: Gé Weijers Sent: 05/14/12 11:31 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Support for Zscaler proxy... Connecting to an HTTPS server through a proxy uses the connect method, if your IT dept. even bothers to route HTTPS through Zscaler. -- Gé ___ 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] Announcement: DRH to be in Munich, Germany July 3rd, 2012
On Tue, May 15, 2012 at 06:20:28PM +0200, Stephan Beal wrote: 1.5) If you happen to know of a *flat-rate* mobile internet provider in Germany, please let me know! BILD.mobil might be the best option. They have pre-paid data cards for around 7EUR / week, 1GB high speed. You might need someone in .de to buy it for you though. Joerg ___ 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] Announcement: DRH to be in Munich, Germany July 3rd, 2012
On Tue, May 15, 2012 at 7:34 PM, Joerg Sonnenberger jo...@britannica.bec.de wrote: On Tue, May 15, 2012 at 06:20:28PM +0200, Stephan Beal wrote: 1.5) If you happen to know of a *flat-rate* mobile internet provider in Germany, please let me know! BILD.mobil might be the best option. They have pre-paid data cards for around 7EUR / week, 1GB high speed. You might need someone in .de to buy it for you though. Thank you, Joerg! @All: If any of you are interested in that option for purposes of Richard's visit, but do not live in Germany, contact me off-list and we can get you set up (i live in Munich). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil commands will not follow through managed symlink dirs
Hi all, Please consider the following test (in Linux on version 1.22): % mkdir dir_a % ln -s dir_a dir_b % touch dir_a/foo % fossil add dir_a/foo ADDED dir_a/foo % fossil commit dir_a/foo -m 'adding test' ADDED dir_a/foo ... % fossil ann dir_a/foo % fossil ann dir_b/foo fossil: no such file: dir_b/foo I realize that fossil probably only responds to the real managed path in dir_a. But this situation may be confusing... thanks James ___ 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 commands will not follow through managed symlink dirs
On Tue, May 15, 2012 at 7:51 PM, James Masters james.d.mast...@gmail.comwrote: Hi all, Please consider the following test (in Linux on version 1.22): % ln -s dir_a dir_b ... % fossil ann dir_a/foo % fossil ann dir_b/foo fossil: no such file: dir_b/foo I realize that fossil probably only responds to the real managed path in dir_a. But this situation may be confusing... Fossil only knows anything useful about added-and-checked-in files, and the name dir_b/foo does not refer to a file it knows. Whether fossil _should_ or _can_ resolve symlinks that way is a question we must wait for Richard to answer, i suspect. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil commands will not follow through managed symlink dirs
On Tue, May 15, 2012 at 1:51 PM, James Masters james.d.mast...@gmail.comwrote: Hi all, Please consider the following test (in Linux on version 1.22): % mkdir dir_a % ln -s dir_a dir_b % touch dir_a/foo % fossil add dir_a/foo ADDED dir_a/foo % fossil commit dir_a/foo -m 'adding test' ADDED dir_a/foo ... % fossil ann dir_a/foo % fossil ann dir_b/foo fossil: no such file: dir_b/foo I realize that fossil probably only responds to the real managed path in dir_a. But this situation may be confusing... I'm not following the confusion here. Fossil can only annotate files that have been checked in and have history. You've never before checked in dir_b/foo. It is random file that Fossil knows nothing about. It says as much when you ask to annotate it. How can one make this less confusing? thanks James ___ 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] Fossil commands will not follow through managed symlink dirs
On Tue, May 15, 2012 at 8:00 PM, Richard Hipp d...@sqlite.org wrote: % ln -s dir_a dir_b I'm not following the confusion here. Fossil can only annotate files that have been checked in and have history. You've never before checked in dir_b/foo. It is The key part is the symlink and whether fossil should/could resolve dir_b/foo to dir_a/foo. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil commands will not follow through managed symlink dirs
Accidentally replied off-list... On Tue, May 15, 2012 at 7:56 PM, Stephan Beal sgb...@googlemail.com wrote: dir_b/foo does not refer to a file it knows. Whether fossil _should_ or _can_ resolve symlinks that way is a question we must wait for Richard to answer, i suspect. And i meant to add... Whether or not fossil could/should do this for symlinks is 100% up to Richard because: a) it's potentially a backwards-compatibility issue, which he does not like at all. b) it's a platform-specific behaviour, which we try to minimize because it's harder to test (he and i both work under some flavour of Unix, as do most (but not all) other contributors). c) there is no right/wrong answer. i.e., it's a largely a philosophical question, and those tend to trouble us because there is no provably correct answer ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil commands will not follow through managed symlink dirs
This will probably start a new thread... if so, then sorry... I have digest mode enabled and it is not clear to me how to reply directly to a particular thread when using the digest. Anyway, my response is below: Message: 6 Date: Tue, 15 May 2012 14:00:43 -0400 From: Richard Hipp d...@sqlite.org To: Fossil SCM user's discussion fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Fossil commands will not follow through managed symlink dirs Message-ID: CALwJ=mx5evcmlyehfv_42uzrugd-cfypasfzwoi3putz5nr...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Tue, May 15, 2012 at 1:51 PM, James Masters james.d.mast...@gmail.com wrote: Hi all, Please consider the following test (in Linux on version 1.22): % mkdir dir_a % ln -s dir_a dir_b % touch dir_a/foo % fossil add dir_a/foo ADDED dir_a/foo % fossil commit dir_a/foo -m 'adding test' ADDED dir_a/foo ... % fossil ann dir_a/foo % fossil ann dir_b/foo fossil: no such file: dir_b/foo I realize that fossil probably only responds to the real managed path in dir_a. But this situation may be confusing... I'm not following the confusion here. Fossil can only annotate files that have been checked in and have history. You've never before checked in dir_b/foo. It is random file that Fossil knows nothing about. It says as much when you ask to annotate it. How can one make this less confusing? Sorry, I missed the crucial step of adding and comitting dir_b as a symlink. Please append this to my example above: % fsl add dir_b ADDED dir_b % fsl commit dir_b -m 'adding symlink' ADDED dir_b ... % fsl ann dir_b/foo fossil: no such file: dir_b/foo The confusion is that dir_b is a symlink to dir_a and when I follow that symlink for normal file operations, it operates upon the file as if it were a normal dir/file at the OS level. But not with fossil. I'm just bringing this up as it caused a bit of confusion for me until I probed deeper and found this out. BTW, the first example, is probably still something that may also be considered to be addressed. thanks James ___ 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 commands will not follow through managed symlink dirs
On 5/15/12, James Masters james.d.mast...@gmail.com wrote: Sorry, I missed the crucial step of adding and comitting dir_b as a symlink. Please append this to my example above: % fsl add dir_b ADDED dir_b % fsl commit dir_b -m 'adding symlink' ADDED dir_b ... % fsl ann dir_b/foo fossil: no such file: dir_b/foo The confusion is that dir_b is a symlink to dir_a and when I follow that symlink for normal file operations, it operates upon the file as if it were a normal dir/file at the OS level. But not with fossil. To most applications, dir_a/foo and dir_b/foo are 2 seperate files. In Unix derived OSes, symbolic links are designed to be transparant to applications that are ignorant of sym links. You might argue that Fossil has a need to be aware of sym links, else you end up with 2 (or more) of the same file under different names (where name == the full path), but there are more complications. Even if sym links worked exactly the same in all OSes, how to treat any given sym link is an open question subject to a lot of debate. For me, sym links would be a way to reference the working copy of a shared subproject in a project's working copy. While SVN's way of handling external references works, in my experience, it is too easy to end up with multiple working copies of the same shared project, so even with that usage model, there are complications. ___ 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] Trac-to-Fossil Was: Wysiwyg wiki editing. Was: Side-by-side wiki editing?
On 15 May 2012 03:01, Ron Wilson ronw.m...@gmail.com wrote: I would guess that Trac stores its wiki pages in version control, so the main issue there would be Trac wiki markup vs Fossil (or other) wiki markup. If there is a client side renderer for Trac's markup, markup conversion would not be an issue. They are likely other issues, though. Trac's versioning for wiki and issues is native to Trac, and is used solely for the wiki and issues. The version control of the source for a project is entirely separate. I have no idea how Trac manages issues nor if there is a plug-in interface for issues. If it simply stores the issues as files in version control, then maybe the plug-in could recognise issues based on file extension or other pattern match, then provide Fossil specific handling. Trac does not use your source control choice for issues or wiki. -- Christopher Vance ___ 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] Trac-to-Fossil Was: Wysiwyg wiki editing. Was: Side-by-side wiki editing?
On 15 May 2012 03:01, Ron Wilson ronw.m...@gmail.com wrote: Trac's versioning for wiki and issues is native to Trac, and is used solely for the wiki and issues. The version control of the source for a project is entirely separate. Trac does not use your source control choice for issues or wiki. Though as I recall, the (default at least) database is SQLite. :) ___ 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] Trac-to-Fossil Was: Wysiwyg wiki editing. Was: Side-by-side wiki editing?
On Tue, May 15, 2012 at 10:23 PM, Scott Robison sc...@scottrobison.uswrote: On 15 May 2012 03:01, Ron Wilson ronw.m...@gmail.com wrote: Trac's versioning for wiki and issues is native to Trac, and is used solely for the wiki and issues. The version control of the source for a project is entirely separate. Trac does not use your source control choice for issues or wiki. Though as I recall, the (default at least) database is SQLite. :) The connections run much deeper. See http://trac.edgewall.org/wiki/TracHistory for a brief history of Trac. Never heard of CVSTrac? Try using ping to find the IP address of www.cvstrac.org. Now do the same with www.sqlite.org and www.fossil-scm.org. ___ 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
