Check-in [5c65487c5f]
Not logged in
Overview

SHA1 Hash:5c65487c5f5cfc8970a4fdd8ad6b2d400faefe7c
Date: 2009-01-25 23:30:07
User: drh
Comment:Add documentation (advocacy-type documentation) on the fossil web interface. Created links from the homepage.
Timelines: ancestors | descendants | both | trunk
Other Links: files | ZIP archive | manifest

Tags And Properties
Changes
[hide diffs]

Modified www/embeddeddoc.wiki from [b0c6d59681] to [f65cddb5e8].

@@ -1,6 +1,6 @@
-<h1>Managing Project Documentation</h1>
+<h1 align="center">Managing Project Documentation</h1>
 
 Fossil provides a built-in <a href="wikitheory.wiki">wiki</a>
 that can be used to store the
 documentation for a project.  This is sufficient for many projects.
 If your project is well-served by wiki documentation, then you
@@ -99,17 +99,29 @@
 This is one of three ways to set up a
 <a href="quickstart.wiki#serversetup">fossil web server</a>.
 
 The "<b>/tip/</b>" part of the URL tells fossil to use
 the documentation files from the check-in that was checked in most
-recently.  This file is stored in the fossil source tree under
+recently.  If you wanted to see an historical version of this document,
+you could substitute the name of a check-in for "<b>/tip/</b>".
+For example, to see the version of this document associated with
+check-in [9be1b00392], simply replace the "<b>/tip/</b>" with
+"<b>/9be1b00392/</b>".  You can also substitute the symbolic name
+for a particular version or branch.  For example, you might
+replace "<b>/tip/</b>" with "<b>/trunk/</b>" to get the latest
+version of this document in the "trunk" branch.  (As of this writing,
+the self-hosting fossil repository only has a single branch "trunk" and
+so "trunk" and "tip" amount to the same thing, but they would be different
+in a project with multiple branches.)
+
+The file that encodes this document is stored in the fossil source tree under
 the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the
-last part of the URL.
+last part of the URL for this document.
 
 As I sit writing this documentation file, I am testing my work by
 running the "<b>fossil server</b>" command line and viewing
 <b>http://localhost:8080/doc/ckout/www/embeddeddoc.wiki</b> in
 Firefox.  I am doing this even though I have not yet checked in
 the "<b>www/embeddeddoc.wiki</b>" file for the first time.  Using
 the special "<b>ckout</b>" version identifier on the "<b>/doc</b>" page
 it is easy to make multiple changes to multiple files and see how they all
 look together before committing anything to the repository.

Modified www/index.wiki from [2046c07523] to [786913c0b4].

@@ -28,14 +28,13 @@
       <a href="http://subversion.tigris.org/">subversion</a>,
     <li>Or, operations on local repositories,
     <li>Or, all of the above at the same time</ul>
   *  Integrated, [./bugtheory.wiki | distributed bug tracking] and
      [./wikitheory.wiki | distributed wiki].
