41 41 <li><a href=makeheaders.html#H0014>3.8 Caveats</a>
42 42 </ul>
43 43 <li><a href=makeheaders.html#H0015>4.0 Using Makeheaders To Generate Documentation</a>
44 44 45 45 <li><a href=makeheaders.html#H0016>5.0 Compiling The Makeheaders Program</a>
46 46 47 47 <li><a href=makeheaders.html#H0017>6.0 Summary And Conclusion</a>
48 -</ul><a name=H0002> 48 +</ul><a name="H0002"></a> 49 49 <h2>1.0 Background</h2>
50 50 51 51 <p>
52 52 A piece of C source code can be one of two things:
53 53 a <em>declaration</em> or a <em>definition</em>.
54 54 A declaration is source text that gives information to the
55 55 compiler but doesn't directly result in any code being generated.
................................................................................ 96 96 The .c files contain ``<code>#include</code>'' preprocessor statements
97 97 that cause the contents of .h files to be included as part of the
98 98 source code when the .c file is compiled.
99 99 In this way, the .h files define the interface to a subsystem and
100 100 the .c files define how the subsystem is implemented.
101 101 </p>
102 102 103 -<a name=H0003> 103 +<a name="H0003"></a> 104 104 <h3>1.1 Problems With The Traditional Approach</h3>
105 105 106 106 <p>
107 107 As the art of computer programming continues to advance, and the size
108 108 and complexity of programs continues to swell, the traditional C
109 109 approach of placing declarations and definitions in separate files begins
110 110 to present the programmer with logistics and
................................................................................ 150 150 In a program with complex, interwoven data structures, the correct
151 151 declaration order can become very difficult to determine manually,
152 152 especially when the declarations involved are spread out over several
153 153 files.
154 154 </ol>
155 155 </p>
156 156 157 -<a name=H0004> 157 +<a name="H0004"></a> 158 158 <h3>1.2 The Makeheaders Solution</h3>
159 159 160 160 <p>
161 161 The makeheaders program is designed to ameliorate the problems associated
162 162 with the traditional C programming model by automatically generating
163 163 the interface information in the .h files from
164 164 interface information contained in other .h files and
................................................................................ 213 213 so that makeheaders will be run automatically whenever the project
214 214 is rebuilt.
215 215 And the burden of running makeheaders is light.
216 216 It will easily process tens of thousands of lines of source
217 217 code per second.
218 218 </p>
219 219 220 -<a name=H0005> 220 +<a name="H0005"></a> 221 221 <h2>2.0 Running The Makeheaders Program</h2>
222 222 223 223 <p>
224 224 The makeheaders program is very easy to run.
225 225 If you have a collection of C source code and include files in the working
226 226 directory, then you can run makeheaders to generate appropriate .h
227 227 files using the following command:
................................................................................ 361 361 you can prepend a ``./'' to its name in order to get it
362 362 accepted by the command line parser.
363 363 Or, you can insert the special option ``--'' on the command
364 364 line to cause all subsequent command line arguments to be treated as
365 365 filenames even if their names beginn with ``-''.
366 366 </p>
367 367 368 -<a name=H0006> 368 +<a name="H0006"></a> 369 369 <h2>3.0 Preparing Source Files For Use With Makeheaders</h2>
370 370 371 371 <p>
372 372 Very little has to be done to prepare source files for use with
373 373 makeheaders since makeheaders will read and understand ordinary
374 374 C code.
375 375 But it is important that you structure your files in a way that
376 376 makes sense in the makeheaders context.
377 377 This section will describe several typical uses of makeheaders.
378 378 </p>
379 379 380 -<a name=H0007> 380 +<a name="H0007"></a> 381 381 <h3>3.1 The Basic Setup</h3>
382 382 383 383 <p>
384 384 The simpliest way to use makeheaders is to put all definitions in
385 385 one or more .c files and all structure and type declarations in
386 386 separate .h files.
387 387 The only restriction is that you should take care to chose basenames
................................................................................ 472 472 those entered manually be the programmer and others generated automatically
473 473 by a prior run of makeheaders.
474 474 But that is not a problem.
475 475 The makeheaders program will recognize and ignore any files it
476 476 has previously generated that show up on its input list.
477 477 </p>
478 478 479 -<a name=H0008> 479 +<a name="H0008"></a> 480 480 <h3>3.2 What Declarations Get Copied</h3>
481 481 482 482 <p>
483 483 The following list details all of the code constructs that makeheaders
484 484 will extract and place in
485 485 the automatically generated .h files:
486 486 </p>
................................................................................ 575 575 As a final note, we observe that automatically generated declarations
576 576 are ordered as required by the ANSI-C programming language.
577 577 If the declaration of some structure ``X'' requires a prior
578 578 declaration of another structure ``Y'', then Y will appear
579 579 first in the generated headers.
580 580 </p>
581 581 582 -<a name=H0009> 582 +<a name="H0009"></a> 583 583 <h3>3.3 How To Avoid Having To Write Any Header Files</h3>
584 584 585 585 <p>
586 586 In my experience, large projects work better if all of the manually
587 587 written code is placed in .c files and all .h files are generated
588 588 automatically.
589 589 This is slightly different for the traditional C method of placing
................................................................................ 642 642 ``#if INTERFACE'' regions of .c files.
643 643 Makeheaders treats all declarations alike, no matter where they
644 644 come from.
645 645 You should also note that a single .c file can contain as many
646 646 ``#if INTERFACE'' regions as desired.
647 647 </p>
648 648 649 -<a name=H0010> 649 +<a name="H0010"></a> 650 650 <h3>3.4 Designating Declarations For Export</h3>
651 651 652 652 <p>
653 653 In a large project, one will often construct a hierarchy of
654 654 interfaces.
655 655 For example, you may have a group of 20 or so files that form
656 656 a library used in several other parts of the system.
................................................................................ 731 731 The ``#if EXPORT_INTERFACE'' mechanism can be used in either
732 732 .c or .h files.
733 733 (The ``#if INTERFACE'' can also be used in both .h and .c files,
734 734 but since it's use in a .h file would be redundant, we haven't mentioned
735 735 it before.)
736 736 </p>
737 737 738 -<a name=H0011> 738 +<a name="H0011"></a> 739 739 <h3>3.5 Local declarations processed by makeheaders</h3>
740 740 741 741 <p>
742 742 Structure declarations and typedefs that appear in .c files are normally
743 743 ignored by makeheaders.
744 744 Such declarations are only intended for use by the source file in which
745 745 they appear and so makeheaders doesn't need to copy them into any
................................................................................ 769 769 A ``LOCAL_INTERFACE'' block works very much like the
770 770 ``INTERFACE'' and ``EXPORT_INTERFACE''
771 771 blocks described above, except that makeheaders insures that the
772 772 objects declared in a LOCAL_INTERFACE are only visible to the
773 773 file containing the LOCAL_INTERFACE.
774 774 </p>
775 775 776 -<a name=H0012> 776 +<a name="H0012"></a> 777 777 <h3>3.6 Using Makeheaders With C++ Code</h3>
778 778 779 779 <p>
780 780 You can use makeheaders to generate header files for C++ code, in
781 781 addition to C.
782 782 Makeheaders will recognize and copy both ``class'' declarations
783 783 and inline function definitions, and it knows not to try to generate
................................................................................ 868 868 869 869 <p>
870 870 Makeheaders does not understand more recent
871 871 C++ syntax such as templates and namespaces.
872 872 Perhaps these issued will be addressed in future revisions.
873 873 </p>
874 874 875 -<a name=H0013> 875 +<a name="H0013"></a> 876 876 <h3>3.7 Conditional Compilation</h3>
877 877 878 878 <p>
879 879 The makeheaders program understands and tracks the conditional
880 880 compilation constructs in the source code files it scans.
881 881 Hence, if the following code appears in a source file
882 882 <pre>
................................................................................ 901 901 <pre>
902 902 #if 0
903 903 #endif
904 904 </pre>
905 905 and treats the enclosed text as a comment.
906 906 </p>
907 907 908 -<a name=H0014> 908 +<a name="H0014"></a> 909 909 <h3>3.8 Caveats</h3>
910 910 911 911 <p>
912 912 The makeheaders system is designed to be robust
913 913 but it is possible for a devious programmer to fool the system,
914 914 usually with unhelpful consequences.
915 915 This subsection is a guide to helping you avoid trouble.
................................................................................ 971 971 For most projects the code constructs that makeheaders cannot
972 972 handle are very rare.
973 973 As long as you avoid excessive cleverness, makeheaders will
974 974 probably be able to figure out what you want and will do the right
975 975 thing.
976 976 </p>
977 977 978 -<a name=H0015> 978 +<a name="H0015"></a> 979 979 <h2>4.0 Using Makeheaders To Generate Documentation</h2>
980 980 981 981 <p>
982 982 Many people have observed the advantages of generating program
983 983 documentation directly from the source code:
984 984 <ul>
985 985 <li> Less effort is involved. It is easier to write a program than
................................................................................ 1035 1035 <li> The complete text of a declaration for the object.
1036 1036 </ul>
1037 1037 The exact output format will not be described here.
1038 1038 It is simple to understand and parse and should be obvious to
1039 1039 anyone who inspects some sample output.
1040 1040 </p>
1041 1041 1042 -<a name=H0016> 1042 +<a name="H0016"></a> 1043 1043 <h2>5.0 Compiling The Makeheaders Program</h2>
1044 1044 1045 1045 <p>
1046 1046 The source code for makeheaders is a single file of ANSI-C code,
1047 1047 less than 3000 lines in length.
1048 1048 The program makes only modest demands of the system and C library
1049 1049 and should compile without alteration on most ANSI C compilers
1050 1050 and on most operating systems.
1051 1051 It is known to compile using several variations of GCC for Unix
1052 1052 as well as Cygwin32 and MSVC 5.0 for Win32.
1053 1053 </p>
1054 1054 1055 -<a name=H0017> 1055 +<a name="H0017"></a> 1056 1056 <h2>6.0 Summary And Conclusion</h2>
1057 1057 1058 1058 <p>
1059 1059 The makeheaders program will automatically generate a minimal header file
1060 1060 for each of a set of C source and header files, and will
1061 1061 generate a composite header file for the entire source file suite,
1062 1062 for either internal or external use.

