From 4f49b16079b27d7ce633619e4cddfdf2bffbc952 Mon Sep 17 00:00:00 2001 From: cashmere Date: Fri, 4 Sep 2026 09:05:24 +0200 Subject: initial commit --- www/faq.tcl | 181 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 181 insertions(+) create mode 100755 www/faq.tcl (limited to 'www/faq.tcl') diff --git a/www/faq.tcl b/www/faq.tcl new file mode 100755 index 0000000..3a17bb8 --- /dev/null +++ b/www/faq.tcl @@ -0,0 +1,181 @@ +#!/usr/bin/tclsh +# +# Run this to generate the FAQ +# +set cnt 1 +proc faq {question answer} { + set ::faq($::cnt) [list [string trim $question] [string trim $answer]] + incr ::cnt +} + +faq { + What GUIs are available for fossil? +} { + The fossil executable comes with a [./webui.wiki | web-based GUI] built in. + Just run: + + 
+  fossil [/help/ui|ui] REPOSITORY-FILENAME
+
+ + And your default web browser should pop up and automatically point to + the fossil interface. (Hint: You can omit the REPOSITORY-FILENAME + if you are within an open check-out.) +} + +faq { + What is the difference between a "branch" and a "fork"? +} { + This is a big question - too big to answer in a FAQ. Please + read the Branching, Forking, Merging, + and Tagging document. +} + + +faq { + How do I create a new branch? +} { + There are lots of ways: + + When you are checking in a new change using the [/help/commit|commit] + command, you can add the option "--branch BRANCH-NAME" to + make the new check-in be the first check-in for a new branch. + + If you want to create a new branch whose initial content is the + same as an existing check-in, use this command: + + 
+  fossil [/help/branch|branch] new BRANCH-NAME BASIS
+
+ + The BRANCH-NAME argument is the name of the new branch and the + BASIS argument is the name of the check-in that the branch splits + off from. + + If you already have a fork in your check-in tree and you want to convert + that fork to a branch, you can do this from the web interface. + First locate the check-in that you want to be + the initial check-in of your branch on the timeline and click on its + link so that you are on the ci page. Then find the "edit" + link (near the "Commands:" label) and click on that. On the + "Edit Check-in" page, check the box beside "Branching:" and fill in + the name of your new branch to the right and press the "Apply Changes" + button. +} + +faq { + How do I tag a check-in? +} { + There are several ways: + + When you are checking in a new change using the [/help/commit|commit] + command, you can add a tag to that check-in using the + "--tag TAGNAME" command-line option. You can repeat the --tag + option to give a check-in multiple tags. Tags need not be unique. So, + for example, it is common to give every released version a "release" tag. + + If you want to add a tag to an existing check-in, you can use the + [/help/tag|tag] command. For example: + + 
+  fossil [/help/branch|tag] add TAGNAME CHECK-IN
+
+ + The CHECK-IN in the previous line can be any + [./checkin_names.wiki | valid check-in name format]. + + You can also add (and remove) tags from a check-in using the + [./webui.wiki | web interface]. First locate the check-in that you + want to tag on the timeline, then click on the link to go the detailed + information page for that check-in. Then find the "edit" + link (near the "Commands:" label) and click on that. There are + controls on the edit page that allow new tags to be added and existing + tags to be removed. +} + +faq { + How do I create a private branch that won't get pushed back to the + main repository. +} { + Use the --private command-line option on the + commit command. The result will be a check-in which exists in + your local repository only and is never pushed to other repositories. + All descendants of a private check-in are also private. + + Unless you specify something different using the --branch and/or + --bgcolor options, the new private check-in will be put on a branch + named "private" with an orange background color. + + You can merge from the trunk into your private branch in order to keep + your private branch in sync with the latest changes on the trunk. Once + you have everything in your private branch the way you want it, you can + then merge your private branch back into the trunk and push. Only the + final merge operation will appear in other repositories. It will seem + as if all the changes that occurred on your private branch occurred in + a single check-in. + Of course, you can also keep your branch private forever simply + by not merging the changes in the private branch back into the trunk. + + [./private.wiki | Additional information] +} + +faq { + How can I delete inappropriate content from my fossil repository? +} { + See the article on [./shunning.wiki | "shunning"] for details. +} + +faq { + How do I make a clone of the fossil self-hosting repository? +} { + Any of the following commands should work: + + 
+  fossil [/help/clone|clone]  https://fossil-scm.org/  fossil.fossil
+  fossil [/help/clone|clone]  https://www2.fossil-scm.org/  fossil.fossil
+  fossil [/help/clone|clone]  https://www3.fossil-scm.org/site.cgi  fossil.fossil
+
+ + Once you have the repository cloned, you can open a local check-out + as follows: + + 
+  mkdir src; cd src; fossil [/help/open|open] ../fossil.fossil
+
+ + Thereafter you should be able to keep your local check-out up to date + with the latest code in the public repository by typing: + + 
+  fossil [/help/update|update]
+
+} + +faq { + How do I import or export content from and to other version control systems? +} { + Please see [./inout.wiki | Import And Export] +} + + + +############################################################################# +# Code to actually generate the FAQ +# +puts "Fossil FAQ\n" +puts "Note: See also Questions and Criticisms.\n" + +puts {
    } +for {set i 1} {$i<$cnt} {incr i} { + puts "
  1. [lindex $faq($i) 0]
    2. " +} +puts {
} +puts {
} + +for {set i 1} {$i<$cnt} {incr i} { + puts "

($i) [lindex $faq($i) 0]

\n" + set body [lindex $faq($i) 1] + regsub -all "\n *" [string trim $body] "\n" body + puts "$body\n" +} +puts {} -- cgit v1.3.1