Re: [fossil-users] Hello. Anyone for source highlighting?
Am Donnerstag 16 Dezember 2010, 15:37:00 schrieb pablo veliz: > Since we are using a browser to see the code, why not use a client side > library for syntax-highlighting like http://codemirror.net/ ? That way > works in any platform, and can be extended for different languages. > > -Original Message- > From: fossil-users-boun...@lists.fossil-scm.org > [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Martin > Sandiford Sent: Monday, December 13, 2010 7:11 PM > To: fossil-users@lists.fossil-scm.org > Subject: Re: [fossil-users] Hello. Anyone for source highlighting? > > I'm in favor. Not really sure what I need to do to help this to happen? > > Code review anyone? > > Martin > This is already documented on the fossil wiki. See the Cookbook page. Rüdiger ___ 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] basic questions about fossil
On Thu, 16 Dec 2010 19:59:14 -0800 >> "Russ" == Russ Paielli wrote: Russ> Here's another suggestion for comments. The idea of launching an Russ> editor seems excessive to me. When I'm working remotely, it Russ> sometimes takes half a minute or so for the editor to come up. If Russ> the user neglects to enter a "-m" comment, why not issue a query Russ> such as, "Do you wish to enter a comment? [yN]: > fossil ci -m "" empty check-in comment. continue (y/N)? y Russ> Is that reasonable? Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: CDBF17CA signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Hello. Anyone for source highlighting?
This is interesting. Where can I get consolidated recipe? - Altu -Original Message- From: Volodya Savastiouk, MSC To: fossil-users@lists.fossil-scm.org Sent: Fri, Dec 17, 2010 12:13 am Subject: Re: [fossil-users] Hello. Anyone for source highlighting? Hi, I did mentioned it here a few days back, the source highlighting canwork with *no* changes to Fossil. I have it working for me on chiselapp.com. What will be great is if the html output can be configured to have more classes/div/id to be used in CSS. I'm not sure if it's ok to send a small screenshot here, but I'll try anyway. Here's how I see diif: Cheers, Volodya ___fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://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] Hello. Anyone for source highlighting?
+1 -Original Message- From: pablo veliz To: fossil-users@lists.fossil-scm.org Sent: Thu, Dec 16, 2010 8:07 pm Subject: Re: [fossil-users] Hello. Anyone for source highlighting? Since we are using a browser to see the code, why not use a client side library for syntax-highlighting like http://codemirror.net/ ?That way works in any platform, and can be extended for different languages.-Original Message-From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Martin SandifordSent: Monday, December 13, 2010 7:11 PMTo: fossil-us...@lists.fossil-scm.orgsubject: Re: [fossil-users] Hello. Anyone for source highlighting?I'm in favor. Not really sure what I need to do to help this to happen?Code review anyone?MartinOn 07/12/2010, at 8:40 PM, Gour wrote:> On Mon, 8 Nov 2010 21:51:19 +1030>>> "Martin" == Martin Sandiford wrote:>> Martin> Changes are on the "experimental" branch. It's been tested> Martin> reasonably well on MacOSX and Linux. I've implemented a Win32> Martin> version as well, but this has really only had basic testing.>> Is there any chance that it ends applied to the upstream?>>> Sincerely,> Gour>> -- >> Gour | Hlapicina, Croatia | GPG key: CDBF17CA> > ___> 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 listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi -bin/mailman/listinfo/fossil-users___ fossil-users mailing listfossil-us...@lists.fossil-scm.orghttp://lists.fossil-scm.org:8080/cgi -bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Template repositories
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have some situations where I find myself creating the same starter projects over and over. For instance, I'll create the same starter web app with similar database setup and coding style. Were I doing this with Git, I'd start with a template repository, clone it and go. But I'm not sure this is possible with Fossil. My understanding is that Fossil creates a unique project ID such that it ensures syncs happen only between repositories of the same project. Is this accurate? If so, I wonder if a variant of "fossil new" might accept a second repository file or URL argument. This would copy all artifacts from the second repository into the first, then set a new project ID on the first repository. This would ensure that each new project has a distinct ID from the template, but still starts with the same artifacts. Or is there some other way to accomplish this goal? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0K8AwACgkQIaMjFWMehWKbdACfZL2dpYkdcExmsBrq2COB/rDC uScAn1jwlg8weJmPAd5jjPKTE3dh4Pid =pyMJ -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] basic questions about fossil
Here's another suggestion for comments. The idea of launching an editor seems excessive to me. When I'm working remotely, it sometimes takes half a minute or so for the editor to come up. If the user neglects to enter a "-m" comment, why not issue a query such as, "Do you wish to enter a comment? [yN]: " If the reply is yes, then accept a comment from the command line, terminating with a newline or Control-D (and explain in advance how to terminate the comment). Is that reasonable? Thanks. Russ P. -- http://RussP.us ___ 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] basic questions about fossil
On Thu, Dec 16, 2010 at 3:24 AM, Rene wrote: > On Wed, 15 Dec 2010 18:44:46 -0800, Russ Paielli > wrote: > > > I downloaded fossil and gave it a try on my Linux machine. The first > > time I tried to add files, I got stuck in some mode that I could not > > get out of. Apparently, my EDITOR environment variable was not set, > > and I was supposed to give a comment. Fossil was showing a question > > mark, but I did not know what it wanted, and not even Control-C would > > get me out. I ended up killing the terminal and deleting the > > repository I had just created in case it was corrupted. How was I > > supposed to respond to the question mark? > You were put in ed The standard and always present editor in UN*X's. > q for quit would be the appropriated response. > > Thanks. Do you have any idea how frustrating it is to get stuck like that within the first five minutes of trying a new program? I'd like to make a suggestion. Instead of just randomly dumping the user into an editor that he may have never even heard of, I suggest that, if the editor is not specified, the user should be explicitly prompted for which editor to use. The user response could then be automatically stored in the fossil editor setting for future use (with a mention that this is being done, along with a brief statement of how to change it in the future if desired). That would have saved me some head scratching. > instead of setting the EDITOR variable you could do > fossil settings editor PutYourFavoriteEditorHere -global > > > > > By the way, why do these version control systems insist on a comment? > > Yes, I understand that commenting is good practice, but does that mean > > it should be mandatory and the version control system should force me > > to write one? I tend to think not. > Because when you alter software you have an intent. > It is either correcting a bug, adding features, building. > These commits show the intent why you altered the software. So just the > comment will give you an idea what the intent of the source code change > are. Which will be beneficial 2 months later when you try to remember > which commit contains the change you made. > > I realize all that. But what if I'm working independently, and I just want to be able to retrieve a working version if I screw something up. I'm not suggesting that I work that way now, but I have in the past, and I didn't consider it worth my time to write comments when the chances are small that I will never look at them anyway. It's not a major issue, but it just seems to me that I should be able to commit without having to write a comment -- even an empty comment to satisfy the program. By the way, here's another little thing I got stuck on. I ran "fossil ui", and the webpage that was generated is very nice. However, the ui command did not return (even after I closed the webpage). I ended up using Control-C to get a prompt back. Sorry if this is a dumb question, but how do I get the ui command to return normally? Thanks. Russ P. -- http://RussP.us ___ 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] Hello. Anyone for source highlighting?
Hi, I did mentioned it here a few days back, the source highlighting can work with *no* changes to Fossil. I have it working for me on chiselapp.com. What will be great is if the html output can be configured to have more classes/div/id to be used in CSS. I'm not sure if it's ok to send a small screenshot here, but I'll try anyway. Here's how I see diif: Cheers, Volodya ___ 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] Merge conflict notation
I also agree that words: "original content" and "conflict" are very clear for a person who understands very well the merge algorithm. However, they might be not so clear for a casual user. People would understand better something like: "local checkout" "files from repository" or something similar RR 2010/12/16 Remigiusz Modrzejewski : > > On Dec 16, 2010, at 16:11 , Richard Hipp wrote: > >> I really do not want to make merge-conflict marks configurable. Aren't >> there enough configuration options in Fossil already? Do we really need the >> extra complication. > > I hope not. > >> >> As of a check-in a did moments ago, the conflict marks now look like this: >> >> <<< BEGIN MERGE CONFLICT: original content first <<< >> === original content above; conflict below = > END MERGE CONFLICT: conflict last >> >> >> These marks do not contain the "version number" of the check-in or file for >> the two versions of the text. But on the other hand, I do not find such >> information particularly useful. Calling the two versions "original" and >> "conflict" works much, much better for me. With that notation, I clearly >> see what the code said before the merge, and what the merge wanted to change >> it into. > > > You mean the original version from the trunk that my edits conflicted with? > Things may not be so clear. I would at least try to fit into there some word > suggesting that the original is "YOUR" version. > >> With version numbers, I have to mentally translate the version >> numbers into "original" and "conflict", which involves extra work. I could >> understand wanting version numbers if conflict marks were something that >> might persist, but the idea is that conflicts are resolved quickly and never >> persist. > > Good point. > > > Kind regards, > Remigiusz Modrzejewski > > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merge conflict notation
On Dec 16, 2010, at 16:11 , Richard Hipp wrote: > I really do not want to make merge-conflict marks configurable. Aren't > there enough configuration options in Fossil already? Do we really need the > extra complication. I hope not. > > As of a check-in a did moments ago, the conflict marks now look like this: > ><<< BEGIN MERGE CONFLICT: original content first <<< >=== original content above; conflict below = END MERGE CONFLICT: conflict last >> > > These marks do not contain the "version number" of the check-in or file for > the two versions of the text. But on the other hand, I do not find such > information particularly useful. Calling the two versions "original" and > "conflict" works much, much better for me. With that notation, I clearly > see what the code said before the merge, and what the merge wanted to change > it into. You mean the original version from the trunk that my edits conflicted with? Things may not be so clear. I would at least try to fit into there some word suggesting that the original is "YOUR" version. > With version numbers, I have to mentally translate the version > numbers into "original" and "conflict", which involves extra work. I could > understand wanting version numbers if conflict marks were something that > might persist, but the idea is that conflicts are resolved quickly and never > persist. Good point. 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] basic questions about fossil
On Thu, Dec 16, 2010 at 9:43 AM, wrote: > > My understanding is that Fossil supports renames of files and > directories, but does not support merges that later use the deprecated > name. This is something of a race condition and might be a concern for > projects with lots of disparate contributors. My own experience is > that by the time a project garners lots of contributors, the basic > tree structure is fairly well sussed (and for few contributors lack of > this support is not that problematic). Nonetheless, providing support > for "intelligent renames" is on Fossil's TODO list. > Some support for "intelligent renames" was added two days ago. Merging and updating to renamed files does the right thing, mostly. There are even a few simple test cases to verify the correct operation of "intelligent renames". That said - I'm sure there are cases that will not work. For example, if you interchange two files (rename A to C, rename B to A, then rename C to B, thus swapping A and B) then things are less likely to work right. Fossil keeps around enough information so that it could, in theory, do the right thing there, but a lot of code is involved and that really is an extreme corner case, so it does not work yet. -- 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] Merge conflict notation
I really do not want to make merge-conflict marks configurable. Aren't there enough configuration options in Fossil already? Do we really need the extra complication. As of a check-in a did moments ago, the conflict marks now look like this: <<< BEGIN MERGE CONFLICT: original content first <<< === original content above; conflict below = >>> END MERGE CONFLICT: conflict last >> These marks do not contain the "version number" of the check-in or file for the two versions of the text. But on the other hand, I do not find such information particularly useful. Calling the two versions "original" and "conflict" works much, much better for me. With that notation, I clearly see what the code said before the merge, and what the merge wanted to change it into. With version numbers, I have to mentally translate the version numbers into "original" and "conflict", which involves extra work. I could understand wanting version numbers if conflict marks were something that might persist, but the idea is that conflicts are resolved quickly and never persist. Who has counter-arguments? -- 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] Hello. Anyone for source highlighting?
I'm interested in this idea. And I thought to try develop "new default" skin for fossil in fancy web 2.0 style and with syntax highlighting, however I was considering http://alexgorbatchev.com/SyntaxHighlighter/ If you're interested, we can discuss our next steps. -- @macacq On Thu, Dec 16, 2010 at 4:37 PM, pablo veliz wrote: > Since we are using a browser to see the code, why not use a client side > library for syntax-highlighting like http://codemirror.net/ ? > That way works in any platform, and can be extended for different languages. > > -Original Message- > From: fossil-users-boun...@lists.fossil-scm.org > [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Martin > Sandiford > Sent: Monday, December 13, 2010 7:11 PM > To: fossil-users@lists.fossil-scm.org > Subject: Re: [fossil-users] Hello. Anyone for source highlighting? > > I'm in favor. Not really sure what I need to do to help this to happen? > > Code review anyone? > > Martin > > On 07/12/2010, at 8:40 PM, Gour wrote: > >> On Mon, 8 Nov 2010 21:51:19 +1030 "Martin" == Martin Sandiford wrote: >> >> Martin> Changes are on the "experimental" branch. It's been tested >> Martin> reasonably well on MacOSX and Linux. I've implemented a Win32 >> Martin> version as well, but this has really only had basic testing. >> >> Is there any chance that it ends applied to the upstream? >> >> >> Sincerely, >> Gour >> >> -- >> >> Gour | Hlapicina, Croatia | GPG key: CDBF17CA >> >> ___ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merge conflict notation
On Wed, 15 Dec 2010 15:17:29 + fossil-users-requ...@lists.fossil-scm.org wrote: > I'm inclined to go with the shorter one-line conflict marks. Other > thoughts from the user community? Love the idea to add context to the conflict lines. How about a compromise solution? Like: 0 1 2 3 <<< BEGIN CONFLICT 9617c665 "initial checkin" 444 >>> MID CONFLICT e332c6da "new branch checkin" <<< 999 >>> END CONFLICT 5 6 7 8 9 Not sure we need the exact text "BEGIN MERGE CONFLICT", since we already know that's what it is. And could we use the shorter version of the checkin identifier? Wouldn't that be sufficient? How about making the "mid-line" a bit more identifiable? Maybe put the second part of the conflict context there? Just some ideas there. Now please begin shooting. :P Regards, Adam J Richardson signature.asc Description: PGP signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Merge conflict notation
On Dec 15, 2010, at 22:10 , Joshua Paine wrote: > On 12/15/2010 04:00 PM, Zach Todd wrote: >> I have updated the merge conflict code as well as config setup to >> allow for configurable notation. > >> Doesn't this call for configurable notation? ;) >> Kind regards, Remigiusz Modrzejewski > > Maybe I missed it, but I sure thought Remigiusz was joking. I'm not sure. I just found the idea of adding another layer of complexity slightly amusing. But if we don't agree on what's the better idea, then actually configurable notation may be the way to go. 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] $baseurl question (reverse proxy issue)
On Thu, Dec 16, 2010 at 8:20 AM, Richard Hipp wrote: > > > On Thu, Dec 16, 2010 at 8:17 AM, Trou Macacq wrote: > >> 2) Should we consider using relative URLs instead of absolute? >> > > That sounds like it is the right solution. But it is a big change. It > will likely take a week or two to appear. > It turns out that switch to using relative rather than absolute URLs was a simple search-and-replace. I checked in the change there: http://www.fossil-scm.org/fossil/info/daeb10f65f - please give it a try and let me know if it works better for you. Please not that the absolute URL is still used for RSS feeds. (I don't know how to fix that.) If you have a customized header or footer, you'll want to change the $baseurl variable to $home. If you are using the default header and footer, this change will occur automatically. > > > -- > 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] basic questions about fossil
Quoting Russ Paielli : > ... At first I was interested in Git and BitKeeper. Then I discovered > Bazaar, and I was almost ready to start using it, but I decided to take one > more look at the options. When I saw fossil, I figured, with a name like > that, it's a real long shot, but I'll take a look anyway. ... You might be interested in visiting http://better-scm.berlios.de/comparison/comparison.html which is a website that provides a conspectus of the various source control management options currently available. > The Bazaar website claims that one advantage of Bazaar over Git is that it > properly handles renames of files and directories. That is important to me. > I'm very particular about filenames and directory structure, and I don't > want to feel that I am stuck with the first file name or directory structure > I chose because changing it will confuse my version control system (or > confuse the people using it). How does fossil compare to Bazaar in that > regard? My understanding is that Fossil supports renames of files and directories, but does not support merges that later use the deprecated name. This is something of a race condition and might be a concern for projects with lots of disparate contributors. My own experience is that by the time a project garners lots of contributors, the basic tree structure is fairly well sussed (and for few contributors lack of this support is not that problematic). Nonetheless, providing support for "intelligent renames" is on Fossil's TODO list. > By the way, why do these version control systems insist on a comment? Yes, I > understand that commenting is good practice, but does that mean it should be > mandatory and the version control system should force me to write one? I > tend to think not. Fossil doesn't actually mandate that you enter a comment -- but it is generally a good idea. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] $baseurl question (reverse proxy issue)
On Thu, Dec 16, 2010 at 04:22:42PM +0200, Trou Macacq wrote: > About fossil server... on production (not ad hoc) this means using > inetd daemon. And I might say something stupid, but I'm almost sure it > not installed on my Ubuntu server 10.10 by default. And I trying to > keep everything as standard as possible. Is this itetd setup really > better than CGI. Where I can find a list of advantages and > disadvantages of this approach? No, it doesn't mean inetd. You might want to use daemon for this purpose though. The primary different to using httpd+CGI is that this only requires a fork per request, not an exec. 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] Hello. Anyone for source highlighting?
Since we are using a browser to see the code, why not use a client side library for syntax-highlighting like http://codemirror.net/ ? That way works in any platform, and can be extended for different languages. -Original Message- From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Martin Sandiford Sent: Monday, December 13, 2010 7:11 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Hello. Anyone for source highlighting? I'm in favor. Not really sure what I need to do to help this to happen? Code review anyone? Martin On 07/12/2010, at 8:40 PM, Gour wrote: > On Mon, 8 Nov 2010 21:51:19 +1030 >>> "Martin" == Martin Sandiford wrote: > > Martin> Changes are on the "experimental" branch. It's been tested > Martin> reasonably well on MacOSX and Linux. I've implemented a Win32 > Martin> version as well, but this has really only had basic testing. > > Is there any chance that it ends applied to the upstream? > > > Sincerely, > Gour > > -- > > Gour | Hlapicina, Croatia | GPG key: CDBF17CA > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] $baseurl question (reverse proxy issue)
On Thu, Dec 16, 2010 at 8:22 AM, Trou Macacq wrote: > connected with HTTP_HOST env variable... And this env variable cannot > be changed either in CGI script using bash, or by using SetEnv > mod_rewreite directive. You'll want to do one of two things here: (1) You'll want to investigate how I'm passing requests back to Fossil in my configuration and take good note of the relevant line in /etc/hosts combined with the host I use in my mod_proxy directives, along with how I'm binding Fossil to a particular loopback address. (2) You'll want to investigate how to use proxy_set_header to set the Host header in nginx. Using SetEnv with mod_rewrite, if memory serves, requires the use of the passthrough flag on that particular rule. I wouldn't advise doing this since it just muddles up your configuration with mod_rewrite rules, which can become cumbersome and hard to deal with very quickly. > About fossil server... on production (not ad hoc) this means using > inetd daemon. And I might say something stupid, but I'm almost sure it > not installed on my Ubuntu server 10.10 by default. And I trying to > keep everything as standard as possible. Is this itetd setup really > better than CGI. Where I can find a list of advantages and > disadvantages of this approach? I was hinting more at the analogue between my configuration and yours. If you want to mimic it, that's fine, but you're already on a good path here. My setup was more an illustration how I solved the same problem in my environment. > Many thanks in advance! Hope this helps, -- Nathaniel R. Reindl ___ 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] $baseurl question (reverse proxy issue)
Hi I've tried to solve my issue by using Apache mod_env and mod_rewrite... I'm might be wrong but zBaseURL variable somehow connected with HTTP_HOST env variable... And this env variable cannot be changed either in CGI script using bash, or by using SetEnv mod_rewreite directive. About fossil server... on production (not ad hoc) this means using inetd daemon. And I might say something stupid, but I'm almost sure it not installed on my Ubuntu server 10.10 by default. And I trying to keep everything as standard as possible. Is this itetd setup really better than CGI. Where I can find a list of advantages and disadvantages of this approach? Many thanks in advance! -- @macacq On Thu, Dec 16, 2010 at 3:26 PM, Joerg Sonnenberger wrote: > On Thu, Dec 16, 2010 at 08:20:02AM -0500, Richard Hipp wrote: >> On Thu, Dec 16, 2010 at 8:17 AM, Trou Macacq wrote: >> >> > 2) Should we consider using relative URLs instead of absolute? >> > >> >> That sounds like it is the right solution. But it is a big change. It will >> likely take a week or two to appear. > > It also doesn't work if you want to redirect. I haven't checked, but > does fossil honour PATH_INFO? That's the correct approach for this and > the rest is a question of Apache configuration. > > BTW, I would suggest to not use CGI, but run the reverse proxy directly > on "fossil server". > > Joerg > ___ > 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] $baseurl question (reverse proxy issue)
On Thu, Dec 16, 2010 at 7:17 AM, Trou Macacq wrote:
> My setup look like this:
>
> ngnix reverse proxy, port 80 <-> apache daemon running fossil via CGI, port
> 8080
>
> And since fossil sets absolute URL to all resources embedded... the
> people outside have seem my repositories wiki, tickets, and other
> filled with links to localhost:8080
I have the feeling that my setup details might be useful to you.
Currently, I have this:
**
[...@bast-imret ~]$ cat /etc/hosts
127.0.0.1 localhost
127.0.0.101 fossil-corvidae.bast-imret.corvidae.org fossil.corvidae.org
[...@bast-imret ~]$ cat /etc/httpd/vhosts.d/fossil.corvidae.org.conf
ServerAdmin webmas...@corvidae.org
DocumentRoot /var/www/domains/corvidae.org/fossil/htdocs
RewriteEngine On
RewriteRule ^/$ /index.html [T=text/html]
#
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI
MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs/2.2/mod/core.html#options
# for more information.
#
Options Indexes FollowSymLinks
#
# AllowOverride controls what directives may be placed in .htaccess
files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None
#
# Controls who can get stuff from this server.
#
Order allow,deny
Allow from all
#
# ScriptAlias: This controls which directories contain server scripts.
# ScriptAliases are essentially the same as Aliases, except that
# documents in the realname directory are treated as applications and
# run by the server when requested rather than as documents sent to the
client.
# The same rules about trailing "/" apply to ScriptAlias directives as
to
# Alias.
#
ScriptAlias /cgi-bin/ "/var/www/domains/corvidae.org/fossil/cgi-bin/"
#
# "/var/www/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
AllowOverride None
Options None
Order allow,deny
Allow from all
ServerName fossil.corvidae.org
ErrorLog "|/usr/sbin/cronolog -l
/var/www/domains/corvidae.org/fossil/logs/error_log
/var/www/domains/corvidae.org/fossil/logs/%Y-%m/error_log-%Y-%m-%d"
CustomLog "|/usr/sbin/cronolog -l
/var/www/domains/corvidae.org/fossil/logs/access_log
/var/www/domains/corvidae.org/fossil/logs/%Y-%m/access_log-%Y-%m-%d"
combined
ProxyPass /cgi-bin !
ProxyPass / http://fossil.corvidae.org/
ProxyPassReverse /cgi-bin !
ProxyPassReverse / http://fossil.corvidae.org/
[...@bast-imret ~]$ cat /etc/xinetd.d/fossil-corvidae
service fossil-corvidae
{
socket_type = stream
type = UNLISTED
wait = no
disable = no
user = root
server = /opt/fossil/bin/fossil
server_args = http /opt/fossil/repositories/corvidae.org/fossil
--notfound http://fossil.corvidae.org/cgi-bin/fossil-list-repositories.cgi
bind = fossil-corvidae.bast-imret.corvidae.org
port = 80
}
**
Let me know if this gives you an idea as to how to accomplish what you
want. Granted, I'm not running Fossil as CGI, but it's kind of the
same arrangement as what you have now with nginx reverse proxying back
to Apache/mod_cgi.
Hope this helps,
--
Nathaniel R. Reindl
___
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] $baseurl question (reverse proxy issue)
On Thu, Dec 16, 2010 at 08:20:02AM -0500, Richard Hipp wrote: > On Thu, Dec 16, 2010 at 8:17 AM, Trou Macacq wrote: > > > 2) Should we consider using relative URLs instead of absolute? > > > > That sounds like it is the right solution. But it is a big change. It will > likely take a week or two to appear. It also doesn't work if you want to redirect. I haven't checked, but does fossil honour PATH_INFO? That's the correct approach for this and the rest is a question of Apache configuration. BTW, I would suggest to not use CGI, but run the reverse proxy directly on "fossil server". 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] $baseurl question (reverse proxy issue)
On Thu, Dec 16, 2010 at 8:17 AM, Trou Macacq wrote: > 2) Should we consider using relative URLs instead of absolute? > That sounds like it is the right solution. But it is a big change. It will likely take a week or two to appear. -- 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
[fossil-users] $baseurl question (reverse proxy issue)
Hi all! Thank you all for such a great tool as fossil! I've become big fan of the fossil SCM some time ago and past few days I spent finally moving fossil repositories to the production server (I need some sort of centralized hosting for all my stuff) and funny thing happened -- fossil let me down for the first time :) My setup look like this: ngnix reverse proxy, port 80 <-> apache daemon running fossil via CGI, port 8080 And since fossil sets absolute URL to all resources embedded... the people outside have seem my repositories wiki, tickets, and other filled with links to localhost:8080 I've looked in source code and found that it's a designed behavior of the fossil, and to make everything work for me I got to apply dirty hack cutting hostname and port number (as well protocol) from g.zBaseURL variable (and consequently from $baseurl variable used in html templates). The questions are: 1) Is there any other way around the setting up fossil behind reverse proxy without recompiling? 2) Should we consider using relative URLs instead of absolute? Isn't it a easier way of setting up fossil on the production environments? Many thanks in advance for your answers and for creating really useful tool! -- @macacq ___ 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] basic questions about fossil
On Wed, 15 Dec 2010 18:44:46 -0800, Russ Paielli wrote: > Hi Richard, > > I discovered fossil yesterday while reading the Wikipedia page that > compares version control systems. I read lots of the material on the > fossil website, and I must say that fossil looks very promising. > Congratulations on what appears to a great piece of software! > > I have very little experience with version control, but I'd like to > start using it more. I work in a Clearcase environment, but I don't > use Clearcase myself because I work relatively independently (I am an > aerospace research engineer who writes prototype software for research > in air traffic control). I recently started doing a little research on > the alternatives. I watched Linus Torvalds talk at Google, and he sold > me on distributed version control. At first I was interested in Git > and BitKeeper. Then I discovered Bazaar, and I was almost ready to > start using it, but I decided to take one more look at the options. > When I saw fossil, I figured, with a name like that, it's a real long > shot, but I'll take a look anyway. Sure enough, it looks impressive. I > just have a few questions. > > The Bazaar website claims that one advantage of Bazaar over Git is > that it properly handles renames of files and directories. That is > important to me. I'm very particular about filenames and directory > structure, and I don't want to feel that I am stuck with the first > file name or directory structure I chose because changing it will > confuse my version control system (or confuse the people using it). > How does fossil compare to Bazaar in that regard? While your at it, > I'd be interested to know how it compares to Bazaar in general. > > I downloaded fossil and gave it a try on my Linux machine. The first > time I tried to add files, I got stuck in some mode that I could not > get out of. Apparently, my EDITOR environment variable was not set, > and I was supposed to give a comment. Fossil was showing a question > mark, but I did not know what it wanted, and not even Control-C would > get me out. I ended up killing the terminal and deleting the > repository I had just created in case it was corrupted. How was I > supposed to respond to the question mark? You were put in ed The standard and always present editor in UN*X's. q for quit would be the appropriated response. instead of setting the EDITOR variable you could do fossil settings editor PutYourFavoriteEditorHere -global > > By the way, why do these version control systems insist on a comment? > Yes, I understand that commenting is good practice, but does that mean > it should be mandatory and the version control system should force me > to write one? I tend to think not. Because when you alter software you have an intent. It is either correcting a bug, adding features, building. These commits show the intent why you altered the software. So just the comment will give you an idea what the intent of the source code change are. Which will be beneficial 2 months later when you try to remember which commit contains the change you made. I ques that in your case not setting the EDITOR and going with q enter y enter is sufficient > > Regards, > Russ Paielli In general every software package has it own learning curve. I think in the case of fossil you are now over the steepest curve :-) Regards -- Rene ___ 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] Stash. Was: How should Fossil handle this merge conflict...
On Wed, Dec 15, 2010 at 11:10:17PM +0100, Joerg Sonnenberger wrote: > On Wed, Dec 15, 2010 at 10:50:52PM +0100, Lluís Batlle i Rossell wrote: > > On Wed, Dec 15, 2010 at 08:33:29PM +0100, Joerg Sonnenberger wrote: > > > Having incomplete changes in the tree is bad for things like bisect. > > > It shouldn't be forced. The big issue here is that merging changes the > > > working copy. If you can make it possible that automatic merges can be > > > done directly, without changing the working copy, that would be good > > > enough for this purpose. > > > > I prefer the current "fossil undo" option (with later commit to a branch), > > and I don't like much those automatic merges done directly, unless they are > > optional. > > The trouble with "fossil undo" is that it throws away the state at some > point, e.g. it very volatile and I wouldn't trust it with my data. There is "fossil redo", that should put the working directory in the same state as before the "undo" (regardless of any later changes after the undo). Is it? > Automatic merge + commit should definitely be optional behavior. It > might make sense to use it as default and fall back to "manual" merging > otherwise. > > > The "fossil undo" + new branch, for those who believe in saving as much as > > possible in the history of the file tree, even encourages the public > > resolution > > of the merge. For those not wanting to save that publicly, those can even > > use > > "-private". > > I would prefer to know in advance whether I can merge without problems > or not. Problems against the base revision, not the working copy. This > is important to decide whether I have to get a new working copy to do > the merge, especially when working on a private branch. I think the fossil 'trunk' knows, whether conflicts come from the working directory or the ckecked out version. The summary after 'merge' could indicate: X conflicts with the local changes, Y conflicts with the checked out version. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