1 1 <title>Check-in Names</title>
2 2 3 -Many Fossil commands and [./webui.wiki | web-interface] URLs accept 4 -check-in names as an argument. For example, the "info" command 3 +Many Fossil [/help|commands] and [./webui.wiki | web-interface] URLs accept 4 +check-in names as an argument. For example, the "[/help/info|info]" command 5 5 accepts an optional check-in name to identify the specific checkout
6 6 about which information is desired:
7 7 8 8 <blockquote>
9 9 <tt>fossil info</tt> <i>checkin-name</i>
10 10 </blockquote>
11 11 ................................................................................ 108 108 The space between the day and the year can optionally be
109 109 replaced by an uppercase <b>T</b> and the entire timestamp can
110 110 optionally be followed by "<b>utc</b>".
111 111 112 112 In its default configuration, Fossil interprets and displays all dates
113 113 in Universal Coordinated Time (UTC). This tends to work the best for
114 114 distributed projects where participants are scattered around the globe.
115 -But there is an open on the Admin/Timeline page of the web-interface to 115 +But there is an option on the Admin/Timeline page of the web-interface to 116 116 switch to local time. The "<b>utc</b>" suffix on an timestamp check-in
117 117 name is meaningless if Fossil is in the default mode of using UTC for
118 118 everything, but if Fossil has been switched to localtime mode, then the
119 119 "<b>utc</b>" suffix means to interpret that particular timestamp using
120 120 UTC instead localtime.
121 121 122 122 As an example, consider the homepage for the Fossil website itself:

