Re: [fossil-users] The fossil service command
On Mon, 18 Jul 2011 23:51:11 +0300, Richard Hipp d...@sqlite.org wrote: First of all, thank you Thomas (and you Richard!) for such a nice feature. Regarding name of the command I'm agree 'service' and 'server' commands are confusing, since theya re very close by meanings. However, I don't think that 'win-serve' is OK too, because this feature will be available on Windows only, so 'win' prefix is definitely obsolete. Moreover, command names with dashes seems to be inconsistent to other fossil commands. I'm voting for name 'background'. It's the same by the meaning, but more useful than 'service' because we can use short command 'fossil ba', for example in this case. Thomas Schnurrenberger's fossil service command - for running Fossil as a windows service - is now on the trunk. But I wonder: The name of this command is very similar to fossil server and might be confusing. Do we need to change it to something more distinctive? Perhaps fossil wservice or fossil win-serve. Other ideas? -- @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] Converting from mercurial
On Mon, Jul 18, 2011 at 09:18:29PM -0700, Jeremy Anderson wrote: Out of curiosity, why are you converting from mercurial? I ask because my friends and I adopted fossil and other friends of ours are asking us why we didn't go with mercurial instead. I didn't really have a good answer, apart from fossil seemed smaller (footprint, use-complexity) and cooler =) I have a big lack of faith for interpreted languages with modules like python. First, they run unnecessarily slow (some say, that they allow developing faster, but I don't agree) and take unnecessarily big amounts of memory. Second, they usually postpone to the 'run time' many system administration issues, with far more complexity than shared objects and dynamic linking. You need matching interpreter versions, modules for those versions, spread at proper positions of the hard disk, and even then, your particular settings (PYTHONPATH,...) can disturb all that too much. You may have other software that requires another python version and the same modules spread for that version. I think the interpreted languages have quite an uncomfortable deployment. Then you go to cross-building, and cross-deployment, and to me it looks like the time to cut yoru veins. :) These interpreters postpone too much runtime environment issues to the user, instead of leaving them easy to a sysadmin or even the programmer. So, every time I run 'hg', I can only feel that it runs by chance. I have many programs written in mercurial, most started at the time where even git was not in trend, and the only vcs I knew was svn. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
On 19.07.2011 06:16, Jeremy Anderson wrote: Other platforms could either re-direct it (e.g., fossil service becomes an alias for fossil server), or just print a message saying that the command is only valid for Windows operating systems. On non Windows platforms, fossil service prints the following message: The service command is platform specific and not available on this platform. HTH -- tsbg ___ 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] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)
Hi, Many thanks for your answers, it turns out I got extremely confused by not paying enough attention to a fossil warning. * Richard Hipp d...@sqlite.org [20110719 00:52]: On Mon, Jul 18, 2011 at 6:41 PM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: I've stumbled upon a situation in which fossil's latest wins merge strategy and a system's far-in-the-future clock have messed up my content timeline. I do recall fossil's warning regarding out-of-synch clocks when synching, but thought that it would DTRT since the files being modified in that system where unrelated to the files being modified in the server against which it was synching. I don't really understand your problem. I get the part about you having make some check-ins with far-in-the-future timestamps. But Fossil doesn't have a latest wins merge strategy. So I'm not sure where that is causing a problem. latest wins merge strategy has shown to be a poor word choice: I did not invoke 'fossil merge' at all (I haven't branched). All work was done in the same (and only) branch, just on diferent systems with out-of-sync clocks. When you try to reference a check-in by its branch name, Fossil actually chooses the check-in of that branch with the latest timestamp. So, if you have some check-ins which are far in the future, those check-ins might be selected when you use the branch name, even though they are not the last check-ins in sequence. Is that what you are having problems with? (That has nothing to do with merging, though, which is why I don't really understand the problem.) This might indeed be the issue, what surprised me is that fossil couldn't DTRT. When I refered to concrete artifacts/manifests I was referencing them by their hash in 'fossil diff --from x --to y'. Another solution is to use the edit feature of the web interface to manually change the timestamps of the far-in-the-future check-ins to something more reasonable. Wow! Talk about rewriting history :p This did the trick: the timeline looks back to normal *and* the content as shown through the embedded doc URL is the same as on the filesystem. * Ron Wilson ronw.m...@gmail.com [20110719 02:10]: I think what Joan is refering to is this, from the Fossil documentation: Wiki pages can branch and merge just like check-ins, though as of this writing (2008-07-29) there is no mechanism in the user interface to support branching and merging. The current implementation of the wiki shows the version of the wiki page that has the most recent timestamp. So I think that manually fixing the timestamps will correct the problem. Indeed, manually fixing the timestamps has corrected the problem. I believe the lesson learned (for me) is that embedded doc is not part of the version graph. However, the fact that a file is different on the filesystem than through the web interface I believe should be considered a bug, it is way too confusing. tks, and keep up the good work -- pica ___ 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] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)
On Tue, Jul 19, 2011 at 4:50 AM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: Another solution is to use the edit feature of the web interface to manually change the timestamps of the far-in-the-future check-ins to something more reasonable. Wow! Talk about rewriting history :p This is a correction not an erasure. The original timestamp is preserved and is even shown on the web interface in places, for historical reference. So there is no loss of information and an audit trail is preserved. History is not rewritten - it is amended with new information. The difference might not seem like much at first glance, but it is a very important distinction. -- 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] Converting from mercurial
On Tue, Jul 19, 2011 at 12:18 AM, Jeremy Anderson jere...@gmail.com wrote: Out of curiosity, why are you converting from mercurial? I ask because my friends and I adopted fossil and other friends of ours are asking us why we didn't go with mercurial instead. I didn't really have a good answer, apart from fossil seemed smaller (footprint, use-complexity) and cooler =) Some other possible reasons to prefer Fossil over Mercurial: (1) Fossil supports integrated and distributed trouble-tickets, wiki, embedded documentation, and blog entries in addition to versioning your files. Mercurial is a file-versioning system only. (2) The fossil ui and fossil serve commands are easier to use and provide much more information than the hg serve command. (3) Fossil gives you a timeline to help track your project. If Mercurial does this, I've never seen it. (4) Fossil is stand-alone; it does not require python to be installed. Fossil can be run from within a very restrictive chroot jail (which is a nice security feature on servers.) (5) A Fossil repository is a single disk file, not a .hg directory containing multiple files. (6) A single fossil repository can host multiple checkouts at the same time. (7) Fossil allows you to amend check-ins with revised timestamps, check-in comments, and/or committers. The original content is preserved and displayed on detailed views, but the revised content is shown on primary displays. (8) Fossil allows check-ins to be moved into new branches after they are committed. (9) Fossil versions branch names so that all contributors have a consistent view of the project. (Git does not do this. I'm not sure how Hg works in this regard - perhap a reader can brief me.) (10) The fossil all sync command. (11) Cloning the self-hosting Fossil repo gets you the entire Fossil website, not just the Fossil source code. (One could argue that this is a restatement of point #1.) (12) Fossil has auto-sync mode, which helps to keep all collaborators working on the same code rather than diverging off into their on forks. -- 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] Converting from mercurial
* Jeremy Anderson jere...@gmail.com [20110719 06:18]: Out of curiosity, why are you converting from mercurial? 1) plain C, single binary 2) integrated wiki ticketing The big minus for me which still keeps me on mercurial for some stuff is the lack of hooks for significant events (commit/update, push/pull). qvb -- pica ___ 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] Converting from mercurial
On Tue, Jul 19, 2011 at 05:35:13AM -0400, Richard Hipp wrote: (3) Fossil gives you a timeline to help track your project. If Mercurial does this, I've never seen it. Well, there is 'hgk'. http://mercurial.selenic.com/wiki/HgkExtension Mercurial also comes with a python web script, that gives pictures like this: http://vicerveza.homeunix.net/~mercurial/cgi-bin/hgwebdir.cgi/ts/graph/bb87d5e7c466 ___ 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] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)
On Tue, Jul 19, 2011 at 4:50 AM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: Many thanks for your answers, it turns out I got extremely confused by not paying enough attention to a fossil warning. Did Fossil give a warning about the times between the 2 PCs not being in sync? ___ 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] Converting from mercurial
On Jul 19, 2011, at 09:38 , Lluís Batlle i Rossell wrote: I have a big lack of faith for interpreted languages with modules like python. First, they run unnecessarily slow (some say, that they allow developing faster, but I don't agree) and take unnecessarily big amounts of memory. Second, they usually postpone to the 'run time' many system administration issues, with far more complexity than shared objects and dynamic linking. You need matching interpreter versions, modules for those versions, spread at proper positions of the hard disk, and even then, your particular settings (PYTHONPATH,...) can disturb all that too much. You may have other software that requires another python version and the same modules spread for that version. Actually for Python this problem is mostly solved by automated tools, you can google it by virtualenv. Apart from performance, none of this is essentially different than with non-interpreted languages. I think the interpreted languages have quite an uncomfortable deployment. Then you go to cross-building, and cross-deployment, and to me it looks like the time to cut yoru veins. :) Actually I have pretty much opposite feelings. Proper installation of Perl or Python provides a more uniform base for my applications. Then, Mac OS X and vast majority of Linux distributions come with proper installations. So I'm actually developing on a Mac laptop, and then deploying it to Linux boxes for crunching numbers is just a matter of scp-ing the whole thing. For the small utils I sometimes write, they also always work OOTB. However, I'm not working on complex packaged software. 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] The fossil service command
On Tue, Jul 19, 2011 at 6:16 AM, Jeremy Anderson jere...@gmail.com wrote: I currently host fossil server as a window service via NSSM. fossil service gets my vote. simple to the point. i would argue for the win prefix because 'service' is used on other platforms as well, e.g. Solaris SMF services or Debian's service start/stop interface. Other platforms could either re-direct it (e.g., fossil service becomes an alias for fossil server), or just print a message saying that the command is only valid for Windows operating systems. Since the command could presumably only run on Windows, i would expect it to not be available on other platforms. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] embedded doc filesystem out-of-sync? (caused by out-of-synch clock)
* Ron Wilson ronw.m...@gmail.com [20110719 14:28]: On Tue, Jul 19, 2011 at 4:50 AM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: Many thanks for your answers, it turns out I got extremely confused by not paying enough attention to a fossil warning. Did Fossil give a warning about the times between the 2 PCs not being in sync? I can't recall exactly what it said, but I'm pretty sure fossil told me something to that effect. qvb -- pica ___ 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] Converting from mercurial
On Tue, Jul 19, 2011 at 11:35 AM, Richard Hipp d...@sqlite.org wrote: (2) The fossil ui and fossil serve commands are easier to use and provide much more information than the hg serve command. Let's not forget: (2.5) The ability to run Fossil over a CGI. This has been THE killer feature for me the past several years. i've tried several times to get git running over cgi but never succeeded. In Fossil it takes all of 3 minutes. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
Why not make an option e.g. fossil server -service? -- 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] Converting from mercurial
Thanks, mike. :) On Mon, Jul 18, 2011 at 10:36 PM, Mike Meyer m...@mired.org wrote: On Mon, 18 Jul 2011 21:18:29 -0700 Jeremy Anderson jere...@gmail.com wrote: Out of curiosity, why are you converting from mercurial? While you weren't asking me, I converted from mercurial (and did the hg - git - fossil path) to fossil, so feel an answer from me isn't unreasonable. I ask because my friends and I adopted fossil and other friends of ours are asking us why we didn't go with mercurial instead. I didn't really have a good answer, apart from fossil seemed smaller (footprint, use-complexity) and cooler =) I'm an independent consultant, and often work for small companies that don't have a corporate SCM or issue tracking system, etc. I originally looked at fossil because I couldn't get a working build of mercurial on an antiquated solaris system (couldn't seem to get a Python build to use any of the ssl libraries, which broke hg even if you aren't using ssl). Getting a working fossil build on that system was easy - just turn off SSL in the Makefile. Once I had it up and working, investigating the wiki and issue tracking system was free, and turned out to be a real win. All for less work than setting up hg (or git) in the first place. Being able to have multiple checkouts of the same repository is also a win - I keep multiple branches checked out, and can merge differences without a push/pull, and can then push all of it to my clients machine. I still use hg for projects I release as open source, mostly because the major hosting sites (I prefer google code) don't support it. To make up for that, I plan to make adding fossil support to cabal as one of my next projects. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Converting from mercurial
Unless you're on windows+IIS. Then it takes hours. And maybe then it doesn't even work... :) On Tue, Jul 19, 2011 at 6:06 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 19, 2011 at 11:35 AM, Richard Hipp d...@sqlite.org wrote: (2) The fossil ui and fossil serve commands are easier to use and provide much more information than the hg serve command. Let's not forget: (2.5) The ability to run Fossil over a CGI. This has been THE killer feature for me the past several years. i've tried several times to get git running over cgi but never succeeded. In Fossil it takes all of 3 minutes. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil IIS-CGI. Was: Converting from mercurial
On Tue, Jul 19, 2011 at 10:05 AM, Jeremy Anderson jere...@gmail.com wrote: Unless you're on windows+IIS. Then it takes hours. And maybe then it doesn't even work... :) Is that an issue with IIS or with Fossil? If the problem is with Fossil, please suggest changes we can make so that Fossil plays better with IIS. -- 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] The fossil service command
On Tue, Jul 19, 2011 at 3:42 PM, Rene renew...@xs4all.nl wrote: Why not make an option e.g. fossil server -service? +1 :) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
On 19.07.2011 15:42, Rene wrote: Why not make an option e.g. fossil server -service? because the service command consists of several sub-commands? -- tsbg ___ 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] Converting from mercurial
To be fair, I'm being glib - it probably works fine if properly configured, but configuring CGI plugins on IIS is not a straightforward task. I tinkered with it for an afternoon and only got so far as IIS loading an instance of fossil.exe for each inbound request. Sadly, the .exes would just sit there chewing up 13% of my CPU (each) and never return, causing the browser to timeout. After a dozen requests, the machine would tank because of all the stalled (but active) fossil processes... not pretty, and hard to debug since i couldn't see what the fossil.exes were up to. fossil server took all of 3 minutes to get running. All I had to do was open up all the right ports in my firewalls and tell NSSM to run it as a service. Done. On Tue, Jul 19, 2011 at 7:05 AM, Jeremy Anderson jere...@gmail.com wrote: Unless you're on windows+IIS. Then it takes hours. And maybe then it doesn't even work... :) On Tue, Jul 19, 2011 at 6:06 AM, Stephan Beal sgb...@googlemail.comwrote: On Tue, Jul 19, 2011 at 11:35 AM, Richard Hipp d...@sqlite.org wrote: (2) The fossil ui and fossil serve commands are easier to use and provide much more information than the hg serve command. Let's not forget: (2.5) The ability to run Fossil over a CGI. This has been THE killer feature for me the past several years. i've tried several times to get git running over cgi but never succeeded. In Fossil it takes all of 3 minutes. -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Converting from mercurial
Lack of hooks is a hassle for me too. Wrapper scripts don't meet the need - especially on the server side. Part of the power of hooks is that you don't have to replicate the effort of parsing the command line to know what is being done. An example: I have a regression system running and when commits happen on the release branch of the regression code I'd like the regression run area brought up to date. This is very easy with a hook on commit. Right now I have to run fossil update in a crontab every five minutes. Maybe there is a better way even without hooks? - Original message - * Jeremy Anderson jere...@gmail.com [20110719 06:18]: Out of curiosity, why are you converting from mercurial? 1) plain C, single binary 2) integrated wiki ticketing The big minus for me which still keeps me on mercurial for some stuff is the lack of hooks for significant events (commit/update, push/pull). qvb -- pica ___ 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] Converting from mercurial
Pretty good list. A few comments below on a couple of them (I switched from git to mercurial and then to fossil). On Tue, Jul 19, 2011 at 5:35 AM, Richard Hipp d...@sqlite.org wrote: (3) Fossil gives you a timeline to help track your project. If Mercurial does this, I've never seen it. Mercurial does have a pretty decent (and customizable) timeline functionality: http://hgbook.red-bean.com/read/customizing-the-output-of-mercurial.html I remember writing templates to make the output look like git (ha!), back before I found fossil. The git-style history diff summaries are pretty neat looking. (6) A single fossil repository can host multiple checkouts at the same time. This is also doable with mercurial (just check out to a new folder), unless I'm confused about what you mean. (9) Fossil versions branch names so that all contributors have a consistent view of the project. (Git does not do this. I'm not sure how Hg works in this regard - perhap a reader can brief me.) Branch names are versioned in mercurial. You assign a name and then commit it. http://mercurial.selenic.com/wiki/NamedBranches (12) Fossil has auto-sync mode, which helps to keep all collaborators working on the same code rather than diverging off into their on forks. This is one of the features that keeps me coming back. Why mercurial and git don't have this option is beyond me. For small especially, but even for fairly large projects, this is the greatest way to keep everyone together without needing excessive merging. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
To quote Donald Knuth: the root of all evil is premature optimization. Is service really that confusing? imho service is the term that windows users would be most familiar with; perhaps it can be given a try first before being rejected as confusing. If it doesn't work out, perhaps svc is a workable alternative. Paul - Original Message - From: Richard Hipp d...@sqlite.org To: fossil-users fossil-users@lists.fossil-scm.org Sent: Monday, July 18, 2011 10:51 PM Subject: [fossil-users] The fossil service command Thomas Schnurrenberger's fossil service command - for running Fossil as a windows service - is now on the trunk. But I wonder: The name of this command is very similar to fossil server and might be confusing. Do we need to change it to something more distinctive? Perhaps fossil wservice or fossil win-serve. Other ideas? -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
On 7/19/2011 11:27 AM, Paul wrote: Is service really that confusing? I'm more concerned that `fossil serv` becomes ambiguous. (fossil allows unambiguous short versions of all its commands.) -- Joshua Paine LetterBlock: Web Applications Built With Joy http://letterblock.com/ 301-576-1920 ___ 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 IIS-CGI. Was: Converting from mercurial
I'm not sure. I mentioned on another thread fiber that I battled it for hours and only got as far as getting fossil to spawn. I don't know why it never came back... and I figured why use IIS just to host fossil when it has a web server [that works properly with itself] built in? =) On Tue, Jul 19, 2011 at 7:11 AM, Richard Hipp d...@sqlite.org wrote: On Tue, Jul 19, 2011 at 10:05 AM, Jeremy Anderson jere...@gmail.comwrote: Unless you're on windows+IIS. Then it takes hours. And maybe then it doesn't even work... :) Is that an issue with IIS or with Fossil? If the problem is with Fossil, please suggest changes we can make so that Fossil plays better with IIS. -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
To quote Donald Knuth: the root of all evil is premature optimization. Although the quote is nice and applicable to many situations, I think that this is absolutely not the case. The problem is not to make a type of optimization, the problem is that it is necessary to make a decision now, and do it good. At least, as good as possible. Once this name is decided, it will be nearly impossible to change it in the future. In my opinion, the name service is too generic and too windows specific. Fossil can give us a lot of services, apart from using the Windows services feature. I agree with another poster that a good solution could be to make it a subcommand of server. How many times is people going to install/uninstall the service? Something like: fossil server ?-P|--port TCPPORT? ?--service-install? ?--service-remove? ?REPOSITORY? RR 2011/7/19 Paul p...@planet.nl: To quote Donald Knuth: the root of all evil is premature optimization. Is service really that confusing? imho service is the term that windows users would be most familiar with; perhaps it can be given a try first before being rejected as confusing. If it doesn't work out, perhaps svc is a workable alternative. Paul - Original Message - From: Richard Hipp d...@sqlite.org To: fossil-users fossil-users@lists.fossil-scm.org Sent: Monday, July 18, 2011 10:51 PM Subject: [fossil-users] The fossil service command Thomas Schnurrenberger's fossil service command - for running Fossil as a windows service - is now on the trunk. But I wonder: The name of this command is very similar to fossil server and might be confusing. Do we need to change it to something more distinctive? Perhaps fossil wservice or fossil win-serve. Other ideas? -- 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 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] some scripts I use to make life easier
I wanted to share some scripts I whipped up to make traversing my fossil
checkouts easier in Windows. If Richard et al., want to add these kinds of
commands to the fossil.exe directly, i'm all for it... I just wanted to
share what's making my fossil use easier until then. =)
*root.cmd*
This walks up the path until it finds _FOSSIL_ (aka, the root folder of
your current checkout) and leaves you there. If it can't find _FOSSIL_, it
will let you know that you're not within an active checkout and leave you in
the directory you started in.
@echo off
SET _startingLocation=%CD%
SET _=
:check
IF [%_%]==[%CD%] (
echo You are not within an open checkout.
cd %_startingLocation%
GOTO :EOF
)
SET _=%CD%
IF NOT EXIST _FOSSIL_ (
CALL :goUp
) ELSE (
GOTO :end
)
goto :eof
:goUp
CD ..
CALL :check
:end
SET _=
SET _startingLocation=
*root.ps1*
This script is a powershell version of root.cmd. I would usually make
root.cmd just an alias for root.ps1, but sometimes I find myself in a cmd
prompt and transferring state (such as your current directory) to a parent
shell is messy. Easier in this case to maintain two different scripts for
two different shells.
try {
$root = Get-CheckoutRootPath
pushd $root
} catch {
write-host You are not within an open checkout.
write-host
}
*addextra.ps1*
My team and I develop in C#. As such, we most often only need to add *.cs
and *.csproj files to our enlistment. Visual Studio likes to create tons of
extra files when you build (objs and dlls and exes and cache files and
such), making the 'fossil extras' and 'fossil addremove' commands not quite
so useful. This script takes the output of 'fossil extras'* *and filters it
to select our desired files, and then changes to the root of the checkout
and adds each file (since fossil add doesn't seem to support the paths that
fossil extras emits unless you're in the root of the checkout... even if you
prepend a / it just gets confused).
[CmdletBinding(SupportsShouldProcess=$true)]
param()
try {
$root = Get-CheckoutRootPath
pushd $root
$extras = fossil extras
$foundFiles = $false
foreach($file in $extras) {
if ($file.EndsWith(.cs) -or $file.EndsWith(.csproj)) {
if ($pscmdlet.ShouldProcess($file, fossil add)) {
fossil add $file
}
$foundFiles = $true
}
}
if(-not $foundFiles) {
write-host No matching files to add.
}
popd
} catch {
write-host $error
}
*addextra.cmd*
This is a simple call-through batch file that lets me use addextra.ps1 (a
powershell script) from a regular command prompt. It must live in the same
folder as addextra.ps1. (Note, this pattern is not specific to addextra.cmd
- you can copy and rename this .cmd file to match the name of any other .ps1
file and it will automatically enable that powershell script for cmd prompt
execution. =)
@powershell -File %~dpn0.ps1 %*
*Get-CheckoutRootPath.ps1*
This is the powershell function that enables the scripts 'root.ps1' and
'addextra.ps1' as listed above.
param([string]$dir = $($(Get-Location).Path))
function GetRootPath($dir) {
$found = Test-Path $($dir + \_FOSSIL_)
if(-not $found) {
$parent = Split-Path $dir -Parent
if($parent -ne ) {
GetRootPath $parent
} else {
throw You are not within an open checkout.
}
} else {
$dir
}
}
GetRootPath $dir
Happy fossiling,
-jer
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
On 19.07.2011 17:47, Ramon Ribó wrote: In my opinion, the name service is too generic and too windows specific. Fossil can give us a lot of services, apart from using the Windows services feature. I agree with another poster that a good solution could be to make it a subcommand of server. How many times is people going to install/uninstall the service? Something like: fossil server ?-P|--port TCPPORT? ?--service-install? ?--service-remove? ?REPOSITORY? I don't think that this a good idea because the service command has several sub-commands. It is probably better to change the command-name from service to e.g. winsvc -- tsbg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
On Tue, Jul 19, 2011 at 12:12 PM, Thomas Schnurrenberger t...@gmx.net wrote: It is probably better to change the command-name from service to e.g. winsvc +1 vote for winsvc/winserve/winservice (no hyphen) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
I vote for fossil server --service or something similar. -Original Message- From: Wes Freeman Sent: Tuesday, July 19, 2011 12:18 PM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] The fossil service command On Tue, Jul 19, 2011 at 12:12 PM, Thomas Schnurrenberger t...@gmx.net wrote: It is probably better to change the command-name from service to e.g. winsvc +1 vote for winsvc/winserve/winservice (no hyphen) ___ 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] The fossil service command
fossil server ?-P|--port TCPPORT? ?--service-install? ?--service-remove? ?REPOSITORY? I don't think that this a good idea because the service command has several sub-commands. It is probably better to change the command-name from service to e.g. winsvc Althouth winsvc could also be a good solution, what other sub commands, appart from install and remove do you really need? I understand that start and stop can be managed automatically, or for special cases, from the Windows GUI directly. RR 2011/7/19 Thomas Schnurrenberger t...@gmx.net: On 19.07.2011 17:47, Ramon Ribó wrote: In my opinion, the name service is too generic and too windows specific. Fossil can give us a lot of services, apart from using the Windows services feature. I agree with another poster that a good solution could be to make it a subcommand of server. How many times is people going to install/uninstall the service? Something like: fossil server ?-P|--port TCPPORT? ?--service-install? ?--service-remove? ?REPOSITORY? I don't think that this a good idea because the service command has several sub-commands. It is probably better to change the command-name from service to e.g. winsvc -- tsbg ___ 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] The fossil service command
Just read through the code. Got a few comments:
These errors:
if( g.argc4 ) fossil_fatal(to much arguments for delete method.);
if( g.argc4 ) fossil_fatal(to much arguments for show method.);
if( g.argc4 ) fossil_fatal(to much arguments for create method.);
if( g.argc4 ) fossil_fatal(to much arguments for start method.);
if( g.argc4 ) fossil_fatal(to much arguments for stop method.);
should read Too many arguments for [method_name] method. or [method_name]
does not take that many arguments., if left in. However, I suggest removing
them altogether and promoting all input checking to the start of the
cmd_win32_service() method, because all the conditions (g.argc4) are
identical.
In other words, I suggest re-factoring all of these checks higher up and
only doing it once, i.e., changing this block of code from:
+ void cmd_win32_service(void){
+ int n;
+ const char *zMethod;
+ const char *zSvcName = Fossil-DSCM; /* Default service name */
+
+ if( g.argc3 ){
+usage(create|delete|show|start|stop ...);
+ }
+ zMethod = g.argv[2];
+ n = strlen(zMethod);
+ if( g.argc==4 ){
+zSvcName = g.argv[3];
+ }
to:
+ if( g.argc3 || g.argc4){
+usage(create|delete|show|start|stop ...);
+ }
+ zMethod = g.argv[2];
+ n = strlen(zMethod);
+ zSvcName = g.argv[3];
(Note: I'm assuming the usage() function somehow aborts execution when it's
finished.)
-jer
On Mon, Jul 18, 2011 at 1:51 PM, Richard Hipp d...@sqlite.org wrote:
Thomas Schnurrenberger's fossil service command - for running Fossil as a
windows service - is now on the trunk. But I wonder: The name of this
command is very similar to fossil server and might be confusing. Do we
need to change it to something more distinctive? Perhaps fossil wservice
or fossil win-serve. Other ideas?
--
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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
On 19.07.2011 18:36, Ramon Ribó wrote: Althouth winsvc could also be a good solution, what other sub commands, appart from install and remove do you really need? You don't need the service command at all. There are command line utilities and/or GUI's in the Windows OS which have the required functionality. But not every tool does everything. The fossil service command is a convenience command for Windows users who are not system administrators. It concentrates the necessary functionality where it is needed. -- tsbg ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] The fossil service command
The fossil service command is a convenience command for Windows users who are not system administrators. It concentrates the necessary functionality where it is needed I agree with it. So my proposal was to add the minimal functionality to the command: fossil server --install-service fossil server --remove-service What else is really necessary? Compass Ing. y Sistemas Dr. Ramon Ribo http://www.compassis.com ram...@compassis.com c/ Tuset, 8 7-2 tel. +34 93 218 19 89 08006 Barcelona, Spainfax. +34 93 396 97 46 El 19/07/2011 21:52, Thomas Schnurrenberger t...@gmx.net escribió: On 19.07.2011 18:36, Ramon Ribó wrote: Althouth winsvc could also be a good solution, what other sub commands, appart from install and remove do you really need? You don't need the service command at all. There are command line utilities and/or GUI's in the Windows OS which have the required functionality. But not every tool does everything. The fossil service command is a convenience command for Windows users who are not system administrators. It concentrates the necessary functionality where it is needed. -- tsbg ___ 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
