|
1
|
<title>The Fossil Web Interface</title> |
|
2
|
|
|
3
|
One of the innovative features of Fossil is its built-in web interface. |
|
4
|
This web interface provides everything you need to run a software |
|
5
|
development project: |
|
6
|
|
|
7
|
* [./bugtheory.wiki | Ticketing and bug tracking] |
|
8
|
* [./wikitheory.wiki | Wiki] |
|
9
|
* [./embeddeddoc.wiki | On-line documentation] |
|
10
|
* [./event.wiki | Technical notes] |
|
11
|
* [./forum.wiki | Forum] |
|
12
|
* [./chat.md | Chatroom] |
|
13
|
* Timelines |
|
14
|
* Full text search over all of the above |
|
15
|
* Status information |
|
16
|
* Graphs of revision and branching history |
|
17
|
* File and version lists and differences |
|
18
|
* Download historical versions as ZIP archives |
|
19
|
* Historical change data |
|
20
|
* Add and remove tags on check-ins |
|
21
|
* Move check-ins between branches |
|
22
|
* Revise check-in comments |
|
23
|
* Manage user credentials and access permissions |
|
24
|
* And so forth... (some [./webpage-ex.md|examples]) |
|
25
|
|
|
26
|
You get all of this, and more, for free when you use Fossil. |
|
27
|
There are no extra programs to install or setup. |
|
28
|
Everything you need is already pre-configured and built into the |
|
29
|
self-contained, stand-alone Fossil executable. |
|
30
|
|
|
31
|
As an example of how useful this web interface can be, |
|
32
|
the entire [./index.wiki | Fossil website], |
|
33
|
including the document you are now reading, |
|
34
|
is rendered using the Fossil web interface, with no enhancements, |
|
35
|
and little customization. |
|
36
|
|
|
37
|
<div class="indent"> |
|
38
|
<b>Key point:</b> <i>The Fossil website is just a running instance |
|
39
|
of Fossil! |
|
40
|
</div> |
|
41
|
|
|
42
|
Note also that because Fossil is a distributed system, you can run |
|
43
|
the web interface on your local machine while off network (for example, |
|
44
|
while on an airplane) including |
|
45
|
making changes to wiki pages and/or trouble ticket, then synchronize with your |
|
46
|
co-workers after you reconnect. When you clone a Fossil repository, you |
|
47
|
don't just get the project source code, you get the entire project |
|
48
|
management website. |
|
49
|
|
|
50
|
<h2>Very Simple Startup</h2> |
|
51
|
|
|
52
|
To start using the built-in Fossil web interface on an existing Fossil |
|
53
|
repository, simply type this: |
|
54
|
|
|
55
|
<pre>fossil ui existing-repository.fossil</pre> |
|
56
|
|
|
57
|
Substitute the name of your repository, of course. |
|
58
|
The "ui" command will start a web server running (it figures out an |
|
59
|
available TCP port to use on its own) and then automatically launches |
|
60
|
your web browser to point at that server. If you run the "ui" command |
|
61
|
from within an open check-out, you can omit the repository name: |
|
62
|
|
|
63
|
<pre>fossil ui</pre> |
|
64
|
|
|
65
|
The latter case is a very useful short-cut when you are working on a |
|
66
|
Fossil project and you want to quickly do some work with the web interface. |
|
67
|
Notice that Fossil automatically finds an unused TCP port to run the |
|
68
|
server on and automatically points your web browser to the correct |
|
69
|
URL. So there is never any fumbling around trying to find an open |
|
70
|
port or to type arcane strings into your browser URL entry box. |
|
71
|
The interface just pops right up, ready to run. |
|
72
|
|
|
73
|
The Fossil web interface is also very easy to setup and run on a |
|
74
|
network server, as either a CGI program or from inetd, or as an |
|
75
|
SCGI server. Details on how |
|
76
|
to do that are described further below. |
|
77
|
|
|
78
|
<h2>Things To Do Using The Web Interface</h2> |
|
79
|
|
|
80
|
You can view <b>timelines</b> of changes to the project. The default |
|
81
|
"Timeline" link on the menu bar takes you to a page that shows the 20 |
|
82
|
most recent check-ins, wiki page edits, ticket/bug-report changes, |
|
83
|
and/or blog entries. |
|
84
|
This gives a very useful snapshot of what has been happening lately on the |
|
85
|
project. You can click to go further back in time, if needed. Or |
|
86
|
follow hyperlinks to see details, including diffs and annotated diffs, |
|
87
|
of individual check-ins, wiki page edits, ticket changes, and |
|
88
|
blog edits. |
|
89
|
|
|
90
|
You can view and edit <b>tickets and bug reports</b> by following the |
|
91
|
"Tickets" link on the menu bar. |
|
92
|
Fossil is backed by an SQL database, so users with appropriate permissions |
|
93
|
can write new ticket report formats based on SQL query statements. |
|
94
|
Fossil is careful to prevent ticket report formats from doing any mischief |
|
95
|
on the database (it only allows SELECT statements to run) and it restricts |
|
96
|
access to sensitive data such as user passwords. So it is actually safe |
|
97
|
to let anonymous users on the internet write their own ticket formats if |
|
98
|
you like. In addition to viewing and/or creating report formats, you can |
|
99
|
also create new tickets or look at summaries or complete histories of |
|
100
|
existing tickets. Any changes you make will automatically merge with |
|
101
|
changes from your co-workers the next time your repository is synchronized. |
|
102
|
|
|
103
|
You can view and edit <b>wiki</b> by following the "Wiki" link on the |
|
104
|
menu bar. Fossil has its own easy-to-remember |
|
105
|
[/wiki_rules | markup rules], or if you prefer, it also |
|
106
|
supports [/md_rules | Markdown]. And, as with tickets, all of |
|
107
|
your edits will automatically merge with those of your co-workers when |
|
108
|
your repository synchronizes. |
|
109
|
|
|
110
|
You can view summary reports of <b>branches</b> in the |
|
111
|
check-in graph by visiting the "Branches" link on the |
|
112
|
menu bar. From those pages you can follow hyperlinks to get additional |
|
113
|
details. These screens allow you to easily keep track of what is going |
|
114
|
on with separate sub-teams within your project team. |
|
115
|
|
|
116
|
The "Files" link on the menu allows you to browse through the <b>file |
|
117
|
hierarchy</b> of the project and to view complete changes histories on |
|
118
|
individual files, with hyperlinks to the check-ins that made those |
|
119
|
changes, and with diffs and annotated diffs between versions. |
|
120
|
|
|
121
|
The web interface supports [./embeddeddoc.wiki | embedded documentation] |
|
122
|
files (usually in wiki format) that are checked into the project as |
|
123
|
part of the source tree. Such files can be viewed as if they were |
|
124
|
ordinary web pages. This document that you are now reading is an |
|
125
|
example of embedded documentation. |
|
126
|
|
|
127
|
<h2>Customizing The Web Interface Appearance</h2> |
|
128
|
|
|
129
|
Users with appropriate permissions can customize the look and feel of |
|
130
|
the web interface using the "Admin" link on the main menu of the web |
|
131
|
interface. Templates |
|
132
|
for the header and footer of each page can be edited, as can the CSS |
|
133
|
for the entire page. You can even change around the main menu. |
|
134
|
Timeline display preferences can be edited. The page that is brought |
|
135
|
up as the "Home" page can be changed. It is often useful to set the |
|
136
|
"Home" page to be a wiki page or an embedded document. The built-in |
|
137
|
pages <b>/home</b> and <b>/index</b> can be used as the "Home" page. |
|
138
|
They have identical effect, which is to instruct Fossil to find and |
|
139
|
display a wiki page with the same name as the project, or if that |
|
140
|
does not exist, <b>/README.md</b> or <b>/index.wiki</b>. |
|
141
|
|
|
142
|
An embedded document link such as <b>doc/trunk/README.md</b> can be |
|
143
|
used for the "Home" page. If you specify one of the built-in keywords |
|
144
|
<b>/home</b> or <b>/index</b>, the page will not be treated as an |
|
145
|
embedded document. |
|
146
|
|
|
147
|
<h2>Installing On A Network Server</h2> |
|
148
|
|
|
149
|
When you create a new Fossil project and after you have configured it |
|
150
|
like you want it using the web interface, you can make the project |
|
151
|
available to a distributed team by simply copying the single |
|
152
|
repository file up to a web server that supports CGI or SCGI. To |
|
153
|
run Fossil as CGI, just put the |
|
154
|
<b>sample-project.fossil</b> file in a directory where CGI scripts |
|
155
|
have both read and write permission on the file and the directory that |
|
156
|
contains the file, then add a CGI script that looks something like this: |
|
157
|
|
|
158
|
<verbatim>#!/usr/local/bin/fossil |
|
159
|
repository: /home/www/sample-project.fossil</verbatim> |
|
160
|
|
|
161
|
Adjust the script above so that the paths are correct for your system, |
|
162
|
of course, and also make sure the Fossil binary is installed on the server. |
|
163
|
But that is <u>all</u> you have to do. You now have everything you need to host |
|
164
|
a distributed software development project in less than five minutes using a |
|
165
|
two-line CGI script. |
|
166
|
|
|
167
|
Instructions for setting up an SCGI server are |
|
168
|
[./scgi.wiki | available separately]. |
|
169
|
|
|
170
|
You don't have a CGI- or SCGI-capable web server running on your |
|
171
|
server machine? |
|
172
|
Not a problem. The Fossil interface can also be launched via inetd or |
|
173
|
xinetd. An inetd configuration line sufficient to launch the Fossil |
|
174
|
web interface looks like this: |
|
175
|
|
|
176
|
<verbatim>80 stream tcp nowait.1000 root /usr/local/bin/fossil \ |
|
177
|
/usr/local/bin/fossil http /home/www/sample-project.fossil</verbatim> |
|
178
|
|
|
179
|
As always, you'll want to adjust the pathnames to whatever is appropriate |
|
180
|
for your system. The xinetd setup uses a different syntax but follows |
|
181
|
the same idea. |
|
182
|
|