Changes to www/faq.tcl.

7 7 set ::faq($::cnt) [list [string trim $question] [string trim $answer]]
8 8 incr ::cnt
9 9 }
10 10 11 11 faq {
12 12 What GUIs are available for fossil?
13 13 } {
14 - The fossil executable comes with a web-based GUI built in. Just run: 14 + The fossil executable comes with a [./webui.wiki | web-based GUI] built in. 15 + Just run: 15 16 16 17 <blockquote>
17 - <b>fossil ui</b> <i>REPOSITORY-FILENAME</i> 18 + <b>fossil [/help/ui|ui]</b> <i>REPOSITORY-FILENAME</i> 18 19 </blockquote>
19 20 20 21 And your default web browser should pop up and automatically point to
21 22 the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
22 23 if you are within an open check-out.)
23 24 }
24 25 ................................................................................ 28 29 This is a big question - too big to answer in a FAQ. Please
29 30 read the <a href="branching.wiki">Branching, Forking, Merging,
30 31 and Tagging</a> document.
31 32 }
32 33 33 34 34 35 faq {
35 - How do I create a new branch in fossil? 36 + How do I create a new branch? 36 37 } {
37 38 There are lots of ways:
38 39 39 - When you are checking in a new change using the <b>commit</b> 40 + When you are checking in a new change using the <b>[/help/commit|commit]</b> 40 41 command, you can add the option "--branch <i>BRANCH-NAME</i>" to
41 - make the change be the founding check-in for a new branch. You can 42 + make the new check-in be the first check-in for a new branch. You can 42 43 also add the "--bgcolor <i>COLOR</i>" option to give the branch a
43 44 specific background color on timelines.
44 45 45 - If you want to create a new branch whose founding check-in is the 46 + If you want to create a new branch whose initial content is the 46 47 same as an existing check-in, use this command:
47 48 48 49 <blockquote>
49 - <b>fossil branch new</b> <i>BRANCH-NAME BASIS</i> 50 + <b>fossil [/help/branch|branch] new</b> <i>BRANCH-NAME BASIS</i> 50 51 </blockquote>
51 52 52 53 The <i>BRANCH-NAME</i> argument is the name of the new branch and the
53 54 <i>BASIS</i> argument is the name of the check-in that the branch splits
54 55 off from.
55 56 56 57 If you already have a fork in your check-in tree and you want to convert
57 58 that fork to a branch, you can do this from the web interface.
58 59 First locate the check-in that you want to be
59 - the founding check-in of your branch on the timeline and click on its 60 + the initial check-in of your branch on the timeline and click on its 60 61 link so that you are on the <b>ci</b> page. Then find the "<b>edit</b>"
61 62 link (near the "Commands:" label) and click on that. On the
62 63 "Edit Check-in" page, check the box beside "Branching:" and fill in
63 64 the name of your new branch to the right and press the "Apply Changes"
64 65 button.
65 66 }
67 + 68 +faq { 69 + How do I tag a check-in? 70 +} { 71 + There are several ways: 72 + 73 + When you are checking in a new change using the <b>[/help/commit|commit]</b> 74 + command, you can add a tag to that check-in using the 75 + "--tag <i>TAGNAME</i>" command-line option. 76 + 77 + If you want add a tag to an existing check-in, you can use the 78 + <b>[/help/tag|tag]</b> command. For example: 79 + 80 + <blockquote> 81 + <b>fossil [/help/branch|tag] add</b> <i>TAGNAME</i> <i>CHECK-IN</i> 82 + </blockquote> 83 + 84 + The CHECK-IN in the previous line can be any 85 + [./checkin_names.wiki | valid check-in name format]. 86 + 87 + You can also add (and remove) tags from a check-in using the 88 + [./webui.wiki | web interface]. First locate the check-in that you 89 + what to tag on the tmline, then click on the link to go the detailed 90 + information page for that check-in. Then find the "<b>edit</b>" 91 + link (near the "Commands:" label) and click on that. There are 92 + controls on the edit page that allow new tags to be added and existing 93 + tags to be removed. 94 +} 66 95 67 96 faq {
68 97 How do I create a private branch that won't get pushed back to the
69 98 main repository.
70 99 } {
71 100 Use the <b>--private</b> command-line option on the
72 101 <b>commit</b> command. The result will be a check-in which exists on
................................................................................ 95 124 }
96 125 97 126 faq {
98 127 How do I make a clone of the fossil self-hosting repository?
99 128 } {
100 129 Any of the following commands should work:
101 130 <blockquote><pre>
102 - fossil clone http://www.fossil-scm.org/ fossil.fossil<br> 103 - fossil clone http://www2.fossil-scm.org/ fossil.fossil<br> 104 - fossil clone http://www.hwaci.com/cgi-bin/fossil fossil.fossil 131 + fossil [/help/clone|clone] http://www.fossil-scm.org/ fossil.fossil<br> 132 + fossil [/help/clone|clone] http://www2.fossil-scm.org/ fossil.fossil<br> 133 + fossil [/help/clone|clone] http://www3.fossli-scm.org/site.cgi fossil.fossil 105 134 </pre></blockquote>
106 135 Once you have the repository cloned, you can open a local check-out
107 136 as follows:
108 137 <blockquote><pre>
109 - mkdir src; cd src; fossil open ../fossil.fossil 138 + mkdir src; cd src; fossil [/help/open|open] ../fossil.fossil 110 139 </pre></blockquote>
111 140 Thereafter you should be able to keep your local check-out up to date
112 141 with the latest code in the public repository by typing:
113 142 <blockquote><pre>
114 - fossil update 143 + fossil [/help/update|update] 115 144 </pre></blockquote>
116 145 }
146 + 147 +faq { 148 + How do I import or export content from and to other version control systems? 149 +} { 150 + Please see [./inout.wiki | Import And Export] 151 +} 152 + 153 + 117 154 118 155 #############################################################################
119 156 # Code to actually generate the FAQ
120 157 #
121 158 puts "<title>Fossil FAQ</title>"
122 159 puts "<h1 align=\"center\">Frequently Asked Questions</h1>\n"
123 160 puts "<p>Note: See also <a href=\"qandc.wiki\">Questions and Criticisms</a>.\n"

