Re: [fossil-users] Hosted fossil solution
Richard Hipp wrote: That said, even Fossil requires a host. So if you don't already have a host sitting around (as many people don't) I think such a service would be quite useful. It's easy enough to host a fossil repository on sourceforge, tho it doesn't interoperate with all their other tools. I can post some simple instructions if anyone's interested. -J ___ 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] Proposed Change To Wiki vs. HTML
On Mon, July 26, 2010 9:33 pm, renework renew...@xs4all.nl wrote: snip/ But that defeats fossil and the wiki system because we (wrongly) want to use wiki for generating the manual. snip/ 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. Thankyou. I tried to say much the same some time ago, but you have made a better job of it. Eric ___ 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 Mon, Jul 26, 2010 at 09:46:14PM +0100, Eric wrote: On Mon, July 26, 2010 9:33 pm, renework renew...@xs4all.nl wrote: snip/ But that defeats fossil and the wiki system because we (wrongly) want to use wiki for generating the manual. snip/ 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. Thankyou. I tried to say much the same some time ago, but you have made a better job of it. But again, none of this matters for my point. I'm not talking about wiki, I'm talking about HTML documentation. If there was a way to generate HTML using any of the many docs generators out there, and then check it into fossil so that fossil styles it, then you could use whatever wiki format you wanted. It would future proof and satisfy all the whiners. -- Zed A. Shaw http://zedshaw.com/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Accessing original check-in
I have encountered a problem which is in a way trivial, but it is also
somewhat important to me.
THE PROBLEM
After creating a new repository and opening it, 'status' displays that
it has been assigned a 'checkout' identifier; however, I am never able
to access that 'checkout'. If I create a new branch off that origin,
when I try to return to 'trunk', I receive a not a check-in error
(I've included a transcript of a test session at the end of this post).
MY GOAL
I wish to use Fossil to maintain a directory of scripts and I would
like to start a new branch whenever I create a new script, and to have
that branch contain only the script file. In other words, if 'root' is
the original empty check-in artifact, I want each script to be a
branch off of 'root' (the scripts would be merged back to 'trunk').
A WORK-AROUND
If I first check-in a commit to trunk that includes an ADDed file
(even an empty one), I can then use the original check-in ('root') for
starting branches -- successfully being able to merge those branches
back to trunk. I can even later delete the empty-file and remove it
from 'trunk'.
WHY WORK-AROUND IS UNSATISFACTORY
Though the above work-around completely satisfies my personal needs, I
am hoping to introduce some absolute beginners -- to both programming
and Source Configuration Management -- to using Fossil to organize
their programming activities. It is less than ideal that amongst the
very first steps in getting started, it is necessary to perform a
somewhat unintuitive work-around (it wouldn't be so bad if it came
later in the course).
CONCLUSION
While my goal is admittedly an edge case, and branching off an empty
check-out may be rather unintuitive itself, I do think this behavior
is somewhat anomalous and should probably be considered a bug. The
original check-out is assigned an ID and one is able to branch from
that ID, yet it is otherwise not recognized as a valid check-out of
'trunk'.
This is by no means critical, but it did seem worth mentioning. If
anybody has any suggestions for simpler work-arounds -- or maybe I
missed something completely obvious -- please let me know.
--
TRANSCRIPT OF TEST SESSION
$ fossil new $HOME/foo.fossil
project-id: 22cc9378e7e9c90aa69ab5de4d2158082e2b84c5
server-id: 4e110fd69e6c808f9b4b77da3450a674e51d0a5e
admin-user: saul (initial password is 004d85)
$ fossil open $HOME/foo.fossil
$ fossil status
repository: /home/saul/foo.fossil
local-root: /home/saul/test/
server-code: 4e110fd69e6c808f9b4b77da3450a674e51d0a5e
checkout: ed9081561d84e261b5a0f3aaf0531fdb530feb57 2010-07-26
21:57:18 UTC
tags: trunk
$ fossil branch new bar trunk
New branch: aa562d8538bbdfa72c44dbf3a8cd14d1925d6db1
$ fossil co bar
$ touch empty-file
$ fossil add empty-file
ADDED empty-file
$ fossil commit
New_Version: d5a946e783821ce9a79866e13f920ec02a092f31
$ fossil co trunk
fossil: object [ed9081561d] is not a check-in
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