-  *  Built-in web interface that supports deep archaeological digs through
-     the project history.
-  *  All network communication via
-     [http://en.wikipedia.org/wiki/HTTP | HTTP] with
+  *  Built-in [./webui.wiki | web interface] that supports deep
+     archaeological digs through the project history.
+  *  All network communication via HTTP with
      [./quickstart.wiki#proxy | proxy support]
      so that everything works from behind restrictive firewalls.
   *  Everything (client, server, and utilities) is included in a
      single self-contained executable - trivial to install
   *  Server runs as [./quickstart.wiki#cgiserver | CGI], using
@@ -55,12 +54,14 @@
 
 <b>User Links:</b>
 
   *  [./faq.wiki | FAQ]
   *  The [./concepts.wiki | concepts] behind fossil
-  *  [./build.wiki | Building And Installing]
   *  [./quickstart.wiki | Quick Start] guide to using fossil
+  *  [./reviews.wiki | Testimonials] from fossil users.
+  *  [./qandc.wiki | Questions &amp; Criticisms] directed at fossil.
+  *  [./build.wiki | Building And Installing]
   *  Fossil supports [./embeddeddoc.wiki | embedded documentation]
      that is versioned along with project source code.
   *  A tutorial on [./branching.wiki | branching], what it means and how
      to do it using fossil.
   *  The [./selfcheck.wiki | automatic self-check] mechanism
@@ -67,12 +68,10 @@
      helps insure project integrity.
   *  Fossil contains a [./wikitheory.wiki | built-in wiki].
   *  There is a
     [http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users | mailing list]
      available for discussing fossil issues.
-  *  [./qandc.wiki | Questions &amp; Criticisms] directed at fossil.
-  *  [./reviews.wiki | Testimonials] from fossil users.
   *  Some (unfinished but expanding) extended
       [./reference.wiki | reference documentation] for the fossil command line.
 
 <b>Developer Links:</b>
 

Added www/webui.wiki version [5308e376e1]

@@ -1,1 +1,165 @@
+<h1 align="center">The Fossil Web Interface</h1>
+
+One of the innovative features of fossil is its built-in web interface.
+This web interface provides everything you need to run a software
+development project:
+
+  *  [./bugtheory.wiki | Ticketing and bug tracking]
+  *  [./wikitheory.wiki | Wiki]
+  *  [./embeddeddoc.wiki | On-line documentation]
+  *  Status information
+  *  Timelines
+  *  File and version lists and differences
+  *  Historical change data
+  *  Links to download historical versions as ZIP archives
+
+You get all of this, and more, for free when you use fossil.
+There are no extra programs to install or setup.
+Everything you need is already pre-configured and built into the
+self-contained, stand-alone fossil executable.
+
+As an example of how useful this web interface can be,
+the entire [./index.wiki | fossil website] (except for the
+[http://www.fossil-scm.org/download.html | precompiled binary download page]),
+including the document you are now reading,
+is rendered using the stock fossil web interface, with no enhancements,
+and little customization.
+
+Note also that because fossil is a distribute system, you can run
+the web interface on your local machine while off network (for example,
+while on an airplane) including
+making changes to wiki pages and/or trouble ticket, then synchronize with your
+co-workers after you reconnect.
+
+<h2>Drop-Dead Simple Startup</h2>
+
+To start using the built-in fossil web interface on an existing fossil
+repository, simply type this:
+
+   <b>fossil ui existing-repository.fossil</b>
+
+Substitute the name of your repository, of course.
+The "ui" command will start a webserver running (it figures out an
+available TCP port to use on its own) and then automatically launches
+your web browser to point at that server.  If you run the "ui" command
+from within an open check-out, you can omit the repository name:
+
+  <b>fossil ui</b>
+
+The latter case is a very useful short-cut when you are working on a
+fossil project and what to quickly do some work with the interface.
+Notice that fossil automatically finds an unused TCP port to run the
+server own and automatically points your web browser to the correct
+URL.  So there is never any fumbling around trying to find an open
+port or to type arcane strings into your browser URL entry box.
+The interface just pops right up, ready to run.
+
+The fossil web interface is also very easy to setup and run on a
+network server, as either a CGI program or from inetd.  Details on how
+to do that are described further below.
+
+<h2>Things To Do Using The Web Interface</h2>
+
+You can view <b>timelines</b> of changes to the project.  The default
+"Timeline" link on the menu bar takes you to a page that shows the 20
+most recent check-ins, wiki page edits, and ticket/bug-report changes.
+This gives a very useful snapshot of what has been happening lately on the
+project.  You can click to go further back in time, if needed.  Or
+follow hyperlinks to see details, including diffs and annotated diffs,
+of individual check-ins, wiki page edits, or ticket changes.
+
+You can view and edit <b>tickets and bug reports</b> by following the
+"Tickets" link on the menu bar.
+Fossil is backed by an SQL database, so users with appropriate permissions
+can write new ticket report formats based on SQL query statements.
+Fossil is careful to prevent ticket report formats from doing any mischief
+on the database (it only allows SELECT statements to run) and it restricts
+access to sensitive data such as user passwords.  So it is actually safe
+to let anonymous users on the internet write their own ticket formats if
+you like.  In addition to viewing and/or creating report formats, you can
+also create new tickets or look at summaries or complete histories of
+existing tickets.  Any changes you make will automatically merge with
+changes from your co-workers the next time your repository is synchronized.
+
+You can view and edit <b>wiki</b> by following the "Wiki" link on the
+menu bar.  Fossil uses simple and easy-to-remember
+[/wiki_rules | wiki formatting rules] so you won't have to spend a lot
+of time learning a new markup language.  And, as with tickets, all of
+your edits will automatically merge with those of your co-workers when
+your repository synchronizes.
+
+You can view summary reports of <b>leaves and branches</b> in the
+check-in graph by visiting the "Leaves" or "Branches" links on the
+menu bar.  From those pages you can follow hyperlinks to get additional
+details.  These screens allow you to easily keep track of what is going
+on with separate subteams within your project team.
+
+The "Files" link on the menu allows you to browse though the <b>file
+hierarchy</b> of the project and to view complete changes histories on
+individual files, with hyperlinks to the check-ins that made those
+changes, and with diffs and annotated diffs between versions.
+
+The web interface supports [./embeddeddoc.wiki | embedded documentation].
+Embedded documentation is documentation files (usually in wiki format)
+that are checked into project as part of the source tree.  Such files
+can be viewed as if they were ordinary web pages.  This document that
+you are now reading is an example of embedded documentation.
+
+<h2>Customizing The Web Interface Appearance</h2>
+
+Users with appropriate permissions can customize the look and feel of
+the web interface using the "Admin" link on the main menu of the web
+interface.  Templates
+for the header and footer of each page can be edited, as can the CSS
+for the entire page.  You can even change around the main menu.
+Timeline display preferences can be edited.  The page that is brought
+up as the "Home" page can be changed.  It is often useful to set the
+"Home" page to be a wiki page or an embedded document.
+
+<h2>Installing On A Network Server</h2>
+
+When you create a new fossil project and after you have configured it
+like you want it using the web interface, you can make the project
+available to a distributed team by simply copying the single
+repository file up to a web server that supports CGI.  Just put the
+<b>sample-project.fossil</b> file in a directory where CGI scripts
+have both read and write permission on the file and the directory that
+contains the file, then add a CGI script that looks something like this:
+
+  <verbatim>
+  #!/usr/local/bin/fossil
+  repository: /home/www/sample-project.fossil
+  </verbatim>
+
+Adjust the script above so that the paths are correct for your system,
+of course, and also make sure the fossil binary is installed on the server.
+But that is <u>all</u> you have to do.  You now have everything you need to host
+a distributed software development project in less than five minutes using a
+two-line CGI script.
+
+You don't have a CGI-capable web server running on your server machine?
+Not a problem.  The fossil interface can also be launched via inetd or
+xinetd.  An inetd configuration line sufficient to launch the fossil
+web interface looks like this:
+
+  <verbatim>
+  80 stream tcp nowait.1000 root /usr/local/bin/fossil \
+  /usr/local/bin/fossil http /home/www/sample-project.fossil
+  </verbatim>
+
+As always, you'll want to adjust the pathnames to whatever is appropriate
+for your system.  The xinetd setup uses a different syntax but follows
+the same idea.
+
+Once you have your new repository running on the network server, delete
+the original repository from your local machine, then clone the repository
+off of the server:
+
+  <b>fossil clone http://user:password@myserver.org/cgi-bin/my-project</b>
 
+(As always, adjust the URL as appropriate for your installation.)
+After copying a repository, it is important to reclone it onto new machines.
+Each repository has a random "repository ID" and repositories will not
+sync with another repository having the same ID (to avoid sync loops).
+Cloning the repository will give you a new repository ID in your local
+copy and allow you to sync with the server.