Changes to www/faq.wiki.

2 2 <h1 align="center">Frequently Asked Questions</h1>
3 3 4 4 <p>Note: See also <a href="qandc.wiki">Questions and Criticisms</a>.
5 5 6 6 <ol>
7 7 <li><a href="#q1">What GUIs are available for fossil?</a></li>
8 8 <li><a href="#q2">What is the difference between a "branch" and a "fork"?</a></li>
9 -<li><a href="#q3">How do I create a new branch in fossil?</a></li> 10 -<li><a href="#q4">How do I create a private branch that won't get pushed back to the 9 +<li><a href="#q3">How do I create a new branch?</a></li> 10 +<li><a href="#q4">How do I tag a check-in?</a></li> 11 +<li><a href="#q5">How do I create a private branch that won't get pushed back to the 11 12 main repository.</a></li>
12 -<li><a href="#q5">How can I delete inappropriate content from my fossil repository?</a></li> 13 -<li><a href="#q6">How do I make a clone of the fossil self-hosting repository?</a></li> 13 +<li><a href="#q6">How can I delete inappropriate content from my fossil repository?</a></li> 14 +<li><a href="#q7">How do I make a clone of the fossil self-hosting repository?</a></li> 15 +<li><a href="#q8">How do I import or export content from and to other version control systems?</a></li> 14 16 </ol>
15 17 <hr>
16 18 <a name="q1"></a>
17 19 <p><b>(1) What GUIs are available for fossil?</b></p>
18 20 19 -<blockquote>The fossil executable comes with a web-based GUI built in. Just run: 21 +<blockquote>The fossil executable comes with a [./webui.wiki | web-based GUI] built in. 22 +Just run: 20 23 21 24 <blockquote>
22 -<b>fossil ui</b> <i>REPOSITORY-FILENAME</i> 25 +<b>fossil [/help/ui|ui]</b> <i>REPOSITORY-FILENAME</i> 23 26 </blockquote>
24 27 25 28 And your default web browser should pop up and automatically point to
26 29 the fossil interface. (Hint: You can omit the <i>REPOSITORY-FILENAME</i>
27 30 if you are within an open check-out.)</blockquote></li>
28 31 29 32 <a name="q2"></a>
................................................................................ 30 33 <p><b>(2) What is the difference between a "branch" and a "fork"?</b></p>
31 34 32 35 <blockquote>This is a big question - too big to answer in a FAQ. Please
33 36 read the <a href="branching.wiki">Branching, Forking, Merging,
34 37 and Tagging</a> document.</blockquote></li>
35 38 36 39 <a name="q3"></a>
37 -<p><b>(3) How do I create a new branch in fossil?</b></p> 40 +<p><b>(3) How do I create a new branch?</b></p> 38 41 39 42 <blockquote>There are lots of ways:
40 43 41 -When you are checking in a new change using the <b>commit</b> 44 +When you are checking in a new change using the <b>[/help/commit|commit]</b> 42 45 command, you can add the option "--branch <i>BRANCH-NAME</i>" to
43 -make the change be the founding check-in for a new branch. You can 46 +make the new check-in be the first check-in for a new branch. You can 44 47 also add the "--bgcolor <i>COLOR</i>" option to give the branch a
45 48 specific background color on timelines.
46 49 47 -If you want to create a new branch whose founding check-in is the 50 +If you want to create a new branch whose initial content is the 48 51 same as an existing check-in, use this command:
49 52 50 53 <blockquote>
51 -<b>fossil branch new</b> <i>BRANCH-NAME BASIS</i> 54 +<b>fossil [/help/branch|branch] new</b> <i>BRANCH-NAME BASIS</i> 52 55 </blockquote>
53 56 54 57 The <i>BRANCH-NAME</i> argument is the name of the new branch and the
55 58 <i>BASIS</i> argument is the name of the check-in that the branch splits
56 59 off from.
57 60 58 61 If you already have a fork in your check-in tree and you want to convert
59 62 that fork to a branch, you can do this from the web interface.
60 63 First locate the check-in that you want to be
61 -the founding check-in of your branch on the timeline and click on its 64 +the initial check-in of your branch on the timeline and click on its 62 65 link so that you are on the <b>ci</b> page. Then find the "<b>edit</b>"
63 66 link (near the "Commands:" label) and click on that. On the
64 67 "Edit Check-in" page, check the box beside "Branching:" and fill in
65 68 the name of your new branch to the right and press the "Apply Changes"
66 69 button.</blockquote></li>
67 70 68 71 <a name="q4"></a>
69 -<p><b>(4) How do I create a private branch that won't get pushed back to the 72 +<p><b>(4) How do I tag a check-in?</b></p> 73 + 74 +<blockquote>There are several ways: 75 + 76 +When you are checking in a new change using the <b>[/help/commit|commit]</b> 77 +command, you can add a tag to that check-in using the 78 +"--tag <i>TAGNAME</i>" command-line option. 79 + 80 +If you want add a tag to an existing check-in, you can use the 81 +<b>[/help/tag|tag]</b> command. For example: 82 + 83 +<blockquote> 84 +<b>fossil [/help/branch|tag] add</b> <i>TAGNAME</i> <i>CHECK-IN</i> 85 +</blockquote> 86 + 87 +The CHECK-IN in the previous line can be any 88 +[./checkin_names.wiki | valid check-in name format]. 89 + 90 +You can also add (and remove) tags from a check-in using the 91 +[./webui.wiki | web interface]. First locate the check-in that you 92 +what to tag on the tmline, then click on the link to go the detailed 93 +information page for that check-in. Then find the "<b>edit</b>" 94 +link (near the "Commands:" label) and click on that. There are 95 +controls on the edit page that allow new tags to be added and existing 96 +tags to be removed.</blockquote></li> 97 + 98 +<a name="q5"></a> 99 +<p><b>(5) How do I create a private branch that won't get pushed back to the 70 100 main repository.</b></p>
71 101 72 102 <blockquote>Use the <b>--private</b> command-line option on the
73 103 <b>commit</b> command. The result will be a check-in which exists on
74 104 your local repository only and is never pushed to other repositories.
75 -All descendants of a private check-in are also private. 105 +All descendents of a private check-in are also private. 76 106 77 107 Unless you specify something different using the <b>--branch</b> and/or
78 108 <b>--bgcolor</b> options, the new private check-in will be put on a branch
79 109 named "private" with an orange background color.
80 110 81 111 You can merge from the trunk into your private branch in order to keep
82 112 your private branch in sync with the latest changes on the trunk. Once
................................................................................ 84 114 then merge your private branch back into the trunk and push. Only the
85 115 final merge operation will appear in other repositories. It will seem
86 116 as if all the changes that occurred on your private branch occurred in
87 117 a single check-in.
88 118 Of course, you can also keep your branch private forever simply
89 119 by not merging the changes in the private branch back into the trunk.</blockquote></li>
90 120 91 -<a name="q5"></a> 92 -<p><b>(5) How can I delete inappropriate content from my fossil repository?</b></p> 121 +<a name="q6"></a> 122 +<p><b>(6) How can I delete inappropriate content from my fossil repository?</b></p> 93 123 94 124 <blockquote>See the article on [./shunning.wiki | "shunning"] for details.</blockquote></li>
95 125 96 -<a name="q6"></a> 97 -<p><b>(6) How do I make a clone of the fossil self-hosting repository?</b></p> 126 +<a name="q7"></a> 127 +<p><b>(7) How do I make a clone of the fossil self-hosting repository?</b></p> 98 128 99 129 <blockquote>Any of the following commands should work:
100 130 <blockquote><pre>
101 -fossil clone http://www.fossil-scm.org/ fossil.fossil<br> 102 -fossil clone http://www2.fossil-scm.org/ fossil.fossil<br> 103 -fossil clone http://www.hwaci.com/cgi-bin/fossil fossil.fossil 131 +fossil [/help/clone|clone] http://www.fossil-scm.org/ fossil.fossil<br> 132 +fossil [/help/clone|clone] http://www2.fossil-scm.org/ fossil.fossil<br> 133 +fossil [/help/clone|clone] http://www3.fossli-scm.org/site.cgi fossil.fossil 104 134 </pre></blockquote>
105 135 Once you have the repository cloned, you can open a local check-out
106 136 as follows:
107 137 <blockquote><pre>
108 -mkdir src; cd src; fossil open ../fossil.fossil 138 +mkdir src; cd src; fossil [/help/open|open] ../fossil.fossil 109 139 </pre></blockquote>
110 140 Thereafter you should be able to keep your local check-out up to date
111 141 with the latest code in the public repository by typing:
112 142 <blockquote><pre>
113 -fossil update 143 +fossil [/help/update|update] 114 144 </pre></blockquote></blockquote></li>
115 145 146 +<a name="q8"></a> 147 +<p><b>(8) How do I import or export content from and to other version control systems?</b></p> 148 + 149 +<blockquote>Please see [./inout.wiki | Import And Export]</blockquote></li> 150 + 116 151 </ol>

