Re: [fossil-users] Proposed Change To Wiki vs. HTML

2010-07-27 Thread renework
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] Fossil gui progress

2010-07-27 Thread Stephen De Gabrielle
Looks great!

On Friday, July 23, 2010, Sergey Volkov s...@mooby.org wrote:
 Hi guys!

 I just want to show my progress with creation of Fossil GUI.
 I'm new in creation GUI programs, most time i work on websites.
 So this is screenshots:
 Fossil | 
 117237909801520996711 http://picasaweb.google.com/117237909801520996711/Fossil#

 It works on Ubuntu with Ruby GTK, not really useful right now, but i
 work on it.

 Best regards!

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


-- 

--
Stephen De Gabrielle
stephen.degabrie...@acm.org
Telephone +44 (0)20 85670911
Mobile+44 (0)79 85189045
http://www.degabrielle.name/stephen
___
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-users Digest, Vol 30, Issue 23

2010-07-27 Thread Benjohn Barnes

On 27 Jul 2010, at 11:37, Zed wrote:

 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.

Is it not sufficient to simply have a link in the the existing wiki to the 
generated documentation? The site wouldn't have a single style then though… are 
there other drawbacks?

-- 
benj...@fysh.org - Twitter @benjohnbarnes - Skype benjohnbarnes - Mobile +44 
(0) 7968 851 636

___
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] Hosted fossil solution

2010-07-27 Thread James Turner
Alright well I finally managed to sit down over the weekend and get something 
up and running. You can check out the web app at:

http://chiselapp.com

You can currently create an account, create new repositories as well as clone 
existing ones. Repositories are served up like:

https://chiselapp.com/user/james/repository/fossil

Currently I'm limiting 5 repositories per account, everything should be 
considered in an alpha state, but so far everything seems to be running 
smoothly. Let me know if you run into any issues or have suggestions. Thanks.

On Jul 21, 2010, at 1:08 PM, Richard Hipp wrote:

 
 
 On Wed, Jul 21, 2010 at 12:53 PM, James Turner ja...@calminferno.net wrote:
 I'm currently playing around with the idea and code for a hosted fossil
 solution. Since each fossil repository already has everything you would
 need, the solution would be more of a fossil repository management tool
 on the web, that would let you create/manage repositories and provide a
 mechanism to serve them (still working on the best solution for this
 part).
 
 I was just wondering if this is a service that people might find useful?
 
 As you have observed, Fossil strives to be a hosted-solution-in-a-box.  
 Just add the host and you are ready to roll.  So I'm thinking that the hosted 
 Fossil idea is not nearly as useful as GitHub, since the distance between raw 
 Fossil and your hosted solution is far less than the distance from raw git to 
 GitHub.
 
 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.
 
 Please keep us posted of your progress!
 
  
 I'm still hashing out my ideas and currently have very basic code up and
 running (creating/deleting/account mgmt). Since everything is
 distributed within fossil there isn't any kind of lockin, so it's more
 of a way to remove the small overhead of setting up a fossil repository
 somewhere.
 
 Feel free to let me know what you all think, or maybe point me to a
 solution that already exists? Thanks.
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
 
 
 
 -- 
 -
 D. Richard Hipp
 d...@sqlite.org
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
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] Hosted fossil solution

2010-07-27 Thread Richard Hipp
On Tue, Jul 27, 2010 at 10:15 PM, James Turner ja...@calminferno.netwrote:

 Alright well I finally managed to sit down over the weekend and get
 something up and running. You can check out the web app at:

 http://chiselapp.com

 You can currently create an account, create new repositories as well as
 clone existing ones. Repositories are served up like:

 https://chiselapp.com/user/james/repository/fossil

 Currently I'm limiting 5 repositories per account, everything should be
 considered in an alpha state, but so far everything seems to be running
 smoothly. Let me know if you run into any issues or have suggestions.
 Thanks.


Very nice.  Thanks for this!

I added a link to Chisel from the Fossil homepage.  Will the mirror of
Fossil that you have on Chisel automatically sync at some point?  Do you
have a cron job that does that?  How does that work?



 On Jul 21, 2010, at 1:08 PM, Richard Hipp wrote:



 On Wed, Jul 21, 2010 at 12:53 PM, James Turner ja...@calminferno.netwrote:

 I'm currently playing around with the idea and code for a hosted fossil
 solution. Since each fossil repository already has everything you would
 need, the solution would be more of a fossil repository management tool
 on the web, that would let you create/manage repositories and provide a
 mechanism to serve them (still working on the best solution for this
 part).

 I was just wondering if this is a service that people might find useful?


 As you have observed, Fossil strives to be a hosted-solution-in-a-box.
 Just add the host and you are ready to roll.  So I'm thinking that the
 hosted Fossil idea is not nearly as useful as GitHub, since the distance
 between raw Fossil and your hosted solution is far less than the distance
 from raw git to GitHub.

 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.

 Please keep us posted of your progress!



 I'm still hashing out my ideas and currently have very basic code up and
 running (creating/deleting/account mgmt). Since everything is
 distributed within fossil there isn't any kind of lockin, so it's more
 of a way to remove the small overhead of setting up a fossil repository
 somewhere.

 Feel free to let me know what you all think, or maybe point me to a
 solution that already exists? Thanks.
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




 --
 -
 D. Richard Hipp
 d...@sqlite.org
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
-
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


Re: [fossil-users] [PATCH] Reimplementation of the reconstruct command that went missing

2010-07-27 Thread Brian Smith
Hi,

I've created the following ticket for this patch:
http://www.fossil-scm.org/index.html/info/dfe1fc608a

Thanks,

-B

On Sun, Jul 11, 2010 at 8:49 PM, Brian Smith br...@linuxfood.net wrote:
 Hi All,

 During the move from GPL to BSD, the 'reconstruct' command went missing.
 I assume this was due to licensing issues. I've re-implemented it, since, my
 git-import tool depends on it. This implementation is black box.
 I've not examined
 the original source for reconstruct at all.

 At the moment, it's in rebuild.c, since that seemed to be the most
 sensible place for it.
 I've not done a reimplementation of deconstruct, though, it would be
 fairly trivial to do so.

 If this is acceptable and can be accepted into trunk immediately, then great.
 Otherwise, please let me know of any stylistic/functional changes
 needed to do so.

 Either way, I'm prepared to send in copyright release.

 -B

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users