Re: [fossil-users] Linux/Windows USB
Install “mingw and msys Original message From: henk harmsen h...@carbonmetrics.com Date: To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] Linux/Windows USB At work I have a Windows 7 laptop, at home a Linux Debian system on which I do the real work. No network traffic is allowed but the files may be put on an encrypted USB. So my fossils are on the USB. The problem that I am facing is that the Debian path starts with /media/usb/mydir, whereas in Windows that is G:\mydir. So, fossil status gives : current directory is not within an open checkout. Is there a workaround for this? Henk ___ 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] Linux/Windows USB
Verzonden vanaf Samsung Mobile Original message From: renework renew...@xs4all.nl Date: To: Fossil SCM user's discussion fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] Linux/Windows USB Install “mingw and msys and make a mount g:mydir /your/path/on/debian. Original message From: henk harmsen h...@carbonmetrics.com Date: To: fossil-users@lists.fossil-scm.org Subject: [fossil-users] Linux/Windows USB At work I have a Windows 7 laptop, at home a Linux Debian system on which I do the real work. No network traffic is allowed but the files may be put on an encrypted USB. So my fossils are on the USB. The problem that I am facing is that the Debian path starts with /media/usb/mydir, whereas in Windows that is G:\mydir. So, fossil status gives : current directory is not within an open checkout. Is there a workaround for this? Henk ___ 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] Using docbook as a way to generate wiki pages
I have been playing with docbook and let it generate wiki pages. I create www/th/ I used the th1 pdf and made the first 2 chapters in THManuals.xml. I customized the html chunk.xsl in wiki-pages.xsl and run xsltproc wiki-pages.xsl THManuals.xml and voila in http://localhost:8080/doc/ckout/www/th/index.wiki you can read the manual. Problems 1) utf-8 nbsp (#160;) isn't displayed correct in firefox (�) anybody a solution? 2) various elements span, colgroupcolcol/colgrouptbody/tbody aren't recognized by wiki. Offcourse if you make html the wiki language then everything is accepted. I did create a compressed tar file of the th directory like so: tar -cvzf th.tgz www/th/ and added it to the mail if someone wants to experiment. The advantage of this is that you can make documentation in pdf, html, wiki and any other format supported by docbook from the same source. e.g. the docbook document http://www.fossil-scm.org/schimpf-book/index could be converted to wiki pages and served from the repository. Rene th.tgz Description: GNU Zip compressed data ___ 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] Using docbook as a way to generate wiki pages
Correction the document at http://www.fossil-scm.org/schimpf-book/index is NOT a docbook document so it cannot be used in the way I said :-( On Sun, 19 Sep 2010 12:40:53 +0200, renework renew...@xs4all.nl wrote: I have been playing with docbook and let it generate wiki pages. I create www/th/ I used the th1 pdf and made the first 2 chapters in THManuals.xml. I customized the html chunk.xsl in wiki-pages.xsl and run xsltproc wiki-pages.xsl THManuals.xml and voila in http://localhost:8080/doc/ckout/www/th/index.wiki you can read the manual. Problems 1) utf-8 nbsp ( ) isn't displayed correct in firefox (�) anybody a solution? 2) various elements span, colgroupcolcol/colgrouptbody/tbody aren't recognized by wiki. Offcourse if you make html the wiki language then everything is accepted. I did create a compressed tar file of the th directory like so: tar -cvzf th.tgz www/th/ and added it to the mail if someone wants to experiment. The advantage of this is that you can make documentation in pdf, html, wiki and any other format supported by docbook from the same source. e.g. the docbook document http://www.fossil-scm.org/schimpf-book/index could be converted to wiki pages and served from the repository. 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] Building Fossil with MSVC (CL.EXE et al.)
On Wed, 11 Aug 2010 11:54:00 -0400, Samuel Adam a...@certifound.com wrote: == What is this? == An attempt to build Fossil using Microsoft Visual C. For this purpose, I used the compiler from Windows SDK 7.1. Despite the “Visual” moniker, I am therefore doing this from the command line. == Why? == Real portability for C code implies that a build should work with the default compiler for a platform; and MSVC is the closest that Windows comes to a default compiler. SQLite is ideal in this aspect: For example, I can build the SQLite3 shell off the amalgamation using a single command. I do not want to install another whole toolchain (i.e., Mingw) just so I can build Fossil—but I do want to (a) use Fossil, (b) tinker with it, and (c) rebuild it with the results of any such tinkering. == Results == No working build thus far. After much pain, however, I seem to be close: All the object files compile without errors, and the build only fails at the final link invocation with a fairly commonplace, Windows-specific link conflict. I am probably making one single obvious mistake. In the process of doing this, I discovered what appears to be two different bugs in makeheaders.c. I should probably post about this separately with details; meanwhile, see the comments in my buildfossil.bat script. I also needed to tinker with src/config.h, which I have attached. Only a few #include lines were changed; diff it to see why. Microsoft’s nmake is (obviously) not up to the task of running Fossil’s build scripts. So I poked around makemake.tcl and main.mk, and cobbled together a batch script. The results of this experiment would best be integrated into makemake.tcl. Fossil’s unistd.h dependency turned out to be the biggest hurdle. Since the Mingw headers are supposed to be wrappers around native Windows, I untarred a bundle of them and copied as few as possible to my working directory. I know that Mingw was made to work with GCC, not MSVC; but *hopefully* the C code is not dependent on a single compiler. Aside from that, the only problem is the generation of VERSION.h. I generated VERSION.h from the exact same source snapshot on a *nix system, and used that. That is a hazardously brittle build practice, but will work perfectly as a short-term hack. Building the object files resulted in a (very) few warnings. Most look spurious, but I have not verified this. A log is attached. == Tested On == * Windows Vista x64 * MSVC 10.0 (as installed by Windows SDK 7.1) * setenv /vista /release /x64 * fossil-src-20100805100943 snapshot from Fossil website * zlib 1.2.5 (tried with zlib built both /MT and /MD) * N.b., no attempt was made to include OpenSSL. == How To Try == The attached files have been renamed to avoid mailing list strippage. Name buildfossil.bat appropriately, place it in the root directory of a fossil snapshot, and follow the instructions contained inside it. The needed Mingw headers are listed therein. Advices on the production of a working fossil.exe would be appreciated. A basic operational build would facilitate attempts to devise a longer-term solution. Very truly, Samuel Adam 763 Montgomery Road Hillsborough, NJ 08844-1304 United States There is a unistd.h out on the net for compiling under windows. Buti found that you had to adjust fossil src. Mainly change __MINGW__ to __WIN32__ ___ 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] Proposed Change To Wiki vs. HTML
On Sun, 25 Jul 2010 17:47:56 -0400, Richard Hipp d...@sqlite.org wrote: I really, really do not like the Use-HTML-Wiki switch and I rue the day that I ever allowed that into the code. I have no desire to make the situation worse by making the Use-HTML-Wiki switch even more complicated. What Use-HTML-Wiki really comes down to is yet another wiki mode. Everybody (me included) has their own idea of what markup wiki should follow. Popular requests include Creole and Markdown. It seems to me that the Use-HTML-Wiki flag and the suggested improvements below are really just alternative wiki modes. When I first started writing Fossil, I did not understand how contentious an issue the choice of wiki markup would become In an effort to keep the peace, I am willing to consider enhancements to Fossil that support varying wiki modes, providing that those enhancements are carefully designed and thought out and do not become a pile of confused and discombobulated switches and options that slowly grow by accretion. The formatting options should be easily described on one 8.5x11 piece of paper. Anything more complicated than that is to complicated. A proposal: Five wiki modes: (1) For backwards compatibility, we must support Fossil wiki (including the safe subset of HTML). (2) In addition, some people request unfiltered, pure HTML so that they can edit documents using HTML editors. I proposed to also add formatters for (3) Creole and (4) Markdown. Finally, we add (5) plain text - no markup at all. No further options or modes are permitted. Zero. Nada. For embedded documentation, file that end in .html or .htm are rendered as pure HTML with no interpretation and with no header or footer added. File that end in .wiki are rendered using Fossil wiki. Files that end in .creole or .markdown are rendered using their respective formatters. Files ending in .txt are rendered as plain text. All wiki files and plain text files have the standard headers and footers added. For tickets, wiki, and check-in comments, each repository has global rendering mode setting which defaults to Fossil Wiki but which can be changed to one of Pure HTML (with no [...] interpretation, so slightly different from the current Use-HTML-Wiki flag) or Creole or Markdown or Plain Text. All check-in comments are always rendered using the global rendering mode. Wiki and Tickets are rendered using the global rendering mode, but there are special markups that can be specified once near the top of the document to determine the renderer used for the entire document: These rendering-mode selection markups can only appear once and must be the first text other than whitespace to appear in the document. It is not possible to include multiple markup styles in the same document. It is not possible to automatically translate from one style to another. The Use-HTML-Wiki flag will go away (to be replaced by the pure-HTML global rendering mode). The document rendering modes are the same for all users, except user will have to have a special permission flag in order to be able to edit pure HTML wiki or tickets. User's without necessary permission will not be allowed to begin editing documents in pure HTML mode and if they try to change the rendering mode as part of their edit, their change will not be accepted. No other modes. No other customization options. No other flags or switches. Will such an enhancement come closer to meeting peoples needs? I think its overkill and places a maintenance burden on the fossil maintainers. Make a choice between creole or markdown or whatever. It is impossible to satisfy all. Text is the absence of any formatting and that can be done in any mode. What I find wrong in the current wiki is the use of nowiki and verbatim because they are not html tags. If the current wiki would be extended to cvstrac functionality I would be satisfied. 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] Proposed Change To Wiki vs. HTML
On Sun, 25 Jul 2010 18:29:43 -0700, Zed A. Shaw zeds...@zedshaw.com wrote: On Sun, Jul 25, 2010 at 04:13:47PM -0700, Zed A. Shaw wrote: Actually, none of this is necessary if you solve this one simple problem: .html will not have the header and active login state of a user, so I have to use wiki, but wiki then has its own set of problems. Ok, so I've been able to simulate what I'm trying to do, and I really think this solves the problem of all the different wiki formats out there. Take a look at this: http://mongrel2.org/doc/tip/docs/manual/book.wiki Now, that's the mongrel2 book that I've started, but what's important is this is generated from a set of TeX files. TeX isn't a wiki format at all, it's just a typesetting format, but the key is that I'm able to craft a very nice PDF and produce the documentation with one make command. What the above link does is put the documentation into the mongrel2.org site so that it fits the overall setup, and people get their login state links above. Without the ability to craft an html document set and have the fossil look applied, I'd have to jank around with my own headers and try to emulate the existing site. No matter what I did I wouldn't be able to get the login state into the generated html. The significance of this is that you can turn on Wiki just like normal. Leave the wiki format the way it is, but tell people to *user their own site generator* just like I did. They generate the site in whatever the hell they want. TeX, Sphinx, Webby, Dexy, some lame ass perl, Creole, Markdown, Textile who cares. What does matter, is if they put into the /doc/tip and end it with .html (or something similar) then fossil will render it within the fossil site's look, and leave it alone. It's not wiki, it's not html, it's *templated* html. If we had that then you'd have all the problems solved in one smooth move. Wiki stays as is, people who want different wiki generate content, headers get applied along with login state links, and everybody is happy. What you think? I think you took the right approach for generating a manual. You used 2 excellent tools 1) TeX, which is crafted for typesetting scientific documentation. 2) fossil to keep the sources for your manual. I would be really impressed if there was a program that the structure of the manual would capture in fossil wiki pages. But that defeats fossil and the wiki system because we (wrongly) want to use wiki for generating the manual. Wiki has not the tight structure a manual needs. You can use wiki for documenting, but using sections, tables, artwork, (cross-)references, footnotes, table of contents, nice printing, etc isn't in the realm of wiki. Wiki isn't meant for that http://wiki.answers.com/Q/What_is_the_purpose_of_a_wiki states The purpose of Wiki is to help people understand things he or she knows nothing about. Users ask question while other users answer them to the best of their knowledge. The main feature that separates Wiki sites from other encyclopedia-type sites is that the users are able to make contributions to any article on a Wiki, such as adding or improving information, or to build up a community where anyone is free to edit. It is a very loosely knitted web which should be easy to edit using simple formatting. I agree with Richard that the current situation with the wiki is undesirable. Unifying creole, textile, fossil-wiki, html and text is a way forward, which tends to bloat fossil. You can't have your cake and eat it too :-) Maybe it is good to take a step back and state first what the purpose is of the wiki system in fossil. Which will give guidance to us all. 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] Makefile
On Thu, 08 Jul 2010 22:07:52 +0200, Paul Ruizendaal p...@planet.nl wrote: I can confirm the out-of-the-box windows build. I am using the make from the UnxUtils package: http://unxutils.sourceforge.net/ Where I went wrong was not installing the sh.exe binary, which this build of make relies on. So the minimal environment to build fossil on windows seems to be: - mingw, with zlib library - from unxutil: make, sh, rm, mkdir and gawk renamed to awk. The unxutil binaries are about ~900K together, so that's not too bad. Paul If you download msys.exe from mingw than you get all those(make, sh, rm, mkdir and gawk renamed to awk.) in one package! 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] Using ticket system from command line
On Sat, 15 May 2010 07:11:35 -0400, Richard Hipp d...@sqlite.org wrote:
On Sat, May 15, 2010 at 6:51 AM, Gour wrote:
On Sat, 15 May 2010 11:30:40 +0100
Eric == Eric wrote:
Eric Otherwise, lack of standard wiki
Eric
Eric I continue to be amazed by all this nonsense about the wiki.
s/standard/complete/g
HTML is not complete enough? What do you want to do (or for that
matter what does any other wiki system do) that you can't do (in a more
standard way, I should add) with HTML?
well I kind of like this
|c table caption
|=2 head|= head
| data|
[[http://bouml.free.fr/|{{http://bouml.free.fr/images/bouml_titre.gif}}]]|
data
| data| {{http://bouml.free.fr/images/bouml_titre.gif|bouml image}}| data
versus
The philosophy of Fossil Wiki is to provide simple and common wiki-style
markup to accomplish 90% of what you need, then allow the use of HTML
for
the other 10%. HTML is seen as superior to increasingly arcane Wiki
formatting for the complicated stuff because (1) most programmers
already
know HTML so there is nothing new to learn, (2) HTML is a standard, and
(3) HTML allows you to do just about whatever you want to do in a web
browser - it is complete. You can disagree with the design choice
here. But please distinguish between a lack of understanding and a
disagreement.
There is one argument for using wiki I haven't seen.
It can be a meta language. You can opt to translate
# Item1
html olliItem1/li/ol
docbook orderedlistlistitemItem1/listitem/orderedlist
ODF listlist-itemItem1/list-item/list
Arguable I used a very simple example.
___
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 case for Markdown (yes, I rtfm)
On Wed, 5 May 2010 14:48:33 +0200, Gour g...@gour-nitai.com wrote: On Wed, 05 May 2010 13:09:34 +0200 renework == renew...@xs4all.nl wrote: renework I'm not clear for what you are going to use this for. I'll try to explain... renework If for writing documentation, say a user manual. Then You renework don't want to use fossil markup. I'd like to use it for user manual. You get into trouble if it is contained in two wiki pages. Basically your are better of to write two markdown files and a Makefile. Which you can do in Darcs anyway. renework (I use markup in a general sense not a specific product) No problem. Product is 'markdown'. ;) renework You might want to use fossil as a scm for storing your renework documentation files. That is possible. renework (Not if you're using native word format :-) Fortunately, I'm not. After having bad experience with Lotus Word Pro many years ago (while using OS/2) I've decided not to use binary format for my writing ever again. renework If you would use say asciidoc renework http://www.methods.co.nz/asciidoc/ as fossil markup. renework Then generating A wikiPAGE could take A long time. Asciidoc renework is overkill for that purpose. I don't like Asciidoc and Docbook toolchain. Otoh, Markdown is quite readable markup, mature, with many implementations etc. I looked up markdown and it is a 35Kb perl source file. But you are in luck there is a c implementation http://www.pell.portland.or.us/~orc/Code/discount/ Now find someone to incorporate it into fossil. renework If you would enhance wiki pages for wiki purposes then a renework markup containing more functions is called for. Yes, I'd also like enhanced capabilities for wiki pages and I see that it's even on Fossil's TODO list: Ability to attach image files (GIFs and JPEGs) and refer to these in wiki pages. Enhance wiki to the point where it can host the existing fossil documentation. (http://www.fossil-scm.org/index.html/wiki?name=To+Do+List) renework Richard wants to keep his past documentation efforts. I fully understand that, but if he would decide to support Markdown, I'd be ready to convert all the Fossil docs from the present wiki to it. renework Assuming that the creole functionality satisfies your needs. No interest for creole since I'm involved with Haskell and there is very nice Pandoc allowing me to use Markdown as single-source markup capable to convert to plethora of end formats (HTML, PDF...) renework However nice it is to ramble along, The question is still renework what do you want to do with the markup? To use (more) 'standard' wiki markup like Markdown which has support in different tools (e.g. Pandoc for processing it, different blog-engines support writing in it, there is Emacs-mode for it etc.) for all my documentation-related needs instead of learning new wiki for every app I need. You do understand that other users have there own preferences for markup implementations and they all claim that theirs is the best and most standard? The present Fossil's markup lacks features in order to be used as single-source markup which is pity and forces one to use another markup for writing other docs. Richard likes HTML markup :-) . But pandoc can convert HTML to markdown (Aha do I see a way out of typing a lot of documents :-) (Before settling on markdown, I was thinking about reST and same reasoning applies there as well.) The solution I presented for creole could just as easy be used for markdown e.g. ** bold markdown this is markdown fossil and back in fossil That would spare you a lot of typing :-) also But it might bring you into trouble with pandoc because pandoc might not understand markdown my advice would be to use DARCS, write your user manual and keep the files in DARCS and use pandoc to your harts content. There is much work involved with what you want and it won't happen overnight if ever. Sincerely, Gour ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] What he danger of allowing all Html
While discussing markup and markdown i looked over wikiformat.c and notice the case of selectively allowing HTML elements. I wonder what the threat is in allowing all HTML elements. Rene ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