Changes to www/makefile.wiki.

83 83 should understand that whenever "src.c" or "src.h" is used in the text
84 84 that follows, we really mean all (79) other source files other than
85 85 the exceptions described above.
86 86 87 87 <h1>3.0 Automatically generated files</h1>
88 88 89 89 The "VERSION.h" header file contains some C preprocessor macros that
90 -identify the version of Fossil that is to be build. The VERSION.h file 90 +identify the version of Fossil that is to be build. The VERSION.h file is 91 91 generated automatically from information extracted from the "manifest"
92 92 and "manifest.uuid" source files in the root directory of the source tree.
93 93 (The "manifest" and "manifest.uuid" files are automatically generated and
94 94 updated by Fossil itself. See the [/help/setting | fossil set manifest]
95 95 command for additional information.)
96 96 97 97 Under unix, there is an AWK script that converts manifest and manifest.uuid
................................................................................ 110 110 in the root of the source tree are the first two arguments and the name of
111 111 the generated VERSION.h file is the third and final argument.
112 112 113 113 <h1>4.0 Preprocessing</h1>
114 114 115 115 There are three preprocessors for the Fossil sources. The mkindex
116 116 and translate preprocessors can be run in any order. The makeheaders
117 -preprocessor has to be run after translate. 117 +preprocessor must be run after translate. 118 118 119 119 <h2>4.1 The mkindex preprocessor</h2>
120 120 121 121 The mkindex program scans the "src.c" source files looking for special
122 122 comments that identify routines that implement of various Fossil commands,
123 123 web interface methods, and help text comments. The mkindex program
124 124 generates some C code that Fossil uses in order to dispatch commands and

Changes to www/webui.wiki.

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

This page was generated in about
0.046s by
Fossil 2.8 [7b0dbe8079] 2019-02-20 22:28:24