Fossil SCM
Remove obsolete documentation from the www/ folder.
Commit
d80f2dc058706c9eb7a1c486029321c8cfd6e6a7
Parent
231113eac291edc…
15 files changed
-65
-59
-19
-19
-50
-38
-55
-24
-33
-40
-53
-22
-29
-12
-702
-
www/cmd_add.wiki
-
www/cmd_all.wiki
-
www/cmd_cgi.wiki
-
www/cmd_changes.wiki
-
www/cmd_checkout.wiki
-
www/cmd_extra.wiki
-
www/cmd_ls.wiki
-
www/cmd_mv.wiki
-
www/cmd_new.wiki
-
www/cmd_rm.wiki
-
www/cmd_status.wiki
-
www/cmd_sync.wiki
-
www/cmd_update.wiki
-
www/cmd_version.wiki
-
www/reference.wiki
D
www/cmd_add.wiki
-65
| --- a/www/cmd_add.wiki | ||
| +++ b/www/cmd_add.wiki | ||
| @@ -1,65 +0,0 @@ | ||
| 1 | -<h2>add</h2> | |
| 2 | - | |
| 3 | -The often used <code>add</code> command is how you tell <b>fossil</b> to | |
| 4 | -include a (usually new) file in the repository. | |
| 5 | - | |
| 6 | -<b>fossil</b> is designed to manage artifacts whose role is being | |
| 7 | -"source" for something, most probably software program code or other | |
| 8 | -text. One can imagine all kinds of ways to let fossil know just what | |
| 9 | -constitutes a source; the simplest and most direct way it | |
| 10 | -<i>actually</i> finds out is when you give it the | |
| 11 | -<code> fossil add <i>path</i> </code> command. | |
| 12 | - | |
| 13 | -It's reasonable to think of | |
| 14 | -the [./cmd_import.wiki | <code>import</code>] | |
| 15 | -and [./cmd_clone.wiki | <code>clone</code>] | |
| 16 | -commands as very high-powered versions of the <code>add</code> | |
| 17 | -command that are combined with system level file movement and | |
| 18 | -networking functions. Not particularly accurate, but reasonable. | |
| 19 | - | |
| 20 | -Typing <code> fossil add myfile</code> causes fossil to put | |
| 21 | -<i>myfile</i> into the repository at the next | |
| 22 | -<code>commit</code>—provided you issue it from within the source | |
| 23 | -tree, of course. | |
| 24 | - | |
| 25 | -By contrast, <code> fossil add mydirectory</code> will add | |
| 26 | -<em><strong>all</strong></em> of the files in <i>mydirectory</i>, and | |
| 27 | -all of its sub-directories. In other words, adding a directory will | |
| 28 | -recursively add all of the directory's file system descendants to the | |
| 29 | -repository. This was an oft-requested feature, recently implemented. | |
| 30 | -It is very flexible. Only when you add a directory do you get the | |
| 31 | -recursive behavior. If you are globbing a subset of files, you won't | |
| 32 | -get the recursion. | |
| 33 | - | |
| 34 | -Realize that the repository is <u>not</u> changed by the | |
| 35 | -<code>add</code> command, but by the <code> commit</code> command. | |
| 36 | -<code>add</code> <i>myfile</i> tells <b>fossil</b> to "mark" | |
| 37 | -<i>myfile</i> as part of the repository. Only commands which actually | |
| 38 | -manipulate the content of the repository can physically put source | |
| 39 | -artifacts into (or remove them from) the repository. | |
| 40 | - | |
| 41 | -Just to keep things symmetric, there are also commands that can | |
| 42 | -manipulate the repository without affecting the checked-out sources | |
| 43 | -(see [./cmd_pull.wiki | fossil pull], for instance.) | |
| 44 | - | |
| 45 | -It's worthwhile reiterating that <b>fossil</b> is storing the content | |
| 46 | -of source artifacts and the names of the artifacts in their "native | |
| 47 | -habitat", a sequence of "temporal slices" (aka "versions") of the | |
| 48 | -state of the whole system, and a set of unique identifiers. When you | |
| 49 | -add a file to a repository, the <i>path</i> to the file is a part of | |
| 50 | -the <i>name</i> of the file. There is a mis-match between the file | |
| 51 | -system's idea of a directory (a file containing pointers to files) and | |
| 52 | -fossil's idea (a substring of the name of the artifact.) The names of | |
| 53 | -the artifacts specify their relative locations because of the way the | |
| 54 | -file system interprets them. If you don't keep this in mind, you may | |
| 55 | -fool yourself into thinking <b>fossil</b> somehow "stores | |
| 56 | -directories." It doesn't, and believing it does will eventually | |
| 57 | -confuse you. | |
| 58 | - | |
| 59 | -See also: [./cmd_rm.wiki | fossil rm], | |
| 60 | -[./cmd_import.wiki | fossil import], | |
| 61 | -[./cmd_clone.wiki | fossil clone], | |
| 62 | -[./cmd_commit.wiki | fossil commit], | |
| 63 | -[./cmd_pull.wiki | fossil pull], | |
| 64 | -[./cmd_settings.wiki | fossil setting] (async), | |
| 65 | -[./reference.wiki | Reference] |
| --- a/www/cmd_add.wiki | |
| +++ b/www/cmd_add.wiki | |
| @@ -1,65 +0,0 @@ | |
| 1 | <h2>add</h2> |
| 2 | |
| 3 | The often used <code>add</code> command is how you tell <b>fossil</b> to |
| 4 | include a (usually new) file in the repository. |
| 5 | |
| 6 | <b>fossil</b> is designed to manage artifacts whose role is being |
| 7 | "source" for something, most probably software program code or other |
| 8 | text. One can imagine all kinds of ways to let fossil know just what |
| 9 | constitutes a source; the simplest and most direct way it |
| 10 | <i>actually</i> finds out is when you give it the |
| 11 | <code> fossil add <i>path</i> </code> command. |
| 12 | |
| 13 | It's reasonable to think of |
| 14 | the [./cmd_import.wiki | <code>import</code>] |
| 15 | and [./cmd_clone.wiki | <code>clone</code>] |
| 16 | commands as very high-powered versions of the <code>add</code> |
| 17 | command that are combined with system level file movement and |
| 18 | networking functions. Not particularly accurate, but reasonable. |
| 19 | |
| 20 | Typing <code> fossil add myfile</code> causes fossil to put |
| 21 | <i>myfile</i> into the repository at the next |
| 22 | <code>commit</code>—provided you issue it from within the source |
| 23 | tree, of course. |
| 24 | |
| 25 | By contrast, <code> fossil add mydirectory</code> will add |
| 26 | <em><strong>all</strong></em> of the files in <i>mydirectory</i>, and |
| 27 | all of its sub-directories. In other words, adding a directory will |
| 28 | recursively add all of the directory's file system descendants to the |
| 29 | repository. This was an oft-requested feature, recently implemented. |
| 30 | It is very flexible. Only when you add a directory do you get the |
| 31 | recursive behavior. If you are globbing a subset of files, you won't |
| 32 | get the recursion. |
| 33 | |
| 34 | Realize that the repository is <u>not</u> changed by the |
| 35 | <code>add</code> command, but by the <code> commit</code> command. |
| 36 | <code>add</code> <i>myfile</i> tells <b>fossil</b> to "mark" |
| 37 | <i>myfile</i> as part of the repository. Only commands which actually |
| 38 | manipulate the content of the repository can physically put source |
| 39 | artifacts into (or remove them from) the repository. |
| 40 | |
| 41 | Just to keep things symmetric, there are also commands that can |
| 42 | manipulate the repository without affecting the checked-out sources |
| 43 | (see [./cmd_pull.wiki | fossil pull], for instance.) |
| 44 | |
| 45 | It's worthwhile reiterating that <b>fossil</b> is storing the content |
| 46 | of source artifacts and the names of the artifacts in their "native |
| 47 | habitat", a sequence of "temporal slices" (aka "versions") of the |
| 48 | state of the whole system, and a set of unique identifiers. When you |
| 49 | add a file to a repository, the <i>path</i> to the file is a part of |
| 50 | the <i>name</i> of the file. There is a mis-match between the file |
| 51 | system's idea of a directory (a file containing pointers to files) and |
| 52 | fossil's idea (a substring of the name of the artifact.) The names of |
| 53 | the artifacts specify their relative locations because of the way the |
| 54 | file system interprets them. If you don't keep this in mind, you may |
| 55 | fool yourself into thinking <b>fossil</b> somehow "stores |
| 56 | directories." It doesn't, and believing it does will eventually |
| 57 | confuse you. |
| 58 | |
| 59 | See also: [./cmd_rm.wiki | fossil rm], |
| 60 | [./cmd_import.wiki | fossil import], |
| 61 | [./cmd_clone.wiki | fossil clone], |
| 62 | [./cmd_commit.wiki | fossil commit], |
| 63 | [./cmd_pull.wiki | fossil pull], |
| 64 | [./cmd_settings.wiki | fossil setting] (async), |
| 65 | [./reference.wiki | Reference] |
| --- a/www/cmd_add.wiki | |
| +++ b/www/cmd_add.wiki | |
| @@ -1,65 +0,0 @@ | |
D
www/cmd_all.wiki
-59
| --- a/www/cmd_all.wiki | ||
| +++ b/www/cmd_all.wiki | ||
| @@ -1,59 +0,0 @@ | ||
| 1 | -<h2>all</h2> | |
| 2 | - | |
| 3 | -The <code>all</code> command will let you perform (some) commands on | |
| 4 | -<em>all</em> of your repositories, and provides a way of finding all | |
| 5 | -of your repositories as well. | |
| 6 | - | |
| 7 | -There are some commands you might especially want to perform on every | |
| 8 | -repository you've got, once in a while. <code> fossil all | |
| 9 | -</code> includes four of the most likely as sub-commands: | |
| 10 | -[./cmd_pull.wiki | <code>pull</code>], | |
| 11 | -[./cmd_push.wiki | <code>push</code>], | |
| 12 | -[./cmd_rebuild.wiki | <code>rebuild</code>] and | |
| 13 | -[./cmd_sync.wiki | <code>sync</code>]. | |
| 14 | - | |
| 15 | -Follow the links to find out what each of those do, and then a moment | |
| 16 | -of thought will tell you why you might want to have them available for | |
| 17 | -all repositories. | |
| 18 | - | |
| 19 | -Certainly you'll want your repositories all rebuilt when you upgrade | |
| 20 | -<b>fossil</b> after there has been a change in the repository | |
| 21 | -structure. For the others, it depends. Usually you would want | |
| 22 | -across-the-board versions if you've been "off Net" for a while, and | |
| 23 | -have commits to multiple repositories than you need to share, or want | |
| 24 | -to get the repository changes that have been made by others, or both. | |
| 25 | - | |
| 26 | -The last sub-command provided by <code>all</code> is "<code>list</code>." | |
| 27 | - | |
| 28 | -While the other sub-commands give you a way to conveniently take care | |
| 29 | -of all of your repositories for some common tasks, the | |
| 30 | -<code>list</code> provides a way to take care of any subset of your | |
| 31 | -repositories in any way you want. It provides a list of all of your | |
| 32 | -repositories' locations. <code>fossil all list</code> | |
| 33 | -outputs a one-per-line listing of the path for each of your | |
| 34 | -repositories. With that in hand, you can easily script just about any | |
| 35 | -repository manipulations you want. | |
| 36 | - | |
| 37 | -Or, you could just jog your memory. | |
| 38 | - | |
| 39 | -The <code>all</code> command uses the <i>.fossil</i> file in the home | |
| 40 | -directory to find all of your repositories, so you can mess it up by | |
| 41 | -moving your repositories around. This is easy to do inadvertently if | |
| 42 | -you have a cavalier attitude about repos, but you'll know pretty | |
| 43 | -quickly that you've done it—many commands you try to use from | |
| 44 | -inside of a checkout won't work correctly. The <i>.fossil</i> file is | |
| 45 | -an <b>sqlite</b> db file which fossil uses to keeping track of | |
| 46 | -repository locations. Advice: if you move your repositories around, | |
| 47 | -let fossil know you did; | |
| 48 | -[./cmd_close.wiki | <code>close</code>] them before you move | |
| 49 | -them, and then [./cmd_open.wiki | <code>open</code>] them from | |
| 50 | -their new locations. | |
| 51 | - | |
| 52 | -See also: [./cmd_pull.wiki | fossil pull], | |
| 53 | -[./cmd_push.wiki | fossil push], | |
| 54 | -[./cmd_rebuild.wiki | fossil rebuild], | |
| 55 | -[./cmd_sync.wiki | fossil sync], | |
| 56 | -[./cmd_open.wiki | fossil open], | |
| 57 | -[./cmd_close.wiki | fossil close], | |
| 58 | -[./reference.wiki | Reference], | |
| 59 | -[http://www.sqlite.org | <b>SQLite</b>] |
| --- a/www/cmd_all.wiki | |
| +++ b/www/cmd_all.wiki | |
| @@ -1,59 +0,0 @@ | |
| 1 | <h2>all</h2> |
| 2 | |
| 3 | The <code>all</code> command will let you perform (some) commands on |
| 4 | <em>all</em> of your repositories, and provides a way of finding all |
| 5 | of your repositories as well. |
| 6 | |
| 7 | There are some commands you might especially want to perform on every |
| 8 | repository you've got, once in a while. <code> fossil all |
| 9 | </code> includes four of the most likely as sub-commands: |
| 10 | [./cmd_pull.wiki | <code>pull</code>], |
| 11 | [./cmd_push.wiki | <code>push</code>], |
| 12 | [./cmd_rebuild.wiki | <code>rebuild</code>] and |
| 13 | [./cmd_sync.wiki | <code>sync</code>]. |
| 14 | |
| 15 | Follow the links to find out what each of those do, and then a moment |
| 16 | of thought will tell you why you might want to have them available for |
| 17 | all repositories. |
| 18 | |
| 19 | Certainly you'll want your repositories all rebuilt when you upgrade |
| 20 | <b>fossil</b> after there has been a change in the repository |
| 21 | structure. For the others, it depends. Usually you would want |
| 22 | across-the-board versions if you've been "off Net" for a while, and |
| 23 | have commits to multiple repositories than you need to share, or want |
| 24 | to get the repository changes that have been made by others, or both. |
| 25 | |
| 26 | The last sub-command provided by <code>all</code> is "<code>list</code>." |
| 27 | |
| 28 | While the other sub-commands give you a way to conveniently take care |
| 29 | of all of your repositories for some common tasks, the |
| 30 | <code>list</code> provides a way to take care of any subset of your |
| 31 | repositories in any way you want. It provides a list of all of your |
| 32 | repositories' locations. <code>fossil all list</code> |
| 33 | outputs a one-per-line listing of the path for each of your |
| 34 | repositories. With that in hand, you can easily script just about any |
| 35 | repository manipulations you want. |
| 36 | |
| 37 | Or, you could just jog your memory. |
| 38 | |
| 39 | The <code>all</code> command uses the <i>.fossil</i> file in the home |
| 40 | directory to find all of your repositories, so you can mess it up by |
| 41 | moving your repositories around. This is easy to do inadvertently if |
| 42 | you have a cavalier attitude about repos, but you'll know pretty |
| 43 | quickly that you've done it—many commands you try to use from |
| 44 | inside of a checkout won't work correctly. The <i>.fossil</i> file is |
| 45 | an <b>sqlite</b> db file which fossil uses to keeping track of |
| 46 | repository locations. Advice: if you move your repositories around, |
| 47 | let fossil know you did; |
| 48 | [./cmd_close.wiki | <code>close</code>] them before you move |
| 49 | them, and then [./cmd_open.wiki | <code>open</code>] them from |
| 50 | their new locations. |
| 51 | |
| 52 | See also: [./cmd_pull.wiki | fossil pull], |
| 53 | [./cmd_push.wiki | fossil push], |
| 54 | [./cmd_rebuild.wiki | fossil rebuild], |
| 55 | [./cmd_sync.wiki | fossil sync], |
| 56 | [./cmd_open.wiki | fossil open], |
| 57 | [./cmd_close.wiki | fossil close], |
| 58 | [./reference.wiki | Reference], |
| 59 | [http://www.sqlite.org | <b>SQLite</b>] |
| --- a/www/cmd_all.wiki | |
| +++ b/www/cmd_all.wiki | |
| @@ -1,59 +0,0 @@ | |
D
www/cmd_cgi.wiki
-19
| --- a/www/cmd_cgi.wiki | ||
| +++ b/www/cmd_cgi.wiki | ||
| @@ -1,19 +0,0 @@ | ||
| 1 | -<h2>cgi</h2> | |
| 2 | - | |
| 3 | -<code>cgi</code> is the command that tells fossil it is running as a | |
| 4 | -web-page supplier for an external http server. (For you web-miesters, | |
| 5 | -the "cgi" is actually unnecessary if your web environment is set up in | |
| 6 | -a normal fashion.) | |
| 7 | - | |
| 8 | -This is the command you will probably use if you want to make a | |
| 9 | -moderate-to-high hit rate public repository (like the <b>fossil</b> | |
| 10 | -project's self-hosted repository) but you'll be using it in the | |
| 11 | -shebang line. | |
| 12 | - | |
| 13 | -If you need lower level access to the pages <b>fossil</b> generates, | |
| 14 | -you'll want to look at the [./cmd_http.wiki | <code>http</code>] | |
| 15 | -command. | |
| 16 | - | |
| 17 | -See also: [./cmd_http.wiki | fossil http], | |
| 18 | -[./concepts.wiki#saserv | <i>Concepts (setting up a server)</i>], | |
| 19 | -[./reference.wiki | Reference] |
| --- a/www/cmd_cgi.wiki | |
| +++ b/www/cmd_cgi.wiki | |
| @@ -1,19 +0,0 @@ | |
| 1 | <h2>cgi</h2> |
| 2 | |
| 3 | <code>cgi</code> is the command that tells fossil it is running as a |
| 4 | web-page supplier for an external http server. (For you web-miesters, |
| 5 | the "cgi" is actually unnecessary if your web environment is set up in |
| 6 | a normal fashion.) |
| 7 | |
| 8 | This is the command you will probably use if you want to make a |
| 9 | moderate-to-high hit rate public repository (like the <b>fossil</b> |
| 10 | project's self-hosted repository) but you'll be using it in the |
| 11 | shebang line. |
| 12 | |
| 13 | If you need lower level access to the pages <b>fossil</b> generates, |
| 14 | you'll want to look at the [./cmd_http.wiki | <code>http</code>] |
| 15 | command. |
| 16 | |
| 17 | See also: [./cmd_http.wiki | fossil http], |
| 18 | [./concepts.wiki#saserv | <i>Concepts (setting up a server)</i>], |
| 19 | [./reference.wiki | Reference] |
| --- a/www/cmd_cgi.wiki | |
| +++ b/www/cmd_cgi.wiki | |
| @@ -1,19 +0,0 @@ | |
D
www/cmd_changes.wiki
-19
| --- a/www/cmd_changes.wiki | ||
| +++ b/www/cmd_changes.wiki | ||
| @@ -1,19 +0,0 @@ | ||
| 1 | -<h2>changes</h2> | |
| 2 | - | |
| 3 | -The <code>changes</code> command is informational, it doesn't do | |
| 4 | -anything to a checked-out project, but it tells you something about | |
| 5 | -it. | |
| 6 | - | |
| 7 | -This is simply a quick way to get a list of the files which are | |
| 8 | -different in the source tree (the checkout) and the repository. | |
| 9 | - | |
| 10 | -There is a bit more information (was a file edited, added or | |
| 11 | -removed?, for instance). | |
| 12 | - | |
| 13 | -The same information will be displayed if you | |
| 14 | -[./cmd_status.wiki | <code> fossil status </code>], | |
| 15 | -except there will be some additional repository information displayed | |
| 16 | -first. | |
| 17 | - | |
| 18 | -See also: [./cmd_status.wiki | fossil status], | |
| 19 | -[./reference.wiki | Reference] |
| --- a/www/cmd_changes.wiki | |
| +++ b/www/cmd_changes.wiki | |
| @@ -1,19 +0,0 @@ | |
| 1 | <h2>changes</h2> |
| 2 | |
| 3 | The <code>changes</code> command is informational, it doesn't do |
| 4 | anything to a checked-out project, but it tells you something about |
| 5 | it. |
| 6 | |
| 7 | This is simply a quick way to get a list of the files which are |
| 8 | different in the source tree (the checkout) and the repository. |
| 9 | |
| 10 | There is a bit more information (was a file edited, added or |
| 11 | removed?, for instance). |
| 12 | |
| 13 | The same information will be displayed if you |
| 14 | [./cmd_status.wiki | <code> fossil status </code>], |
| 15 | except there will be some additional repository information displayed |
| 16 | first. |
| 17 | |
| 18 | See also: [./cmd_status.wiki | fossil status], |
| 19 | [./reference.wiki | Reference] |
| --- a/www/cmd_changes.wiki | |
| +++ b/www/cmd_changes.wiki | |
| @@ -1,19 +0,0 @@ | |
D
www/cmd_checkout.wiki
-50
| --- a/www/cmd_checkout.wiki | ||
| +++ b/www/cmd_checkout.wiki | ||
| @@ -1,50 +0,0 @@ | ||
| 1 | -<h2>checkout</h2> | |
| 2 | - | |
| 3 | -The <code>checkout</code> command is how a project version goes from | |
| 4 | -the repository to the chosen project directory. | |
| 5 | - | |
| 6 | -Without going into detail about getting/opening a repository, once you | |
| 7 | -have a repository and a place in which the repository has been | |
| 8 | -opened, you can "check out" a "version" of the files which make up the | |
| 9 | -repository at somewhen. | |
| 10 | - | |
| 11 | -The term "checkout" is traditional in source management systems, but a | |
| 12 | -bit of an anachronism in a distributed system like <b>fossil</b>. | |
| 13 | -"Checking out" a version of a project means getting all of the source | |
| 14 | -artifacts out into the standard environment---currently the | |
| 15 | -shell/file-system. | |
| 16 | - | |
| 17 | -Traditionally, the version is some "incrementing" code like | |
| 18 | -v1.3.2rcQuink or f451 or something. In distributed SCM systems it's | |
| 19 | -some absolutely unique identifier, usually the result of a one-way | |
| 20 | -hash (SHA1, in fossil's case.) The <b>fossil</b> term for these is | |
| 21 | -<em>artifact IDs</em>. | |
| 22 | - | |
| 23 | -<code>fossil checkout </code> <i>id</i> will check out the | |
| 24 | -version corresponding to <i>id</i> into the source tree. | |
| 25 | - | |
| 26 | -<code>checkout</code> requires you to pick a precise version to put into | |
| 27 | -the "on-disk" source tree, and leaves any edited files which are already | |
| 28 | -in the tree intact. | |
| 29 | - | |
| 30 | -<code>update</code>, on the other hand, <em>merges</em> edits into the | |
| 31 | -version you choose (if you choose one; you can default the version.) | |
| 32 | - | |
| 33 | -Since a version is required, and <b>fossil</b>'s artifact IDs are | |
| 34 | -fairly long, there are two good ways to refer to the version. You can | |
| 35 | -use a unique proper prefix of the version (six or eight characters is | |
| 36 | -more than enough in most cases) <em>or</em> you can [./cmd_tag.wiki | | |
| 37 | -tag] your check-ins and use the tags for checkouts, reverting, | |
| 38 | -branching (tags are the best way to branch) and so forth. Both | |
| 39 | -methods work throughout fossil. | |
| 40 | - | |
| 41 | -See also [./cmd_tag.wiki | fossil tag], | |
| 42 | -[./cmd_revert.wiki | fossil revert], | |
| 43 | -[./cmd_update.wiki | fossil update], | |
| 44 | -[./cmd_push.wiki | fossil push], | |
| 45 | -[./cmd_pull.wiki | fossil pull], | |
| 46 | -[./cmd_clone.wiki | fossil clone], | |
| 47 | -[./cmd_open.wiki | fossil open], | |
| 48 | -[./cmd_close.wiki | fossil close], | |
| 49 | -[./cmd_new.wiki | fossil new], | |
| 50 | -[./reference.wiki | Reference] |
| --- a/www/cmd_checkout.wiki | |
| +++ b/www/cmd_checkout.wiki | |
| @@ -1,50 +0,0 @@ | |
| 1 | <h2>checkout</h2> |
| 2 | |
| 3 | The <code>checkout</code> command is how a project version goes from |
| 4 | the repository to the chosen project directory. |
| 5 | |
| 6 | Without going into detail about getting/opening a repository, once you |
| 7 | have a repository and a place in which the repository has been |
| 8 | opened, you can "check out" a "version" of the files which make up the |
| 9 | repository at somewhen. |
| 10 | |
| 11 | The term "checkout" is traditional in source management systems, but a |
| 12 | bit of an anachronism in a distributed system like <b>fossil</b>. |
| 13 | "Checking out" a version of a project means getting all of the source |
| 14 | artifacts out into the standard environment---currently the |
| 15 | shell/file-system. |
| 16 | |
| 17 | Traditionally, the version is some "incrementing" code like |
| 18 | v1.3.2rcQuink or f451 or something. In distributed SCM systems it's |
| 19 | some absolutely unique identifier, usually the result of a one-way |
| 20 | hash (SHA1, in fossil's case.) The <b>fossil</b> term for these is |
| 21 | <em>artifact IDs</em>. |
| 22 | |
| 23 | <code>fossil checkout </code> <i>id</i> will check out the |
| 24 | version corresponding to <i>id</i> into the source tree. |
| 25 | |
| 26 | <code>checkout</code> requires you to pick a precise version to put into |
| 27 | the "on-disk" source tree, and leaves any edited files which are already |
| 28 | in the tree intact. |
| 29 | |
| 30 | <code>update</code>, on the other hand, <em>merges</em> edits into the |
| 31 | version you choose (if you choose one; you can default the version.) |
| 32 | |
| 33 | Since a version is required, and <b>fossil</b>'s artifact IDs are |
| 34 | fairly long, there are two good ways to refer to the version. You can |
| 35 | use a unique proper prefix of the version (six or eight characters is |
| 36 | more than enough in most cases) <em>or</em> you can [./cmd_tag.wiki | |
| 37 | tag] your check-ins and use the tags for checkouts, reverting, |
| 38 | branching (tags are the best way to branch) and so forth. Both |
| 39 | methods work throughout fossil. |
| 40 | |
| 41 | See also [./cmd_tag.wiki | fossil tag], |
| 42 | [./cmd_revert.wiki | fossil revert], |
| 43 | [./cmd_update.wiki | fossil update], |
| 44 | [./cmd_push.wiki | fossil push], |
| 45 | [./cmd_pull.wiki | fossil pull], |
| 46 | [./cmd_clone.wiki | fossil clone], |
| 47 | [./cmd_open.wiki | fossil open], |
| 48 | [./cmd_close.wiki | fossil close], |
| 49 | [./cmd_new.wiki | fossil new], |
| 50 | [./reference.wiki | Reference] |
| --- a/www/cmd_checkout.wiki | |
| +++ b/www/cmd_checkout.wiki | |
| @@ -1,50 +0,0 @@ | |
D
www/cmd_extra.wiki
-38
| --- a/www/cmd_extra.wiki | ||
| +++ b/www/cmd_extra.wiki | ||
| @@ -1,38 +0,0 @@ | ||
| 1 | -<h2>extra</h2> | |
| 2 | - | |
| 3 | -The <code>extra</code> command is informational, it doesn't do anything to | |
| 4 | -a checked-out project, but it tells you something about it. | |
| 5 | - | |
| 6 | -Extra files are files that exist in a checked-out project, but don't belong to | |
| 7 | -the repository. | |
| 8 | - | |
| 9 | -The <code>fossil extra</code> command will get you a list of these files. | |
| 10 | - | |
| 11 | -This is convenient for figuring out if you've <code> | |
| 12 | -[./cmd_add.wiki | add]</code>ed every file that needs to be | |
| 13 | - | |
| 14 | -in the repository before you do a commit. It will also tell you what | |
| 15 | -will be removed if you [./cmd_clean.wiki | <code>clean</code>] | |
| 16 | -the project. | |
| 17 | - | |
| 18 | -Suppose, for example, you have a "noodle.src" file as a scratch pad | |
| 19 | -for source code, and you don't want to include your latest | |
| 20 | -hare-brained ideas in the repository? You don't <code>add</code> it | |
| 21 | -to the repository, of course—though there are ways you might add | |
| 22 | -it unintentionally. If your project is big, and you want to find | |
| 23 | -noodle.src, and anything else that isn't under source control within | |
| 24 | -the project directories, then<code> fossil extra </code> will | |
| 25 | -give you a list. | |
| 26 | - | |
| 27 | -If you don't think this is all that useful, then you've never had to write | |
| 28 | -a shell script that only affects project files and leaves everything | |
| 29 | -else alone. ;) | |
| 30 | - | |
| 31 | -The <code>extra</code> command is almost, but not quite entirely, the exact | |
| 32 | -opposite of the [./cmd_ls.wiki | <code>ls</code>] command. | |
| 33 | - | |
| 34 | -See also: [./cmd_status.wiki | fossil status], | |
| 35 | -[./cmd_ls.wiki | fossil ls], | |
| 36 | -[./cmd_changes.wiki | fossil changes], | |
| 37 | -[./cmd_clean.wiki | fossil clean], | |
| 38 | -[./reference.wiki | Reference] |
| --- a/www/cmd_extra.wiki | |
| +++ b/www/cmd_extra.wiki | |
| @@ -1,38 +0,0 @@ | |
| 1 | <h2>extra</h2> |
| 2 | |
| 3 | The <code>extra</code> command is informational, it doesn't do anything to |
| 4 | a checked-out project, but it tells you something about it. |
| 5 | |
| 6 | Extra files are files that exist in a checked-out project, but don't belong to |
| 7 | the repository. |
| 8 | |
| 9 | The <code>fossil extra</code> command will get you a list of these files. |
| 10 | |
| 11 | This is convenient for figuring out if you've <code> |
| 12 | [./cmd_add.wiki | add]</code>ed every file that needs to be |
| 13 | |
| 14 | in the repository before you do a commit. It will also tell you what |
| 15 | will be removed if you [./cmd_clean.wiki | <code>clean</code>] |
| 16 | the project. |
| 17 | |
| 18 | Suppose, for example, you have a "noodle.src" file as a scratch pad |
| 19 | for source code, and you don't want to include your latest |
| 20 | hare-brained ideas in the repository? You don't <code>add</code> it |
| 21 | to the repository, of course—though there are ways you might add |
| 22 | it unintentionally. If your project is big, and you want to find |
| 23 | noodle.src, and anything else that isn't under source control within |
| 24 | the project directories, then<code> fossil extra </code> will |
| 25 | give you a list. |
| 26 | |
| 27 | If you don't think this is all that useful, then you've never had to write |
| 28 | a shell script that only affects project files and leaves everything |
| 29 | else alone. ;) |
| 30 | |
| 31 | The <code>extra</code> command is almost, but not quite entirely, the exact |
| 32 | opposite of the [./cmd_ls.wiki | <code>ls</code>] command. |
| 33 | |
| 34 | See also: [./cmd_status.wiki | fossil status], |
| 35 | [./cmd_ls.wiki | fossil ls], |
| 36 | [./cmd_changes.wiki | fossil changes], |
| 37 | [./cmd_clean.wiki | fossil clean], |
| 38 | [./reference.wiki | Reference] |
| --- a/www/cmd_extra.wiki | |
| +++ b/www/cmd_extra.wiki | |
| @@ -1,38 +0,0 @@ | |
D
www/cmd_ls.wiki
-55
| --- a/www/cmd_ls.wiki | ||
| +++ b/www/cmd_ls.wiki | ||
| @@ -1,55 +0,0 @@ | ||
| 1 | -<h2>ls</h2> | |
| 2 | - | |
| 3 | -The <code>ls</code><a href="#notes">*</a> command is informational, it doesn't do anything to | |
| 4 | -a checked-out project, but it tells you something about it. | |
| 5 | - | |
| 6 | -A project consists of a "source tree" of "artifacts" (see [./concepts.wiki | Fossil concepts].) | |
| 7 | -From a practical standpoint this is a set of files and directories rooted | |
| 8 | -at a main project directory. The files that are under source control aren't | |
| 9 | -particularly distinguishable from those that aren't. The <code>ls</code> and | |
| 10 | -<code>extra</code> commands provide this information. | |
| 11 | - | |
| 12 | -<code>fossil ls</code> produces a listing of the files which are under source | |
| 13 | -control <i>and</i> their status within the repository. The output is a simple | |
| 14 | -list of STATUS/filepath pairs on separate lines. The status of a file will | |
| 15 | -likely be one of ADDED, UNCHANGED, UPDATED, or DELETED. <a href="#notes">*</a> | |
| 16 | - | |
| 17 | -It's important to realize that this is the status <i>relative to the repository</i>, | |
| 18 | -it's the status as <b>fossil</b> sees it and has nothing to do with | |
| 19 | -filesystem status. If you're new to source-management/version-control | |
| 20 | -systems, you'll probably get bit by this concept-bug at least once. | |
| 21 | - | |
| 22 | -To really see the difference, issue an <code>ls</code> before and after doing | |
| 23 | -a [./cmd_commit.wiki | <code>commit</code>]. Before, the status of files may be any of the three, | |
| 24 | -but after <code>commit</code>ting changes the status will be UNCHANGED "across | |
| 25 | -the board." | |
| 26 | - | |
| 27 | -By way of example, here's what I see if I <code>fossil ls</code> in the | |
| 28 | -directory where I have checked out my testing repository: | |
| 29 | -<nowiki><pre> | |
| 30 | - $ fossil ls | |
| 31 | - ADDED feegboing | |
| 32 | - UNCHANGED fossil_docs.txt | |
| 33 | - DELETED nibcrod | |
| 34 | -</pre></nowiki> | |
| 35 | -But if I do a simple ls, what I get is | |
| 36 | -<nowiki><pre> | |
| 37 | - $ ls | |
| 38 | - feegboing fossil_docs.txt manifest.uuid noodle.txt | |
| 39 | - _FOSSIL_ manifest nibcrod | |
| 40 | -</pre></nowiki> | |
| 41 | - | |
| 42 | -The <code>ls</code> command is almost, but not quite entirely, the exact | |
| 43 | -opposite of the | |
| 44 | -[./cmd_extra.wiki | <code>extra</code> command]. | |
| 45 | - | |
| 46 | -<a name="notes">Notes:</a> | |
| 47 | - * If you come from the <b>Windows</b> world, it will help to know that 'ls' is the usual <b>unix</b> command for listing a directory. | |
| 48 | - * There are more states for a file to be in than those listed, including MISSING, EDITED, RENAMED and a couple of others. | |
| 49 | - | |
| 50 | -See also: [./cmd_add.wiki | fossil add], | |
| 51 | -[./rm.wiki | fossil rm], | |
| 52 | -[./cmd_extra.wiki | fossil extra], | |
| 53 | -[./cmd_commit.wiki | fossil commit], | |
| 54 | -[./concepts.wiki | Fossil concepts], | |
| 55 | -[./reference.wiki | Reference] |
| --- a/www/cmd_ls.wiki | |
| +++ b/www/cmd_ls.wiki | |
| @@ -1,55 +0,0 @@ | |
| 1 | <h2>ls</h2> |
| 2 | |
| 3 | The <code>ls</code><a href="#notes">*</a> command is informational, it doesn't do anything to |
| 4 | a checked-out project, but it tells you something about it. |
| 5 | |
| 6 | A project consists of a "source tree" of "artifacts" (see [./concepts.wiki | Fossil concepts].) |
| 7 | From a practical standpoint this is a set of files and directories rooted |
| 8 | at a main project directory. The files that are under source control aren't |
| 9 | particularly distinguishable from those that aren't. The <code>ls</code> and |
| 10 | <code>extra</code> commands provide this information. |
| 11 | |
| 12 | <code>fossil ls</code> produces a listing of the files which are under source |
| 13 | control <i>and</i> their status within the repository. The output is a simple |
| 14 | list of STATUS/filepath pairs on separate lines. The status of a file will |
| 15 | likely be one of ADDED, UNCHANGED, UPDATED, or DELETED. <a href="#notes">*</a> |
| 16 | |
| 17 | It's important to realize that this is the status <i>relative to the repository</i>, |
| 18 | it's the status as <b>fossil</b> sees it and has nothing to do with |
| 19 | filesystem status. If you're new to source-management/version-control |
| 20 | systems, you'll probably get bit by this concept-bug at least once. |
| 21 | |
| 22 | To really see the difference, issue an <code>ls</code> before and after doing |
| 23 | a [./cmd_commit.wiki | <code>commit</code>]. Before, the status of files may be any of the three, |
| 24 | but after <code>commit</code>ting changes the status will be UNCHANGED "across |
| 25 | the board." |
| 26 | |
| 27 | By way of example, here's what I see if I <code>fossil ls</code> in the |
| 28 | directory where I have checked out my testing repository: |
| 29 | <nowiki><pre> |
| 30 | $ fossil ls |
| 31 | ADDED feegboing |
| 32 | UNCHANGED fossil_docs.txt |
| 33 | DELETED nibcrod |
| 34 | </pre></nowiki> |
| 35 | But if I do a simple ls, what I get is |
| 36 | <nowiki><pre> |
| 37 | $ ls |
| 38 | feegboing fossil_docs.txt manifest.uuid noodle.txt |
| 39 | _FOSSIL_ manifest nibcrod |
| 40 | </pre></nowiki> |
| 41 | |
| 42 | The <code>ls</code> command is almost, but not quite entirely, the exact |
| 43 | opposite of the |
| 44 | [./cmd_extra.wiki | <code>extra</code> command]. |
| 45 | |
| 46 | <a name="notes">Notes:</a> |
| 47 | * If you come from the <b>Windows</b> world, it will help to know that 'ls' is the usual <b>unix</b> command for listing a directory. |
| 48 | * There are more states for a file to be in than those listed, including MISSING, EDITED, RENAMED and a couple of others. |
| 49 | |
| 50 | See also: [./cmd_add.wiki | fossil add], |
| 51 | [./rm.wiki | fossil rm], |
| 52 | [./cmd_extra.wiki | fossil extra], |
| 53 | [./cmd_commit.wiki | fossil commit], |
| 54 | [./concepts.wiki | Fossil concepts], |
| 55 | [./reference.wiki | Reference] |
| --- a/www/cmd_ls.wiki | |
| +++ b/www/cmd_ls.wiki | |
| @@ -1,55 +0,0 @@ | |
D
www/cmd_mv.wiki
-24
| --- a/www/cmd_mv.wiki | ||
| +++ b/www/cmd_mv.wiki | ||
| @@ -1,24 +0,0 @@ | ||
| 1 | -<h2>mv | rename</h2> | |
| 2 | - | |
| 3 | -The <code>mv</code> (alias "<code>rename</code>") command tells | |
| 4 | -<b>fossil</b> that a file has gone from one external name to another | |
| 5 | -without changing content. | |
| 6 | - | |
| 7 | -You could do this by renaming the file in the file system, | |
| 8 | -[./cmd_rm.wiki | deleting] the old name from the project, and | |
| 9 | -[./cmd_add.wiki | adding] the new name. But you would lose the | |
| 10 | -continuity of the <u>content's</u> history that way. Using | |
| 11 | -<code>mv</code> makes the name change a part of the history | |
| 12 | -maintained by <b>fossil</b>. You will, of course, need a good | |
| 13 | -comment somewhere (say, the commit comment) if you want to | |
| 14 | -remember <em>why</em> you changed the name... <b>fossil</b> | |
| 15 | -only maintains history, it doesn't (yet) explain it. | |
| 16 | - | |
| 17 | -<code>mv</code> is much like the [./cmd_rm.wiki | <code>rm</code>] | |
| 18 | -command, in that it manipulates <b>fossil</b>'s "idea" of what is | |
| 19 | -part of the project. The difference is that <code>mv</code> assumes | |
| 20 | -you have actually made some change to the file system. | |
| 21 | - | |
| 22 | -See also: [./cmd_rm.wiki | fossil rm], | |
| 23 | -[./cmd_add.wiki | fossil add], | |
| 24 | -[./reference.wiki | Reference] |
| --- a/www/cmd_mv.wiki | |
| +++ b/www/cmd_mv.wiki | |
| @@ -1,24 +0,0 @@ | |
| 1 | <h2>mv | rename</h2> |
| 2 | |
| 3 | The <code>mv</code> (alias "<code>rename</code>") command tells |
| 4 | <b>fossil</b> that a file has gone from one external name to another |
| 5 | without changing content. |
| 6 | |
| 7 | You could do this by renaming the file in the file system, |
| 8 | [./cmd_rm.wiki | deleting] the old name from the project, and |
| 9 | [./cmd_add.wiki | adding] the new name. But you would lose the |
| 10 | continuity of the <u>content's</u> history that way. Using |
| 11 | <code>mv</code> makes the name change a part of the history |
| 12 | maintained by <b>fossil</b>. You will, of course, need a good |
| 13 | comment somewhere (say, the commit comment) if you want to |
| 14 | remember <em>why</em> you changed the name... <b>fossil</b> |
| 15 | only maintains history, it doesn't (yet) explain it. |
| 16 | |
| 17 | <code>mv</code> is much like the [./cmd_rm.wiki | <code>rm</code>] |
| 18 | command, in that it manipulates <b>fossil</b>'s "idea" of what is |
| 19 | part of the project. The difference is that <code>mv</code> assumes |
| 20 | you have actually made some change to the file system. |
| 21 | |
| 22 | See also: [./cmd_rm.wiki | fossil rm], |
| 23 | [./cmd_add.wiki | fossil add], |
| 24 | [./reference.wiki | Reference] |
| --- a/www/cmd_mv.wiki | |
| +++ b/www/cmd_mv.wiki | |
| @@ -1,24 +0,0 @@ | |
D
www/cmd_new.wiki
-33
| --- a/www/cmd_new.wiki | ||
| +++ b/www/cmd_new.wiki | ||
| @@ -1,33 +0,0 @@ | ||
| 1 | -<h2>new</h2> | |
| 2 | - | |
| 3 | -The <code>new</code> command allows you to create a brand new | |
| 4 | -repository. | |
| 5 | - | |
| 6 | -Pragmatically, this means that an SQLite database is created with | |
| 7 | -whatever name you specified, and set up with the appropriate tables | |
| 8 | -and initial data. | |
| 9 | - | |
| 10 | -There's not much to <code>new</code>, it's what happens afterward that | |
| 11 | -gets a project going: | |
| 12 | - | |
| 13 | - Once you have a new repository file, you need to create and cd to a | |
| 14 | - directory in which you will store your files, or move into an | |
| 15 | - existing directory which contains the files for a project. | |
| 16 | - | |
| 17 | - Then, you need to [./cmd_open.wiki | <code>open</code>] the new | |
| 18 | - repository, and get the server running so you can set up the project | |
| 19 | - name and so forth. | |
| 20 | - | |
| 21 | - Finally, you'll [./cmd_add.wiki | <code>add</code>] files to it. If | |
| 22 | - you are adding exisiting files, you can add them individually, via | |
| 23 | - globbing from the shell, or by adding the directory (which will add | |
| 24 | - all of the directory's file-system descendants recursively.) | |
| 25 | - | |
| 26 | -But you can't do all that until you create a repository file with | |
| 27 | -<code>new</code>. | |
| 28 | - | |
| 29 | -See also: | |
| 30 | -[./cmd_open.wiki | fossil open], | |
| 31 | -[./cmd_add.wiki | fossil add], | |
| 32 | -[./cmd_server.wiki | fossil ui], | |
| 33 | -[./reference.wiki | Reference] |
| --- a/www/cmd_new.wiki | |
| +++ b/www/cmd_new.wiki | |
| @@ -1,33 +0,0 @@ | |
| 1 | <h2>new</h2> |
| 2 | |
| 3 | The <code>new</code> command allows you to create a brand new |
| 4 | repository. |
| 5 | |
| 6 | Pragmatically, this means that an SQLite database is created with |
| 7 | whatever name you specified, and set up with the appropriate tables |
| 8 | and initial data. |
| 9 | |
| 10 | There's not much to <code>new</code>, it's what happens afterward that |
| 11 | gets a project going: |
| 12 | |
| 13 | Once you have a new repository file, you need to create and cd to a |
| 14 | directory in which you will store your files, or move into an |
| 15 | existing directory which contains the files for a project. |
| 16 | |
| 17 | Then, you need to [./cmd_open.wiki | <code>open</code>] the new |
| 18 | repository, and get the server running so you can set up the project |
| 19 | name and so forth. |
| 20 | |
| 21 | Finally, you'll [./cmd_add.wiki | <code>add</code>] files to it. If |
| 22 | you are adding exisiting files, you can add them individually, via |
| 23 | globbing from the shell, or by adding the directory (which will add |
| 24 | all of the directory's file-system descendants recursively.) |
| 25 | |
| 26 | But you can't do all that until you create a repository file with |
| 27 | <code>new</code>. |
| 28 | |
| 29 | See also: |
| 30 | [./cmd_open.wiki | fossil open], |
| 31 | [./cmd_add.wiki | fossil add], |
| 32 | [./cmd_server.wiki | fossil ui], |
| 33 | [./reference.wiki | Reference] |
| --- a/www/cmd_new.wiki | |
| +++ b/www/cmd_new.wiki | |
| @@ -1,33 +0,0 @@ | |
D
www/cmd_rm.wiki
-40
| --- a/www/cmd_rm.wiki | ||
| +++ b/www/cmd_rm.wiki | ||
| @@ -1,40 +0,0 @@ | ||
| 1 | -<h2>del | rm</h2> | |
| 2 | - | |
| 3 | -The <code>del</code> (alias <code>rm</code>) command takes a "file" | |
| 4 | -<em>out</em> of a project. | |
| 5 | - | |
| 6 | -It does <u>not</u> delete the file from the repository, it does | |
| 7 | -<u>not</u> remove the file from the file system on disk. It tells | |
| 8 | -<b>fossil</b> that the file is no longer a part of the project for | |
| 9 | -which <b>fossil</b> is maintaining the sources. | |
| 10 | - | |
| 11 | -For example, if you have a nice, clean source tree and use the | |
| 12 | -[./cmd_extra.wiki | <code>extra</code>] command on it, you won't | |
| 13 | -get any output. If you then <code>rm</code> some file and commit | |
| 14 | -the change, that file will be listed by the <code>extra</code> | |
| 15 | -command. | |
| 16 | - | |
| 17 | -The file is still on the disk, and it is still in the repository. | |
| 18 | -<strong>But</strong> the file <em>is not part of the project</em> | |
| 19 | -anymore. Further changes to the file will not be checked in unless | |
| 20 | -you [./cmd_add.wiki | <code>add</code>] the file again. | |
| 21 | - | |
| 22 | -It can initially be confusing to see a file that's been "deleted" | |
| 23 | -still showing up in the files list in the repository, but remember | |
| 24 | -that the files list currently<a href="#vnote"><sup>*</sup></a> shows | |
| 25 | -all of the files that have ever been in the repository <em>because | |
| 26 | -<b>fossil</b> is a source control system and therefore keeps a record | |
| 27 | -of the history of a project.</em> | |
| 28 | - | |
| 29 | -To get a list of the files <em>only in the current version</em> of the | |
| 30 | -project, use the [./cmd_ls.wiki | <code>ls</code>] command. | |
| 31 | - | |
| 32 | -The <code>del</code> command is the logical opposite of the | |
| 33 | -[./cmd_add.wiki | <code>add</code>] command, in its single-file-add | |
| 34 | -form. | |
| 35 | - | |
| 36 | -<font size="-1"><a name="vnote"><sup>*</sup></a>version 7c281b629a on 20081220</font> | |
| 37 | - | |
| 38 | -See also: [./cmd_add.wiki | fossil add], | |
| 39 | -[./cmd_ls.wiki | fossil ls], | |
| 40 | -[./reference.wiki | Reference] |
| --- a/www/cmd_rm.wiki | |
| +++ b/www/cmd_rm.wiki | |
| @@ -1,40 +0,0 @@ | |
| 1 | <h2>del | rm</h2> |
| 2 | |
| 3 | The <code>del</code> (alias <code>rm</code>) command takes a "file" |
| 4 | <em>out</em> of a project. |
| 5 | |
| 6 | It does <u>not</u> delete the file from the repository, it does |
| 7 | <u>not</u> remove the file from the file system on disk. It tells |
| 8 | <b>fossil</b> that the file is no longer a part of the project for |
| 9 | which <b>fossil</b> is maintaining the sources. |
| 10 | |
| 11 | For example, if you have a nice, clean source tree and use the |
| 12 | [./cmd_extra.wiki | <code>extra</code>] command on it, you won't |
| 13 | get any output. If you then <code>rm</code> some file and commit |
| 14 | the change, that file will be listed by the <code>extra</code> |
| 15 | command. |
| 16 | |
| 17 | The file is still on the disk, and it is still in the repository. |
| 18 | <strong>But</strong> the file <em>is not part of the project</em> |
| 19 | anymore. Further changes to the file will not be checked in unless |
| 20 | you [./cmd_add.wiki | <code>add</code>] the file again. |
| 21 | |
| 22 | It can initially be confusing to see a file that's been "deleted" |
| 23 | still showing up in the files list in the repository, but remember |
| 24 | that the files list currently<a href="#vnote"><sup>*</sup></a> shows |
| 25 | all of the files that have ever been in the repository <em>because |
| 26 | <b>fossil</b> is a source control system and therefore keeps a record |
| 27 | of the history of a project.</em> |
| 28 | |
| 29 | To get a list of the files <em>only in the current version</em> of the |
| 30 | project, use the [./cmd_ls.wiki | <code>ls</code>] command. |
| 31 | |
| 32 | The <code>del</code> command is the logical opposite of the |
| 33 | [./cmd_add.wiki | <code>add</code>] command, in its single-file-add |
| 34 | form. |
| 35 | |
| 36 | <font size="-1"><a name="vnote"><sup>*</sup></a>version 7c281b629a on 20081220</font> |
| 37 | |
| 38 | See also: [./cmd_add.wiki | fossil add], |
| 39 | [./cmd_ls.wiki | fossil ls], |
| 40 | [./reference.wiki | Reference] |
| --- a/www/cmd_rm.wiki | |
| +++ b/www/cmd_rm.wiki | |
| @@ -1,40 +0,0 @@ | |
D
www/cmd_status.wiki
-53
| --- a/www/cmd_status.wiki | ||
| +++ b/www/cmd_status.wiki | ||
| @@ -1,53 +0,0 @@ | ||
| 1 | -<h2>status</h2> | |
| 2 | - | |
| 3 | -The <code>status</code> command is informational, it doesn't do anything to | |
| 4 | -a checked-out project, but it tells you something about it. | |
| 5 | - | |
| 6 | -Running <code> fossil status </code> currently prefixes | |
| 7 | -the output of the <code>[./cmd_changes.wiki | changes]</code> command | |
| 8 | -with information about the repository and checkout. The information | |
| 9 | -is in the form of the [./concepts.wiki#aidex | Artifact ID]s of the | |
| 10 | -server code, the checkout, and the parent (of, I <em>think</em> the | |
| 11 | -checkout.) | |
| 12 | - | |
| 13 | -This is useful for getting an at-a-glance view of the state of your | |
| 14 | -project, especially in a situation where you need the artifact IDs. | |
| 15 | - | |
| 16 | -Here is what I get when I issue a <code>status</code> on my local | |
| 17 | -version of the <b>fossil</b> repository as I write this: | |
| 18 | - | |
| 19 | -<nowiki><pre> | |
| 20 | - $ fossil status | |
| 21 | - repository: /home/me/myclone.fossil | |
| 22 | - local-root: /home/me/fossil/ | |
| 23 | - server-code: 99d6c9cf3f262720579db177503812814d712fc7 | |
| 24 | - checkout: a8c3a7ea9249281e0a1fb55fb31d2ad57844f848 | |
| 25 | - parent: 21cecd209f7201f17e8a784c0d8f735603d440ae | |
| 26 | - EDITED www/cmd_.wiki-template | |
| 27 | - EDITED www/cmd_add.wiki | |
| 28 | - EDITED www/cmd_all.wiki | |
| 29 | - EDITED www/cmd_extra.wiki | |
| 30 | - EDITED www/cmd_ls.wiki | |
| 31 | - EDITED www/cmd_update.wiki | |
| 32 | - EDITED www/index.wiki | |
| 33 | - $ | |
| 34 | -</pre></nowiki> | |
| 35 | - | |
| 36 | -Once I actually make changes to the repository (say, a | |
| 37 | -[./cmd_commit.wiki | commit]) most of that will change—all | |
| 38 | -of those files showing as "EDITED" will be checked in and won't | |
| 39 | -show up, and the artifact IDs will reflect the new state of the | |
| 40 | -repository. | |
| 41 | - | |
| 42 | -If the only thing you want to see is which files in the checked-out | |
| 43 | -source tree have changed in some way, use the | |
| 44 | -[./cmd_changes.wiki | <code>changes</code>] command. | |
| 45 | - | |
| 46 | -If what you want is the files in the checked-out source tree which are | |
| 47 | -<em>not</em> part of the project, use the | |
| 48 | -[./cmd_extra.wiki | <code>extra</code>] command. | |
| 49 | - | |
| 50 | -See also: [./cmd_changes.wiki | fossil changes], | |
| 51 | -[./cmd_extra.wiki | fossil extra], | |
| 52 | -[./concepts.wiki | <i>Fossil concepts</i>], | |
| 53 | -[./reference.wiki | Reference] |
| --- a/www/cmd_status.wiki | |
| +++ b/www/cmd_status.wiki | |
| @@ -1,53 +0,0 @@ | |
| 1 | <h2>status</h2> |
| 2 | |
| 3 | The <code>status</code> command is informational, it doesn't do anything to |
| 4 | a checked-out project, but it tells you something about it. |
| 5 | |
| 6 | Running <code> fossil status </code> currently prefixes |
| 7 | the output of the <code>[./cmd_changes.wiki | changes]</code> command |
| 8 | with information about the repository and checkout. The information |
| 9 | is in the form of the [./concepts.wiki#aidex | Artifact ID]s of the |
| 10 | server code, the checkout, and the parent (of, I <em>think</em> the |
| 11 | checkout.) |
| 12 | |
| 13 | This is useful for getting an at-a-glance view of the state of your |
| 14 | project, especially in a situation where you need the artifact IDs. |
| 15 | |
| 16 | Here is what I get when I issue a <code>status</code> on my local |
| 17 | version of the <b>fossil</b> repository as I write this: |
| 18 | |
| 19 | <nowiki><pre> |
| 20 | $ fossil status |
| 21 | repository: /home/me/myclone.fossil |
| 22 | local-root: /home/me/fossil/ |
| 23 | server-code: 99d6c9cf3f262720579db177503812814d712fc7 |
| 24 | checkout: a8c3a7ea9249281e0a1fb55fb31d2ad57844f848 |
| 25 | parent: 21cecd209f7201f17e8a784c0d8f735603d440ae |
| 26 | EDITED www/cmd_.wiki-template |
| 27 | EDITED www/cmd_add.wiki |
| 28 | EDITED www/cmd_all.wiki |
| 29 | EDITED www/cmd_extra.wiki |
| 30 | EDITED www/cmd_ls.wiki |
| 31 | EDITED www/cmd_update.wiki |
| 32 | EDITED www/index.wiki |
| 33 | $ |
| 34 | </pre></nowiki> |
| 35 | |
| 36 | Once I actually make changes to the repository (say, a |
| 37 | [./cmd_commit.wiki | commit]) most of that will change—all |
| 38 | of those files showing as "EDITED" will be checked in and won't |
| 39 | show up, and the artifact IDs will reflect the new state of the |
| 40 | repository. |
| 41 | |
| 42 | If the only thing you want to see is which files in the checked-out |
| 43 | source tree have changed in some way, use the |
| 44 | [./cmd_changes.wiki | <code>changes</code>] command. |
| 45 | |
| 46 | If what you want is the files in the checked-out source tree which are |
| 47 | <em>not</em> part of the project, use the |
| 48 | [./cmd_extra.wiki | <code>extra</code>] command. |
| 49 | |
| 50 | See also: [./cmd_changes.wiki | fossil changes], |
| 51 | [./cmd_extra.wiki | fossil extra], |
| 52 | [./concepts.wiki | <i>Fossil concepts</i>], |
| 53 | [./reference.wiki | Reference] |
| --- a/www/cmd_status.wiki | |
| +++ b/www/cmd_status.wiki | |
| @@ -1,53 +0,0 @@ | |
D
www/cmd_sync.wiki
-22
| --- a/www/cmd_sync.wiki | ||
| +++ b/www/cmd_sync.wiki | ||
| @@ -1,22 +0,0 @@ | ||
| 1 | -<h2>sync</h2> | |
| 2 | - | |
| 3 | -The <code>sync</code> command [./cmd_pull.wiki | <code>pull</code>]s and | |
| 4 | -[./cmd_push.wiki | <code>push</code>]es repository changes simultaneously. | |
| 5 | - | |
| 6 | -This applies to repositories available via a URL, of course. If your | |
| 7 | -project is strictly local you can do all of the distributed stuff as | |
| 8 | -long as you are "serving" the repository via http in some fashion, but | |
| 9 | -it's probably pointless to do so. | |
| 10 | - | |
| 11 | -Assuming you aren't running <b>fossil</b> as a high-powered version of | |
| 12 | -[http://www.gnu.org/software/rcs | RCS], your use of <code>sync</code> | |
| 13 | -in your projects is up to you. <b>fossil</b> defaults to using a | |
| 14 | -[./cmd_setting.wiki | setting] of <code>autosync</code> | |
| 15 | -If you have cloned a repository you will automatically sync with the | |
| 16 | -original if you [./cmd_commit.wiki | commit] changes to your local | |
| 17 | -version <em>unless</em> you customize your configuration. | |
| 18 | - | |
| 19 | -See also: [./cmd_pull.wiki | fossil pull], | |
| 20 | -[./cmd_push.wiki | fossil push], | |
| 21 | -[./cmd_setting.wiki | fossil setting], | |
| 22 | -[./r |
| --- a/www/cmd_sync.wiki | |
| +++ b/www/cmd_sync.wiki | |
| @@ -1,22 +0,0 @@ | |
| 1 | <h2>sync</h2> |
| 2 | |
| 3 | The <code>sync</code> command [./cmd_pull.wiki | <code>pull</code>]s and |
| 4 | [./cmd_push.wiki | <code>push</code>]es repository changes simultaneously. |
| 5 | |
| 6 | This applies to repositories available via a URL, of course. If your |
| 7 | project is strictly local you can do all of the distributed stuff as |
| 8 | long as you are "serving" the repository via http in some fashion, but |
| 9 | it's probably pointless to do so. |
| 10 | |
| 11 | Assuming you aren't running <b>fossil</b> as a high-powered version of |
| 12 | [http://www.gnu.org/software/rcs | RCS], your use of <code>sync</code> |
| 13 | in your projects is up to you. <b>fossil</b> defaults to using a |
| 14 | [./cmd_setting.wiki | setting] of <code>autosync</code> |
| 15 | If you have cloned a repository you will automatically sync with the |
| 16 | original if you [./cmd_commit.wiki | commit] changes to your local |
| 17 | version <em>unless</em> you customize your configuration. |
| 18 | |
| 19 | See also: [./cmd_pull.wiki | fossil pull], |
| 20 | [./cmd_push.wiki | fossil push], |
| 21 | [./cmd_setting.wiki | fossil setting], |
| 22 | [./r |
| --- a/www/cmd_sync.wiki | |
| +++ b/www/cmd_sync.wiki | |
| @@ -1,22 +0,0 @@ | |
D
www/cmd_update.wiki
-29
| --- a/www/cmd_update.wiki | ||
| +++ b/www/cmd_update.wiki | ||
| @@ -1,29 +0,0 @@ | ||
| 1 | -<h2>update</h2> | |
| 2 | - | |
| 3 | -What do you do if you have changes out on a repository and | |
| 4 | -you want them merged with te</h2> | |
| 5 | - | |
| 6 | -<u>Updating</u> a repository is the process of applying to it changes | |
| 7 | -made by external entities. Contrast this with [./cmd_commit.wiki | | |
| 8 | -commit]ing a locally made change; updating is a bit like "committing" | |
| 9 | -external changes to the local repo. | |
| 10 | - | |
| 11 | -Update <em>merges</em> changes from the repository into your checkout. | |
| 12 | -That means that it won't have any effect unless there <i>are</i> | |
| 13 | -changes in the repository. The only way the checkout can affect | |
| 14 | -the repo (this is the local repo we're talking about) is if you | |
| 15 | -do a [./cmd_commit.wiki | <code>ci</code>]. So, <code>update</code> | |
| 16 | -only really makes sense if you have | |
| 17 | -[./cmd_pull.wiki | <code>pull</code>]ed changes from the master repository | |
| 18 | -into the local repository. | |
| 19 | - | |
| 20 | -<annotation> | |
| 21 | - Note : | |
| 22 | - really really need a quick overview of the pull-update-edit-commit-push | |
| 23 | - workflow, and the shortcuts for that, and re-emphasize the role of autosync | |
| 24 | - in changing the basic nature of the workflow | |
| 25 | -</annotation> | |
| 26 | - | |
| 27 | -Local intranet <code>[./cmd_commit.wiki | commit]</code>s | |
| 28 | -(by someone else) | |
| 29 | -or Net <code>[./cmd_pull.wiki | |
| --- a/www/cmd_update.wiki | |
| +++ b/www/cmd_update.wiki | |
| @@ -1,29 +0,0 @@ | |
| 1 | <h2>update</h2> |
| 2 | |
| 3 | What do you do if you have changes out on a repository and |
| 4 | you want them merged with te</h2> |
| 5 | |
| 6 | <u>Updating</u> a repository is the process of applying to it changes |
| 7 | made by external entities. Contrast this with [./cmd_commit.wiki | |
| 8 | commit]ing a locally made change; updating is a bit like "committing" |
| 9 | external changes to the local repo. |
| 10 | |
| 11 | Update <em>merges</em> changes from the repository into your checkout. |
| 12 | That means that it won't have any effect unless there <i>are</i> |
| 13 | changes in the repository. The only way the checkout can affect |
| 14 | the repo (this is the local repo we're talking about) is if you |
| 15 | do a [./cmd_commit.wiki | <code>ci</code>]. So, <code>update</code> |
| 16 | only really makes sense if you have |
| 17 | [./cmd_pull.wiki | <code>pull</code>]ed changes from the master repository |
| 18 | into the local repository. |
| 19 | |
| 20 | <annotation> |
| 21 | Note : |
| 22 | really really need a quick overview of the pull-update-edit-commit-push |
| 23 | workflow, and the shortcuts for that, and re-emphasize the role of autosync |
| 24 | in changing the basic nature of the workflow |
| 25 | </annotation> |
| 26 | |
| 27 | Local intranet <code>[./cmd_commit.wiki | commit]</code>s |
| 28 | (by someone else) |
| 29 | or Net <code>[./cmd_pull.wiki | |
| --- a/www/cmd_update.wiki | |
| +++ b/www/cmd_update.wiki | |
| @@ -1,29 +0,0 @@ | |
D
www/cmd_version.wiki
-12
| --- a/www/cmd_version.wiki | ||
| +++ b/www/cmd_version.wiki | ||
| @@ -1,12 +0,0 @@ | ||
| 1 | -<h2>version</h2> | |
| 2 | - | |
| 3 | -The <code>version</code> command is informational, it doesn't do | |
| 4 | -anything to a checked-out project, but it tells you something about | |
| 5 | -it. | |
| 6 | - | |
| 7 | -Issuing the version command will print out the short-form of the | |
| 8 | -artifact ID for the fossil executable. | |
| 9 | - | |
| 10 | -See also: [./cmd_status.wiki | fossil status], | |
| 11 | -[./cmd_info.wiki | fossil info], | |
| 12 | -[./reference.wiki | Reference] |
| --- a/www/cmd_version.wiki | |
| +++ b/www/cmd_version.wiki | |
| @@ -1,12 +0,0 @@ | |
| 1 | <h2>version</h2> |
| 2 | |
| 3 | The <code>version</code> command is informational, it doesn't do |
| 4 | anything to a checked-out project, but it tells you something about |
| 5 | it. |
| 6 | |
| 7 | Issuing the version command will print out the short-form of the |
| 8 | artifact ID for the fossil executable. |
| 9 | |
| 10 | See also: [./cmd_status.wiki | fossil status], |
| 11 | [./cmd_info.wiki | fossil info], |
| 12 | [./reference.wiki | Reference] |
| --- a/www/cmd_version.wiki | |
| +++ b/www/cmd_version.wiki | |
| @@ -1,12 +0,0 @@ | |
D
www/reference.wiki
-702
| --- a/www/reference.wiki | ||
| +++ b/www/reference.wiki | ||
| @@ -1,702 +0,0 @@ | ||
| 1 | - <h2>Command Line Interface Reference</h2> | |
| 2 | - | |
| 3 | - This is an easy introduction to the fossil command line interface | |
| 4 | - (cli). It assumes some familiarity with using the command line, and | |
| 5 | - with Source Code Maintenence (SCM) systems—but not <i>too</i> | |
| 6 | - much. | |
| 7 | - | |
| 8 | - If you are trying to find information about fossil's web | |
| 9 | - capabilities, see the <a href="index.wiki">Fossil Home</a> and | |
| 10 | - <a href="wikitheory.wiki">Fossil Wiki</a> pages for pointers. | |
| 11 | - | |
| 12 | - <h3>Things to note</h3> | |
| 13 | - * Fossil cli commands do not use special delimeters, they use | |
| 14 | - spaces. This is traditional with VCS/SCM. Some <i>options</i> to | |
| 15 | - fossil commands <i>do</i> use special delimiters, particularly the | |
| 16 | - '-' (hyphen, or dash) character. This is very similar to Tcl. | |
| 17 | - Think of fossil as a shell you invoke and feed a command to, | |
| 18 | - including any options, and it will make more sense. | |
| 19 | - | |
| 20 | - * Any fossil command is acceptable once enough of it has been | |
| 21 | - entered to make the intent unambiguous. 'clo' is a proper prefix of | |
| 22 | - both the 'clone' and 'close' commands, for instance, but 'clon' is | |
| 23 | - enough to make the intent—the 'clone' | |
| 24 | - command—unambiguous. | |
| 25 | - | |
| 26 | - * Pragmatically, a [./concepts.wiki#keyconc | <u>version</u>] | |
| 27 | - in <b>fossil</b> is a 40-character long string of hexadecimal. | |
| 28 | - <b>fossil</b> will be able to figure out which version you want | |
| 29 | - with any <i>distinct</i> prefix of that string which is at | |
| 30 | - least four characters long. <em>Commands which require a | |
| 31 | - version are looking for the string, a distinct prefix of the | |
| 32 | - string, or a <code>tag</code>.</em> | |
| 33 | - | |
| 34 | - * SCM in a distributed environment can be a bit confusing with | |
| 35 | - regard to branching, merging, and versions in general. See the | |
| 36 | - [./branching.wiki | explanation of branching] and it will all make | |
| 37 | - much more sense. | |
| 38 | - | |
| 39 | - * <i>Op.Ed.</i> An excellent way to learn to use <b>fossil</b> | |
| 40 | - effectively is to | |
| 41 | - [./quickstart.wiki#fslclone | clone the repository for fossil] | |
| 42 | - itself. You can then poke around using the <code>fossil ui</code> | |
| 43 | - command, and look things up with no connection worries. You can | |
| 44 | - set up test repositories and try things out on-the-fly to see how | |
| 45 | - they work, using their own ui's. The CLI will far easier to | |
| 46 | - understand if you can run a repository, watch it in a browser, and | |
| 47 | - hack around with it in a simplified environment (your tests) with | |
| 48 | - guaranteed and fast access to the sources & docs (your cloned fossil | |
| 49 | - repository). | |
| 50 | -<br /><br /> <br /> | |
| 51 | - <b>You should</b> probably start interacting with fossil at the command | |
| 52 | - line by asking it what it can | |
| 53 | - do: <a name="tof">ˆ</a> | |
| 54 | - | |
| 55 | - <code>$ fossil help</code><nowiki><pre> | |
| 56 | -Usage: fossil help COMMAND. | |
| 57 | -Available COMMANDs:</pre><table width="80%" | |
| 58 | - style="font-family: fixed, courier, monospace;"> | |
| 59 | - <tr> | |
| 60 | - <td><a href="#add">add</a>*</td> | |
| 61 | - <td><a href="#checkout">co</a>*</td> | |
| 62 | - <td><a href="#http">http</a></td> | |
| 63 | - <td><a href="#rebuild">rebuild</a></td> | |
| 64 | - <td><a href="#sync">sync</a>*</td> | |
| 65 | - </tr> | |
| 66 | - <tr> | |
| 67 | - <td><a href="#all">all</a>*</td> | |
| 68 | - <td><a href="#commit">commit</a></td> | |
| 69 | - <td><a href="#info">info</a></td> | |
| 70 | - <td><a href="#reconstruct">reconstruct</a></td> | |
| 71 | - <td><a href="#tag">tag</a></td> | |
| 72 | - </tr> | |
| 73 | - <tr> | |
| 74 | - <td><a href="#branch">branch</a></td> | |
| 75 | - <td><a href="#configuration">configuration</a></td> | |
| 76 | - <td><a href="#leaves">leaves</a></td> | |
| 77 | - <td><a href="#redo">redo</a></td> | |
| 78 | - <td><a href="#timeline">timeline</a></td> | |
| 79 | - </tr> | |
| 80 | - <tr> | |
| 81 | - <td><a href="#cgi">cgi</a>*</td> | |
| 82 | - <td><a href="#deconstruct">deconstruct</a></td> | |
| 83 | - <td><a href="#ls">ls</a>*</td> | |
| 84 | - <td><a href="#mv">rename</a>*</td> | |
| 85 | - <td><a href="#server">ui</a></td> | |
| 86 | - </tr> | |
| 87 | - <tr> | |
| 88 | - <td><a href="#changes">changes</a>*</td> | |
| 89 | - <td><a href="#rm">del</a>*</td> | |
| 90 | - <td><a href="#merge">merge</a></td> | |
| 91 | - <td><a href="#revert">revert</a></td> | |
| 92 | - <td><a href="#undo">undo</a></td> | |
| 93 | - </tr> | |
| 94 | - <tr> | |
| 95 | - <td><a href="#checkout">checkout</a>*</td> | |
| 96 | - <td><a href="#descendants">descendants</a></td> | |
| 97 | - <td><a href="#mv">mv</a>*</td> | |
| 98 | - <td><a href="#rm">rm</a>*</td> | |
| 99 | - <td><a href="#settings">unset</a></td> | |
| 100 | - </tr> | |
| 101 | - <tr> | |
| 102 | - <td><a href="#commit">ci</a></td> | |
| 103 | - <td><a href="#diff">diff</a></td> | |
| 104 | - <td><a href="#new">new</a>*</td> | |
| 105 | - <td><a href="#rstats">rstats</a></td> | |
| 106 | - <td><a href="#update">update</a>*</td> | |
| 107 | - </tr> | |
| 108 | - <tr> | |
| 109 | - <td><a href="#clean">clean</a></td> | |
| 110 | - <td><a href="#extra">extra</a>*</td> | |
| 111 | - <td><a href="#open">open</a></td> | |
| 112 | - <td><a href="#server">server</a></td> | |
| 113 | - <td><a href="#user">user</a></td> | |
| 114 | - </tr> | |
| 115 | - <tr> | |
| 116 | - <td><a href="#clone">clone</a></td> | |
| 117 | - <td><a href="#diff">gdiff</a></td> | |
| 118 | - <td><a href="#pull">pull</a></td> | |
| 119 | - <td><a href="#settings">settings</a></td> | |
| 120 | - <td><a href="#version">version</a>*</td> | |
| 121 | - </tr> | |
| 122 | - <tr> | |
| 123 | - <td><a href="#close">close</a></td> | |
| 124 | - <td><a href="#help">help</a></td> | |
| 125 | - <td><a href="#push">push</a></td> | |
| 126 | - <td><a href="#status">status</a>*</td> | |
| 127 | - <td><a href="#wiki">wiki</a></td> | |
| 128 | - </tr> | |
| 129 | -</table><nowiki><pre> | |
| 130 | -This is fossil version [a89b436bc9] 2009-02-11 05:00:02 UTC | |
| 131 | -</pre> | |
| 132 | -<b>What follows</b> is a survey of what you get if you type<code> | |
| 133 | -fossil help <i>command</i> </code>for all of the | |
| 134 | -commands listed above. There are links to individual pages for each | |
| 135 | -of them; pages with content (commands marked with a '*' are done) go | |
| 136 | -into the reason for a command in a bit more depth than the program help. | |
| 137 | -<pre> | |
| 138 | -<hr><a href="#tof">ˆ</a> | |
| 139 | - <a name="add">Usage: </a><code><a href="cmd_add.wiki">fossil add</a></code> FILE... | |
| 140 | - Make arrangements to add one or more files to the current checkout | |
| 141 | - at the next commit. | |
| 142 | - | |
| 143 | -<hr><a href="#tof">ˆ</a> | |
| 144 | - <a name="all">Usage: </a><code><a href="cmd_all.wiki">fossil all</a></code> (list|pull|push|rebuild|sync) | |
| 145 | - The ~/.fossil file records the location of all repositories for a | |
| 146 | - user. This command performs certain operations on all repositories | |
| 147 | - that can be useful before or after a period of disconnection operation. | |
| 148 | - | |
| 149 | - On Win32 systems, this file is located in %LOCALAPPDATA%, %APDDATA% | |
| 150 | - or %HOMEPATH% and is named _fossil. | |
| 151 | - | |
| 152 | - Available operations are: | |
| 153 | - | |
| 154 | - list Display the location of all repositories | |
| 155 | - | |
| 156 | - pull Run a "pull" operation on all repositories | |
| 157 | - | |
| 158 | - push Run a "push" on all repositories | |
| 159 | - | |
| 160 | - rebuild Rebuild on all repositories | |
| 161 | - | |
| 162 | - sync Run a "sync" on all repositories | |
| 163 | - | |
| 164 | - Respositories are automatically added to the set of known repositories | |
| 165 | - when one of the following commands against the repository: clone, info, | |
| 166 | - pull, push, or sync | |
| 167 | - | |
| 168 | -<hr><a href="#tof">ˆ</a> | |
| 169 | - <a name="branch">Usage: </a><code><a href="cmd_branch.wiki">fossil branch</a></code> SUBCOMMAND ... ?-R|--repository FILE? | |
| 170 | - | |
| 171 | -Run various subcommands on the branches of the open repository or | |
| 172 | -of the repository identified by the -R or --repository option. | |
| 173 | - | |
| 174 | - fossil branch new BRANCH-NAME BASIS ?-bgcolor COLOR? | |
| 175 | - | |
| 176 | - Create a new branch BRANCH-NAME off of check-in BASIS. | |
| 177 | - You can optionally give the branch a default color. | |
| 178 | - | |
| 179 | - fossil branch list | |
| 180 | - | |
| 181 | - List all branches | |
| 182 | - | |
| 183 | -<hr><a href="#tof">ˆ</a> | |
| 184 | - <a name="cgi">Usage: </a><a href="cmd_cgi.wiki">fossil cgi</a> SCRIPT | |
| 185 | - The SCRIPT argument is the name of a file that is the CGI script | |
| 186 | - that is being run. The command name, "cgi", may be omitted if | |
| 187 | - the GATEWAY_INTERFACE environment variable is set to "CGI" (which | |
| 188 | - should always be the case for CGI scripts run by a webserver.) The | |
| 189 | - SCRIPT file should look something like this: | |
| 190 | - | |
| 191 | - #!/usr/bin/fossil | |
| 192 | - repository: /home/somebody/project.db | |
| 193 | - | |
| 194 | - The second line defines the name of the repository. After locating | |
| 195 | - the repository, fossil will generate a webpage on stdout based on | |
| 196 | - the values of standard CGI environment variables. | |
| 197 | - | |
| 198 | -<hr><a href="#tof">ˆ</a> | |
| 199 | - <a name="changes">Usage: </a><a href="cmd_changes.wiki">fossil changes</a> | |
| 200 | - Report on the edit status of all files in the current checkout. | |
| 201 | - See also the "status" and "extra" commands. | |
| 202 | - | |
| 203 | -<hr><a href="#tof">ˆ</a> | |
| 204 | - <a name="checkout">Usage: </a><a href="cmd_checkout.wiki">fossil checkout</a> VERSION ?-f|--force? | |
| 205 | - Check out a version specified on the command-line. This command | |
| 206 | - will not overwrite edited files in the current checkout unless | |
| 207 | - the --force option appears on the command-line. | |
| 208 | - | |
| 209 | - See also the "update" command. | |
| 210 | - | |
| 211 | -<hr><a href="#tof">ˆ</a> | |
| 212 | - <a name="commit">Usage: </a><a href="cmd_commit.wiki">fossil commit</a> ?-m COMMENT? ?--nosign? ?FILE...? fossil ci ... (as above) | |
| 213 | - | |
| 214 | - Create a new version containing all of the changes in the current | |
| 215 | - checkout. You will be prompted to enter a check-in comment unless | |
| 216 | - the "-m" option is used to specify a comment line. You will be | |
| 217 | - prompted for your GPG passphrase in order to sign the new manifest | |
| 218 | - unless the "--nosign" option is used. All files that have | |
| 219 | - changed will be committed unless some subset of files is specified | |
| 220 | - on the command line. | |
| 221 | - | |
| 222 | -<hr><a href="#tof">ˆ</a> | |
| 223 | - <a name="clean">Usage: </a><a href="cmd_clean.wiki">fossil clean</a> ?-all? | |
| 224 | - Delete all "extra" files in the source tree. "Extra" files are | |
| 225 | - files that are not officially part of the checkout. See also | |
| 226 | - the "extra" command. This operation cannot be undone. | |
| 227 | - | |
| 228 | - You will be prompted before removing each file. If you are | |
| 229 | - sure you wish to remove all "extra" files you can specify the | |
| 230 | - optional -all flag. | |
| 231 | - | |
| 232 | -<hr><a href="#tof">ˆ</a> | |
| 233 | - <a name="clone">Usage: </a><a href="cmd_clone.wiki">fossil clone</a> URL FILENAME | |
| 234 | - Make a clone of a repository specified by URL in the local | |
| 235 | - file named FILENAME. | |
| 236 | - | |
| 237 | -<hr><a href="#tof">ˆ</a> | |
| 238 | - <a name="close">Usage: </a><a href="cmd_close.wiki">fossil close</a> ?-f|--force? | |
| 239 | - The opposite of "open". Close the current database connection. | |
| 240 | - Require a -f or --force flag if there are unsaved changed in the | |
| 241 | - current check-out. | |
| 242 | - | |
| 243 | -<hr><a href="#tof">ˆ</a> | |
| 244 | - <a name="configuration">Usage: </a><a href="cmd_configure.wiki">fossil configuration</a> METHOD ... | |
| 245 | - Where METHOD is one of: export import merge pull push reset. All methods | |
| 246 | - accept the -R or --repository option to specific a repository. | |
| 247 | - | |
| 248 | - fossil configuration export AREA FILENAME | |
| 249 | - | |
| 250 | - Write to FILENAME exported configuraton information for AREA. | |
| 251 | - AREA can be one of: all ticket skin project | |
| 252 | - | |
| 253 | - fossil configuration import FILENAME | |
| 254 | - | |
| 255 | - Read a configuration from FILENAME, overwriting the current | |
| 256 | - configuration. | |
| 257 | - | |
| 258 | - fossil configuration merge FILENAME | |
| 259 | - | |
| 260 | - Read a configuration from FILENAME and merge its values into | |
| 261 | - the current configuration. Existing values take priority over | |
| 262 | - values read from FILENAME. | |
| 263 | - | |
| 264 | - fossil configuration pull AREA ?URL? | |
| 265 | - | |
| 266 | - Pull and install the configuration from a different server | |
| 267 | - identified by URL. If no URL is specified, then the default | |
| 268 | - server is used. | |
| 269 | - fossil configuration push AREA ?URL? | |
| 270 | - | |
| 271 | - Push the local configuration into the remote server identified | |
| 272 | - by URL. Admin privilege is required on the remote server for | |
| 273 | - this to work. | |
| 274 | - | |
| 275 | - fossil configuration reset AREA | |
| 276 | - | |
| 277 | - Restore the configuration to the default. AREA as above. | |
| 278 | - | |
| 279 | - WARNING: Do not import, merge, or pull configurations from an untrusted | |
| 280 | - source. The inbound configuration is not checked for safety and can | |
| 281 | - introduce security vulnerabilities. | |
| 282 | - | |
| 283 | -<hr><a href="#tof">ˆ</a> | |
| 284 | - COMMAND: deconstruct | |
| 285 | - <a name="deconstruct">Usage: </a><a href="cmd_deconstruct.wiki">fossil deconstruct</a> ?-R|--repository REPOSITORY? DESTINATION | |
| 286 | - Populates the indicated DESTINATION directory with copies of all | |
| 287 | - artifcats contained within the repository. Artifacts are named AA/bbbbb | |
| 288 | - where AA is the first 2 characters of the artifact ID and bbbbb is the | |
| 289 | - remaining 38 characters. | |
| 290 | - | |
| 291 | -<hr><a href="#tof">ˆ</a> | |
| 292 | - <a name="rm">Usage: </a><a href="cmd_rm.wiki">fossil rm</a> FILE... or: fossil del FILE... | |
| 293 | - Remove one or more files from the tree. | |
| 294 | - | |
| 295 | -<hr><a href="#tof">ˆ</a> | |
| 296 | - <a name="descendants">Usage: </a><a href="cmd_descendants.wiki">fossil descendants</a> ?CHECKIN-ID? | |
| 297 | - Find all leaf descendants of the check-in specified or if the argument | |
| 298 | - is omitted, of the check-in currently checked out. | |
| 299 | - | |
| 300 | -<hr><a href="#tof">ˆ</a> | |
| 301 | - <a name="diff">Usage: </a><a href="cmd_diff.wiki">fossil diff</a>|gdiff ?-i? ?-r REVISION? FILE... | |
| 302 | - Show the difference between the current version of a file (as it | |
| 303 | - exists on disk) and that same file as it was checked out. | |
| 304 | - | |
| 305 | - diff will show a textual diff while gdiff will attempt to run a | |
| 306 | - graphical diff command that you have setup. If the choosen command | |
| 307 | - is not yet configured, the internal textual diff command will be | |
| 308 | - used. | |
| 309 | - | |
| 310 | - If -i is supplied for either diff or gdiff, the internal textual | |
| 311 | - diff command will be executed. | |
| 312 | - | |
| 313 | - Here are a few external diff command settings, for example: | |
| 314 | - | |
| 315 | - fossil setting diff-command diff | |
| 316 | - | |
| 317 | - fossil setting gdiff-command tkdiff | |
| 318 | - fossil setting gdiff-command eskill22 | |
| 319 | - fossil setting gdiff-command tortoisemerge | |
| 320 | - fossil setting gdiff-command meld | |
| 321 | - fossil setting gdiff-command xxdiff | |
| 322 | - fossil setting gdiff-command kdiff3 | |
| 323 | - | |
| 324 | -<hr><a href="#tof">ˆ</a> | |
| 325 | - <a name="extra">Usage: </a><a href="cmd_extra.wiki">fossil extra</a> | |
| 326 | - Print a list of all files in the source tree that are not part of | |
| 327 | - the current checkout. See also the "clean" command. | |
| 328 | - | |
| 329 | -<hr><a href="#tof">ˆ</a> | |
| 330 | - <a name="help">Usage: </a><a href="cmd_help.wiki">fossil help</a> COMMAND | |
| 331 | - Display information on how to use COMMAND | |
| 332 | - | |
| 333 | -<hr><a href="#tof">ˆ</a> | |
| 334 | - <a name="http">Usage: </a><a href="cmd_http.wiki">fossil http</a> REPOSITORY | |
| 335 | - Handle a single HTTP request appearing on stdin. The resulting webpage | |
| 336 | - is delivered on stdout. This method is used to launch an HTTP request | |
| 337 | - handler from inetd, for example. The argument is the name of the repository. | |
| 338 | - | |
| 339 | -<hr><a href="#tof">ˆ</a> | |
| 340 | - <a name="info">Usage: </a><a href="cmd_info.wiki">fossil info</a> ?ARTIFACT-ID|FILENAME? | |
| 341 | - With no arguments, provide information about the current tree. | |
| 342 | - If an argument is specified, provide information about the object | |
| 343 | - in the respository of the current tree that the argument refers | |
| 344 | - to. Or if the argument is the name of a repository, show | |
| 345 | - information about that repository. | |
| 346 | - | |
| 347 | -<hr><a href="#tof">ˆ</a> | |
| 348 | - <a name="leaves">Usage: </a><a href="cmd_leaves.wiki">fossil leaves</a> | |
| 349 | - Find leaves of all branches. | |
| 350 | - | |
| 351 | -<hr><a href="#tof">ˆ</a> | |
| 352 | - <a name="ls">Usage: </a><a href="cmd_ls.wiki">fossil ls</a> | |
| 353 | - Show the names of all files in the current checkout | |
| 354 | - | |
| 355 | -<hr><a href="#tof">ˆ</a> | |
| 356 | - <a name="merge">Usage: </a><a href="cmd_merge.wiki">fossil merge</a> VERSION | |
| 357 | - The argument is a version that should be merged into the current | |
| 358 | - checkout. | |
| 359 | - Only file content is merged. The result continues to use the | |
| 360 | - file and directory names from the current check-out even if those | |
| 361 | - names might have been changed in the branch being merged in. | |
| 362 | - | |
| 363 | -<hr><a href="#tof">ˆ</a> | |
| 364 | - <a name="mv">Usage: </a><a href="cmd_mv.wiki">fossil mv|rename</a> OLDNAME NEWNAME or: fossil mv|rename OLDNAME... DIR | |
| 365 | - | |
| 366 | - Move or rename one or more files within the tree | |
| 367 | - | |
| 368 | - This command does not rename the files on disk. All this command does is | |
| 369 | - record the fact that filenames have changed so that appropriate notations | |
| 370 | - can be made at the next commit/checkin. | |
| 371 | - | |
| 372 | -<hr><a href="#tof">ˆ</a> | |
| 373 | - <a name="new">Usage: </a><a href="cmd_new.wiki">fossil new</a> FILENAME | |
| 374 | - | |
| 375 | - Create a repository for a new project in the file named FILENAME. | |
| 376 | - This command is distinct from "clone". The "clone" command makes | |
| 377 | - a copy of an existing project. This command starts a new project. | |
| 378 | - | |
| 379 | -<hr><a href="#tof">ˆ</a> | |
| 380 | - <a name="open">Usage: </a><a href="cmd_open.wiki">fossil open</a> FILENAME | |
| 381 | - Open a connection to the local repository in FILENAME. A checkout | |
| 382 | - for the repository is created with its root at the working directory. | |
| 383 | - See also the "close" command. | |
| 384 | - | |
| 385 | -<hr><a href="#tof">ˆ</a> | |
| 386 | - <a name="rstats">Usage: </a><a href="cmd_rstats.wiki">fossil rstats</a> | |
| 387 | - | |
| 388 | - Deliver a report of the repository statistics for the | |
| 389 | - current checkout. | |
| 390 | - | |
| 391 | -<hr><a href="#tof">ˆ</a> | |
| 392 | - <a name="pull">Usage: </a><a href="cmd_pull.wiki">fossil pull</a> ?URL? ?-R|--respository REPOSITORY? | |
| 393 | - Pull changes in a remote repository into the local repository. | |
| 394 | - The repository is identified by the -R or --repository option. | |
| 395 | - If there is no such option then the open repository is used. | |
| 396 | - The URL of the remote server is specified on the command line | |
| 397 | - If no URL is specified then the URL used by the most recent | |
| 398 | - "pull", "push", or "sync" command is used. | |
| 399 | - | |
| 400 | - The URL is of the following form: | |
| 401 | - | |
| 402 | - http://USER@HOST:PORT/PATH | |
| 403 | - | |
| 404 | - The "USER@" and ":PORT" substrings are optional. | |
| 405 | - The "USER" substring specifies the login user. You will be | |
| 406 | - prompted for the password on the command-line. The PORT | |
| 407 | - specifies the TCP port of the server. The default port is | |
| 408 | - 80. | |
| 409 | - | |
| 410 | -<hr><a href="#tof">ˆ</a> | |
| 411 | - <a name="push">Usage: </a><a href="cmd_push.wiki">fossil push</a> ?URL? ?-R|--repository REPOSITORY? | |
| 412 | - Push changes in the local repository over into a remote repository. | |
| 413 | - See the "pull" command for additional information. | |
| 414 | - | |
| 415 | -<hr><a href="#tof">ˆ</a> | |
| 416 | - <a name="rebuild">Usage: </a><a href="cmd_rebuild.wiki">fossil rebuild</a> REPOSITORY | |
| 417 | - Reconstruct the named repository database from the core | |
| 418 | - records. Run this command after updating the fossil | |
| 419 | - executable in a way that changes the database schema. | |
| 420 | - | |
| 421 | -<hr><a href="#tof">ˆ</a> | |
| 422 | - COMMAND: reconstruct | |
| 423 | - <a name="reconstruct">Usage: </a><a href="cmd_reconstruct.wiki">fossil reconstruct</a> REPOSITORY ORIGIN | |
| 424 | - Creates the REPOSITORY and populates it with the artifacts in the | |
| 425 | - indicated ORIGIN directory. | |
| 426 | - | |
| 427 | -<hr><a href="#tof">ˆ</a> | |
| 428 | - <a name="redo">Usage: </a><a href="cmd_redo.wiki">fossil redo</a> ?FILENAME...? | |
| 429 | - Redo the an update or merge operation that has been undone by the | |
| 430 | - undo command. If FILENAME is specified then restore the changes | |
| 431 | - associated with the named file(s) but otherwise leave the update | |
| 432 | - or merge undone. | |
| 433 | - | |
| 434 | - A single level of undo/redo is supported. The undo/redo stack | |
| 435 | - is cleared by the commit and checkout commands. | |
| 436 | - | |
| 437 | -<hr><a href="#tof">ˆ</a> | |
| 438 | - <a name="revert">Usage: </a><a href="cmd_revert.wiki">fossil revert</a> ?--yes? ?-r CHECKIN? FILE | |
| 439 | - Revert to the current repository version of FILE, or to | |
| 440 | - the version associated with check-in CHECKIN if the -r flag | |
| 441 | - appears. This command will confirm your operation unless the | |
| 442 | - file is missing or the --yes option is used. | |
| 443 | - | |
| 444 | -<hr><a href="#tof">ˆ</a> | |
| 445 | - <a name="server">Usage: </a><a href="cmd_server.wiki">fossil server</a> ?-P|--port TCPPORT? ?REPOSITORY? Or: fossil ui ?-P|--port TCPPORT? ?REPOSITORY? | |
| 446 | - | |
| 447 | - Open a socket and begin listening and responding to HTTP requests on | |
| 448 | - TCP port 8080, or on any other TCP port defined by the -P or | |
| 449 | - --port option. The optional argument is the name of the repository. | |
| 450 | - The repository argument may be omitted if the working directory is | |
| 451 | - within an open checkout. | |
| 452 | - | |
| 453 | - The "ui" command automatically starts a web browser after initializing | |
| 454 | - the web server. | |
| 455 | - | |
| 456 | -<hr><a href="#tof">ˆ</a> | |
| 457 | - COMMAND: settings | |
| 458 | - COMMAND: unset | |
| 459 | - <a name="settings">Usage: </a><a href="cmd_setting.wiki">fossil settings</a> ?PROPERTY? ?VALUE? ?-global? | |
| 460 | - fossil unset PROPERTY ?-global? | |
| 461 | - | |
| 462 | - The "settings" command with no arguments lists all properties and their | |
| 463 | - values. With just a property name it shows the value of that property. | |
| 464 | - With a value argument it changes the property for the current repository. | |
| 465 | - | |
| 466 | - The "unset" command clears a property setting. | |
| 467 | - | |
| 468 | - autosync If enabled, automatically pull prior to | |
| 469 | - commit or update and automatically push | |
| 470 | - after commit or tag or branch creation. | |
| 471 | - | |
| 472 | - diff-command External command to run when performing a diff. | |
| 473 | - If undefined, the internal text diff will be used. | |
| 474 | - | |
| 475 | - editor Text editor command used for check-in comments. | |
| 476 | - | |
| 477 | - http-port The TCP/IP port number to use by the "server" | |
| 478 | - and "ui" commands. Default: 8080 | |
| 479 | - | |
| 480 | - gdiff-command External command to run when performing a graphical | |
| 481 | - diff. If undefined, text diff will be used. | |
| 482 | - | |
| 483 | - localauth If enabled, require that HTTP connections from | |
| 484 | - 127.0.0.1 be authenticated by password. If | |
| 485 | - false, all HTTP requests from localhost have | |
| 486 | - unrestricted access to the repository. | |
| 487 | - | |
| 488 | - clearsign When enabled (the default), fossil will attempt to | |
| 489 | - sign all commits with gpg. When disabled, commits will | |
| 490 | - be unsigned. | |
| 491 | - | |
| 492 | - pgp-command Command used to clear-sign manifests at check-in. | |
| 493 | - The default is "gpg --clearsign -o ". | |
| 494 | - | |
| 495 | - mtime-changes Use file modification times (mtimes) to detect when | |
| 496 | - files have been modified. | |
| 497 | - | |
| 498 | - proxy URL of the HTTP proxy. If undefined or "on" then | |
| 499 | - the "http_proxy" environment variable is consulted. | |
| 500 | - If the http_proxy environment variable is undefined | |
| 501 | - then a direct HTTP connection is used. | |
| 502 | - | |
| 503 | - web-browser A shell command used to launch your preferred | |
| 504 | - web browser when given a URL as an argument. | |
| 505 | - Defaults to "start" on windows, "open" on Mac, | |
| 506 | - and "firefox" on Unix. | |
| 507 | - | |
| 508 | -<hr><a href="#tof">ˆ</a> | |
| 509 | - <a name="status">Usage: </a><a href="cmd_status.wiki">fossil status</a> | |
| 510 | - Report on the status of the current checkout. | |
| 511 | - | |
| 512 | -<hr><a href="#tof">ˆ</a> | |
| 513 | - <a name="sync">Usage: </a><a href="cmd_sync.wiki">fossil sync</a> ?URL? ?-R|--repository REPOSITORY? | |
| 514 | - Synchronize the local repository with a remote repository. This is | |
| 515 | - the equivalent of running both "push" and "pull" at the same time. | |
| 516 | - See the "pull" command for additional information. | |
| 517 | - | |
| 518 | -<hr><a href="#tof">ˆ</a> | |
| 519 | - <a name="tag">Usage: </a><a href="cmd_tag.wiki">fossil tag</a> SUBCOMMAND ... | |
| 520 | - Run various subcommands to control tags and properties | |
| 521 | - | |
| 522 | - fossil tag add ?--raw? TAGNAME CHECK-IN ?VALUE? | |
| 523 | - | |
| 524 | - Add a new tag or property to CHECK-IN. The tag will | |
| 525 | - be usable instead of a CHECK-IN in commands such as | |
| 526 | - update and merge. | |
| 527 | - | |
| 528 | - fossil tag branch ?--raw? ?--nofork? TAGNAME CHECK-IN ?VALUE? | |
| 529 | - | |
| 530 | - A fork will be created so that the new checkin | |
| 531 | - is a sibling of CHECK-IN and identical to it except | |
| 532 | - for a generated comment. Then the new tag will | |
| 533 | - be added to the new checkin and propagated to | |
| 534 | - all direct children. Additionally all symbolic | |
| 535 | - tags of that checkin inherited from CHECK-IN will | |
| 536 | - be cancelled. | |
| 537 | - | |
| 538 | - However, if the option --nofork is given, no | |
| 539 | - fork will be created and the tag/property will be | |
| 540 | - added to CHECK-IN directly. No tags will be canceled. | |
| 541 | - | |
| 542 | - fossil tag cancel ?--raw? TAGNAME CHECK-IN | |
| 543 | - | |
| 544 | - Remove the tag TAGNAME from CHECK-IN, and also remove | |
| 545 | - the propagation of the tag to any descendants. | |
| 546 | - | |
| 547 | - fossil tag find ?--raw? TAGNAME | |
| 548 | - | |
| 549 | - List all check-ins that use TAGNAME | |
| 550 | - | |
| 551 | - fossil tag list ?--raw? ?CHECK-IN? | |
| 552 | - | |
| 553 | - List all tags, or if CHECK-IN is supplied, list | |
| 554 | - all tags and their values for CHECK-IN. | |
| 555 | - | |
| 556 | - The option --raw allows the manipulation of all types of | |
| 557 | - tags used for various internal purposes in fossil. You | |
| 558 | - should not use this option to make changes unless you are | |
| 559 | - sure what you are doing. | |
| 560 | - | |
| 561 | - If you need to use a tagname that might be confused with | |
| 562 | - a hexadecimal check-in or artifact ID, you can explicitly | |
| 563 | - disambiguate it by prefixing it with "tag:". For instance: | |
| 564 | - | |
| 565 | - fossil update decaf | |
| 566 | - | |
| 567 | - will be taken as an artifact or check-in ID and fossil will | |
| 568 | - probably complain that no such revision was found. However | |
| 569 | - | |
| 570 | - fossil update tag:decaf | |
| 571 | - | |
| 572 | - will assume that "decaf" is a tag/branch name. | |
| 573 | - | |
| 574 | -<hr><a href="#tof">ˆ</a> | |
| 575 | - <a name="timeline">Usage: </a><a href="cmd_timeline.wiki">fossil timeline</a> ?WHEN? ?CHECK-IN|DATETIME? ?-n|--count N? | |
| 576 | - Print a summary of activity going backwards in date and time | |
| 577 | - specified or from the current date and time if no arguments | |
| 578 | - are given. Show as many as N (default 20) check-ins. The | |
| 579 | - WHEN argument can be any unique abbreviation of one of these | |
| 580 | - keywords: | |
| 581 | - | |
| 582 | - before | |
| 583 | - after | |
| 584 | - descendants | children | |
| 585 | - ancestors | parents | |
| 586 | - | |
| 587 | - The CHECK-IN can be any unique prefix of 4 characters or more. | |
| 588 | - The DATETIME should be in the ISO8601 format. For | |
| 589 | - examples: "2007-08-18 07:21:21". You can also say "current" | |
| 590 | - for the current version or "now" for the current time. | |
| 591 | - | |
| 592 | -<hr><a href="#tof">ˆ</a> | |
| 593 | - <a name="undo">Usage: </a><a href="cmd_undo.wiki">fossil undo</a> ?FILENAME...? | |
| 594 | - Undo the most recent update or merge operation. If FILENAME is | |
| 595 | - specified then restore the content of the named file(s) but otherwise | |
| 596 | - leave the update or merge in effect. | |
| 597 | - | |
| 598 | - A single level of undo/redo is supported. The undo/redo stack | |
| 599 | - is cleared by the commit and checkout commands. | |
| 600 | - | |
| 601 | -<hr><a href="#tof">ˆ</a> | |
| 602 | - <a name="update">Usage: </a><a href="cmd_update.wiki">fossil update</a> ?VERSION? ?--latest? | |
| 603 | - The optional argument is a version that should become the current | |
| 604 | - version. If the argument is omitted, then use the leaf of the | |
| 605 | - tree that begins with the current version, if there is only a single leaf. If there are a multiple leaves, the latest is used | |
| 606 | - if the --latest flag is present. | |
| 607 | - | |
| 608 | - This command is different from the "checkout" in that edits are | |
| 609 | - not overwritten. Edits are merged into the new version. | |
| 610 | - | |
| 611 | -<hr><a href="#tof">ˆ</a> | |
| 612 | - <a name="user">Usage: </a><a href="cmd_user.wiki">fossil user</a> SUBCOMMAND ... ?-R|--repository FILE? | |
| 613 | - Run various subcommands on users of the open repository or of | |
| 614 | - the repository identified by the -R or --repository option. | |
| 615 | - | |
| 616 | - fossil user capabilities USERNAME ?STRING? | |
| 617 | - | |
| 618 | - Query or set the capabilities for user USERNAME | |
| 619 | - | |
| 620 | - fossil user default ?USERNAME? | |
| 621 | - | |
| 622 | - Query or set the default user. The default user is the | |
| 623 | - user for command-line interaction. | |
| 624 | - | |
| 625 | - fossil user list | |
| 626 | - | |
| 627 | - List all users known to the repository | |
| 628 | - | |
| 629 | - fossil user new ?USERNAME? | |
| 630 | - | |
| 631 | - Create a new user in the repository. Users can never be | |
| 632 | - deleted. They can be denied all access but they must continue | |
| 633 | - to exist in the database. | |
| 634 | - | |
| 635 | - fossil user password USERNAME | |
| 636 | - | |
| 637 | - Change the web access password for a user. | |
| 638 | - | |
| 639 | -<hr><a href="#tof">ˆ</a> | |
| 640 | - <a name="version">Usage: </a><a href="cmd_version.wiki">fossil version</a> | |
| 641 | - Print the source code version number for the fossil executable. | |
| 642 | - | |
| 643 | -<hr><a href="#tof">ˆ</a> | |
| 644 | - <a name="wiki">Usage: </a><a href="cmd_wiki.wiki">fossil wiki</a> (export|create|commit|list) WikiName | |
| 645 | - Run various subcommands to fetch wiki entries. | |
| 646 | - | |
| 647 | - fossil wiki export PAGENAME ?FILE? | |
| 648 | - | |
| 649 | - Sends the latest version of the PAGENAME wiki | |
| 650 | - entry to the given file or standard output. | |
| 651 | - | |
| 652 | - fossil wiki commit PAGENAME ?FILE? | |
| 653 | - | |
| 654 | - Commit changes to a wiki page from FILE or from standard. | |
| 655 | - | |
| 656 | - fossil wiki create PAGENAME ?FILE? | |
| 657 | - | |
| 658 | - Create a new wiki page with initial content taken from | |
| 659 | - FILE or from standard input. | |
| 660 | - | |
| 661 | - fossil wiki list | |
| 662 | - | |
| 663 | - Lists all wiki entries, one per line, ordered | |
| 664 | - case-insentively by name. | |
| 665 | - | |
| 666 | - TODOs: | |
| 667 | - | |
| 668 | - fossil wiki export ?-u ARTIFACT? WikiName ?FILE? | |
| 669 | - | |
| 670 | - Outputs the selected version of WikiName. | |
| 671 | - | |
| 672 | - fossil wiki delete ?-m MESSAGE? WikiName | |
| 673 | - | |
| 674 | - The same as deleting a file entry, but i don't know if fossil | |
| 675 | - supports a commit message for Wiki entries. | |
| 676 | - | |
| 677 | - fossil wiki ?-u? ?-d? ?-s=[|]? list | |
| 678 | - | |
| 679 | - Lists the artifact ID and/or Date of last change along with | |
| 680 | - each entry name, delimited by the -s char. | |
| 681 | - | |
| 682 | - fossil wiki diff ?ARTIFACT? ?-f infile[=stdin]? EntryName | |
| 683 | - | |
| 684 | - Diffs the local copy of a page with a given version (defaulting | |
| 685 | - to the head version). | |
| 686 | - | |
| 687 | - </pre></nowiki> | |
| 688 | - | |
| 689 | - <hr><a href="#tof">ˆ</a> | |
| 690 | - | |
| 691 | - <h3>Caveats</h3> | |
| 692 | - This is not actually a reference, it's the start of a reference. | |
| 693 | - There are wikilinks to uncreated pages for the commands. This was | |
| 694 | - created by running the fossil help for each command listed by running | |
| 695 | - fossil help... Duplicate commands are only listed once (I | |
| 696 | - <i>think</i>). There are several bits of <b>fossil</b> that are not addressed | |
| 697 | - in the help for commands (special wiki directories, special users, etc.) | |
| 698 | - so they are (currently) not addressed here. Clarity and brevity may be | |
| 699 | - sacrificed for expediency at the authors indiscretion. All spelling and | |
| 700 | - grammatical mistakes are somebody elses fault.<code> void * </code> | |
| 701 | - prohibited where<code> __C_PLUS_PLUS__ </code>. Title and taxes extra. | |
| 702 | - Not valid in Hooptigonia. |
| --- a/www/reference.wiki | |
| +++ b/www/reference.wiki | |
| @@ -1,702 +0,0 @@ | |
| 1 | <h2>Command Line Interface Reference</h2> |
| 2 | |
| 3 | This is an easy introduction to the fossil command line interface |
| 4 | (cli). It assumes some familiarity with using the command line, and |
| 5 | with Source Code Maintenence (SCM) systems—but not <i>too</i> |
| 6 | much. |
| 7 | |
| 8 | If you are trying to find information about fossil's web |
| 9 | capabilities, see the <a href="index.wiki">Fossil Home</a> and |
| 10 | <a href="wikitheory.wiki">Fossil Wiki</a> pages for pointers. |
| 11 | |
| 12 | <h3>Things to note</h3> |
| 13 | * Fossil cli commands do not use special delimeters, they use |
| 14 | spaces. This is traditional with VCS/SCM. Some <i>options</i> to |
| 15 | fossil commands <i>do</i> use special delimiters, particularly the |
| 16 | '-' (hyphen, or dash) character. This is very similar to Tcl. |
| 17 | Think of fossil as a shell you invoke and feed a command to, |
| 18 | including any options, and it will make more sense. |
| 19 | |
| 20 | * Any fossil command is acceptable once enough of it has been |
| 21 | entered to make the intent unambiguous. 'clo' is a proper prefix of |
| 22 | both the 'clone' and 'close' commands, for instance, but 'clon' is |
| 23 | enough to make the intent—the 'clone' |
| 24 | command—unambiguous. |
| 25 | |
| 26 | * Pragmatically, a [./concepts.wiki#keyconc | <u>version</u>] |
| 27 | in <b>fossil</b> is a 40-character long string of hexadecimal. |
| 28 | <b>fossil</b> will be able to figure out which version you want |
| 29 | with any <i>distinct</i> prefix of that string which is at |
| 30 | least four characters long. <em>Commands which require a |
| 31 | version are looking for the string, a distinct prefix of the |
| 32 | string, or a <code>tag</code>.</em> |
| 33 | |
| 34 | * SCM in a distributed environment can be a bit confusing with |
| 35 | regard to branching, merging, and versions in general. See the |
| 36 | [./branching.wiki | explanation of branching] and it will all make |
| 37 | much more sense. |
| 38 | |
| 39 | * <i>Op.Ed.</i> An excellent way to learn to use <b>fossil</b> |
| 40 | effectively is to |
| 41 | [./quickstart.wiki#fslclone | clone the repository for fossil] |
| 42 | itself. You can then poke around using the <code>fossil ui</code> |
| 43 | command, and look things up with no connection worries. You can |
| 44 | set up test repositories and try things out on-the-fly to see how |
| 45 | they work, using their own ui's. The CLI will far easier to |
| 46 | understand if you can run a repository, watch it in a browser, and |
| 47 | hack around with it in a simplified environment (your tests) with |
| 48 | guaranteed and fast access to the sources & docs (your cloned fossil |
| 49 | repository). |
| 50 | <br /><br /> <br /> |
| 51 | <b>You should</b> probably start interacting with fossil at the command |
| 52 | line by asking it what it can |
| 53 | do: <a name="tof">ˆ</a> |
| 54 | |
| 55 | <code>$ fossil help</code><nowiki><pre> |
| 56 | Usage: fossil help COMMAND. |
| 57 | Available COMMANDs:</pre><table width="80%" |
| 58 | style="font-family: fixed, courier, monospace;"> |
| 59 | <tr> |
| 60 | <td><a href="#add">add</a>*</td> |
| 61 | <td><a href="#checkout">co</a>*</td> |
| 62 | <td><a href="#http">http</a></td> |
| 63 | <td><a href="#rebuild">rebuild</a></td> |
| 64 | <td><a href="#sync">sync</a>*</td> |
| 65 | </tr> |
| 66 | <tr> |
| 67 | <td><a href="#all">all</a>*</td> |
| 68 | <td><a href="#commit">commit</a></td> |
| 69 | <td><a href="#info">info</a></td> |
| 70 | <td><a href="#reconstruct">reconstruct</a></td> |
| 71 | <td><a href="#tag">tag</a></td> |
| 72 | </tr> |
| 73 | <tr> |
| 74 | <td><a href="#branch">branch</a></td> |
| 75 | <td><a href="#configuration">configuration</a></td> |
| 76 | <td><a href="#leaves">leaves</a></td> |
| 77 | <td><a href="#redo">redo</a></td> |
| 78 | <td><a href="#timeline">timeline</a></td> |
| 79 | </tr> |
| 80 | <tr> |
| 81 | <td><a href="#cgi">cgi</a>*</td> |
| 82 | <td><a href="#deconstruct">deconstruct</a></td> |
| 83 | <td><a href="#ls">ls</a>*</td> |
| 84 | <td><a href="#mv">rename</a>*</td> |
| 85 | <td><a href="#server">ui</a></td> |
| 86 | </tr> |
| 87 | <tr> |
| 88 | <td><a href="#changes">changes</a>*</td> |
| 89 | <td><a href="#rm">del</a>*</td> |
| 90 | <td><a href="#merge">merge</a></td> |
| 91 | <td><a href="#revert">revert</a></td> |
| 92 | <td><a href="#undo">undo</a></td> |
| 93 | </tr> |
| 94 | <tr> |
| 95 | <td><a href="#checkout">checkout</a>*</td> |
| 96 | <td><a href="#descendants">descendants</a></td> |
| 97 | <td><a href="#mv">mv</a>*</td> |
| 98 | <td><a href="#rm">rm</a>*</td> |
| 99 | <td><a href="#settings">unset</a></td> |
| 100 | </tr> |
| 101 | <tr> |
| 102 | <td><a href="#commit">ci</a></td> |
| 103 | <td><a href="#diff">diff</a></td> |
| 104 | <td><a href="#new">new</a>*</td> |
| 105 | <td><a href="#rstats">rstats</a></td> |
| 106 | <td><a href="#update">update</a>*</td> |
| 107 | </tr> |
| 108 | <tr> |
| 109 | <td><a href="#clean">clean</a></td> |
| 110 | <td><a href="#extra">extra</a>*</td> |
| 111 | <td><a href="#open">open</a></td> |
| 112 | <td><a href="#server">server</a></td> |
| 113 | <td><a href="#user">user</a></td> |
| 114 | </tr> |
| 115 | <tr> |
| 116 | <td><a href="#clone">clone</a></td> |
| 117 | <td><a href="#diff">gdiff</a></td> |
| 118 | <td><a href="#pull">pull</a></td> |
| 119 | <td><a href="#settings">settings</a></td> |
| 120 | <td><a href="#version">version</a>*</td> |
| 121 | </tr> |
| 122 | <tr> |
| 123 | <td><a href="#close">close</a></td> |
| 124 | <td><a href="#help">help</a></td> |
| 125 | <td><a href="#push">push</a></td> |
| 126 | <td><a href="#status">status</a>*</td> |
| 127 | <td><a href="#wiki">wiki</a></td> |
| 128 | </tr> |
| 129 | </table><nowiki><pre> |
| 130 | This is fossil version [a89b436bc9] 2009-02-11 05:00:02 UTC |
| 131 | </pre> |
| 132 | <b>What follows</b> is a survey of what you get if you type<code> |
| 133 | fossil help <i>command</i> </code>for all of the |
| 134 | commands listed above. There are links to individual pages for each |
| 135 | of them; pages with content (commands marked with a '*' are done) go |
| 136 | into the reason for a command in a bit more depth than the program help. |
| 137 | <pre> |
| 138 | <hr><a href="#tof">ˆ</a> |
| 139 | <a name="add">Usage: </a><code><a href="cmd_add.wiki">fossil add</a></code> FILE... |
| 140 | Make arrangements to add one or more files to the current checkout |
| 141 | at the next commit. |
| 142 | |
| 143 | <hr><a href="#tof">ˆ</a> |
| 144 | <a name="all">Usage: </a><code><a href="cmd_all.wiki">fossil all</a></code> (list|pull|push|rebuild|sync) |
| 145 | The ~/.fossil file records the location of all repositories for a |
| 146 | user. This command performs certain operations on all repositories |
| 147 | that can be useful before or after a period of disconnection operation. |
| 148 | |
| 149 | On Win32 systems, this file is located in %LOCALAPPDATA%, %APDDATA% |
| 150 | or %HOMEPATH% and is named _fossil. |
| 151 | |
| 152 | Available operations are: |
| 153 | |
| 154 | list Display the location of all repositories |
| 155 | |
| 156 | pull Run a "pull" operation on all repositories |
| 157 | |
| 158 | push Run a "push" on all repositories |
| 159 | |
| 160 | rebuild Rebuild on all repositories |
| 161 | |
| 162 | sync Run a "sync" on all repositories |
| 163 | |
| 164 | Respositories are automatically added to the set of known repositories |
| 165 | when one of the following commands against the repository: clone, info, |
| 166 | pull, push, or sync |
| 167 | |
| 168 | <hr><a href="#tof">ˆ</a> |
| 169 | <a name="branch">Usage: </a><code><a href="cmd_branch.wiki">fossil branch</a></code> SUBCOMMAND ... ?-R|--repository FILE? |
| 170 | |
| 171 | Run various subcommands on the branches of the open repository or |
| 172 | of the repository identified by the -R or --repository option. |
| 173 | |
| 174 | fossil branch new BRANCH-NAME BASIS ?-bgcolor COLOR? |
| 175 | |
| 176 | Create a new branch BRANCH-NAME off of check-in BASIS. |
| 177 | You can optionally give the branch a default color. |
| 178 | |
| 179 | fossil branch list |
| 180 | |
| 181 | List all branches |
| 182 | |
| 183 | <hr><a href="#tof">ˆ</a> |
| 184 | <a name="cgi">Usage: </a><a href="cmd_cgi.wiki">fossil cgi</a> SCRIPT |
| 185 | The SCRIPT argument is the name of a file that is the CGI script |
| 186 | that is being run. The command name, "cgi", may be omitted if |
| 187 | the GATEWAY_INTERFACE environment variable is set to "CGI" (which |
| 188 | should always be the case for CGI scripts run by a webserver.) The |
| 189 | SCRIPT file should look something like this: |
| 190 | |
| 191 | #!/usr/bin/fossil |
| 192 | repository: /home/somebody/project.db |
| 193 | |
| 194 | The second line defines the name of the repository. After locating |
| 195 | the repository, fossil will generate a webpage on stdout based on |
| 196 | the values of standard CGI environment variables. |
| 197 | |
| 198 | <hr><a href="#tof">ˆ</a> |
| 199 | <a name="changes">Usage: </a><a href="cmd_changes.wiki">fossil changes</a> |
| 200 | Report on the edit status of all files in the current checkout. |
| 201 | See also the "status" and "extra" commands. |
| 202 | |
| 203 | <hr><a href="#tof">ˆ</a> |
| 204 | <a name="checkout">Usage: </a><a href="cmd_checkout.wiki">fossil checkout</a> VERSION ?-f|--force? |
| 205 | Check out a version specified on the command-line. This command |
| 206 | will not overwrite edited files in the current checkout unless |
| 207 | the --force option appears on the command-line. |
| 208 | |
| 209 | See also the "update" command. |
| 210 | |
| 211 | <hr><a href="#tof">ˆ</a> |
| 212 | <a name="commit">Usage: </a><a href="cmd_commit.wiki">fossil commit</a> ?-m COMMENT? ?--nosign? ?FILE...? fossil ci ... (as above) |
| 213 | |
| 214 | Create a new version containing all of the changes in the current |
| 215 | checkout. You will be prompted to enter a check-in comment unless |
| 216 | the "-m" option is used to specify a comment line. You will be |
| 217 | prompted for your GPG passphrase in order to sign the new manifest |
| 218 | unless the "--nosign" option is used. All files that have |
| 219 | changed will be committed unless some subset of files is specified |
| 220 | on the command line. |
| 221 | |
| 222 | <hr><a href="#tof">ˆ</a> |
| 223 | <a name="clean">Usage: </a><a href="cmd_clean.wiki">fossil clean</a> ?-all? |
| 224 | Delete all "extra" files in the source tree. "Extra" files are |
| 225 | files that are not officially part of the checkout. See also |
| 226 | the "extra" command. This operation cannot be undone. |
| 227 | |
| 228 | You will be prompted before removing each file. If you are |
| 229 | sure you wish to remove all "extra" files you can specify the |
| 230 | optional -all flag. |
| 231 | |
| 232 | <hr><a href="#tof">ˆ</a> |
| 233 | <a name="clone">Usage: </a><a href="cmd_clone.wiki">fossil clone</a> URL FILENAME |
| 234 | Make a clone of a repository specified by URL in the local |
| 235 | file named FILENAME. |
| 236 | |
| 237 | <hr><a href="#tof">ˆ</a> |
| 238 | <a name="close">Usage: </a><a href="cmd_close.wiki">fossil close</a> ?-f|--force? |
| 239 | The opposite of "open". Close the current database connection. |
| 240 | Require a -f or --force flag if there are unsaved changed in the |
| 241 | current check-out. |
| 242 | |
| 243 | <hr><a href="#tof">ˆ</a> |
| 244 | <a name="configuration">Usage: </a><a href="cmd_configure.wiki">fossil configuration</a> METHOD ... |
| 245 | Where METHOD is one of: export import merge pull push reset. All methods |
| 246 | accept the -R or --repository option to specific a repository. |
| 247 | |
| 248 | fossil configuration export AREA FILENAME |
| 249 | |
| 250 | Write to FILENAME exported configuraton information for AREA. |
| 251 | AREA can be one of: all ticket skin project |
| 252 | |
| 253 | fossil configuration import FILENAME |
| 254 | |
| 255 | Read a configuration from FILENAME, overwriting the current |
| 256 | configuration. |
| 257 | |
| 258 | fossil configuration merge FILENAME |
| 259 | |
| 260 | Read a configuration from FILENAME and merge its values into |
| 261 | the current configuration. Existing values take priority over |
| 262 | values read from FILENAME. |
| 263 | |
| 264 | fossil configuration pull AREA ?URL? |
| 265 | |
| 266 | Pull and install the configuration from a different server |
| 267 | identified by URL. If no URL is specified, then the default |
| 268 | server is used. |
| 269 | fossil configuration push AREA ?URL? |
| 270 | |
| 271 | Push the local configuration into the remote server identified |
| 272 | by URL. Admin privilege is required on the remote server for |
| 273 | this to work. |
| 274 | |
| 275 | fossil configuration reset AREA |
| 276 | |
| 277 | Restore the configuration to the default. AREA as above. |
| 278 | |
| 279 | WARNING: Do not import, merge, or pull configurations from an untrusted |
| 280 | source. The inbound configuration is not checked for safety and can |
| 281 | introduce security vulnerabilities. |
| 282 | |
| 283 | <hr><a href="#tof">ˆ</a> |
| 284 | COMMAND: deconstruct |
| 285 | <a name="deconstruct">Usage: </a><a href="cmd_deconstruct.wiki">fossil deconstruct</a> ?-R|--repository REPOSITORY? DESTINATION |
| 286 | Populates the indicated DESTINATION directory with copies of all |
| 287 | artifcats contained within the repository. Artifacts are named AA/bbbbb |
| 288 | where AA is the first 2 characters of the artifact ID and bbbbb is the |
| 289 | remaining 38 characters. |
| 290 | |
| 291 | <hr><a href="#tof">ˆ</a> |
| 292 | <a name="rm">Usage: </a><a href="cmd_rm.wiki">fossil rm</a> FILE... or: fossil del FILE... |
| 293 | Remove one or more files from the tree. |
| 294 | |
| 295 | <hr><a href="#tof">ˆ</a> |
| 296 | <a name="descendants">Usage: </a><a href="cmd_descendants.wiki">fossil descendants</a> ?CHECKIN-ID? |
| 297 | Find all leaf descendants of the check-in specified or if the argument |
| 298 | is omitted, of the check-in currently checked out. |
| 299 | |
| 300 | <hr><a href="#tof">ˆ</a> |
| 301 | <a name="diff">Usage: </a><a href="cmd_diff.wiki">fossil diff</a>|gdiff ?-i? ?-r REVISION? FILE... |
| 302 | Show the difference between the current version of a file (as it |
| 303 | exists on disk) and that same file as it was checked out. |
| 304 | |
| 305 | diff will show a textual diff while gdiff will attempt to run a |
| 306 | graphical diff command that you have setup. If the choosen command |
| 307 | is not yet configured, the internal textual diff command will be |
| 308 | used. |
| 309 | |
| 310 | If -i is supplied for either diff or gdiff, the internal textual |
| 311 | diff command will be executed. |
| 312 | |
| 313 | Here are a few external diff command settings, for example: |
| 314 | |
| 315 | fossil setting diff-command diff |
| 316 | |
| 317 | fossil setting gdiff-command tkdiff |
| 318 | fossil setting gdiff-command eskill22 |
| 319 | fossil setting gdiff-command tortoisemerge |
| 320 | fossil setting gdiff-command meld |
| 321 | fossil setting gdiff-command xxdiff |
| 322 | fossil setting gdiff-command kdiff3 |
| 323 | |
| 324 | <hr><a href="#tof">ˆ</a> |
| 325 | <a name="extra">Usage: </a><a href="cmd_extra.wiki">fossil extra</a> |
| 326 | Print a list of all files in the source tree that are not part of |
| 327 | the current checkout. See also the "clean" command. |
| 328 | |
| 329 | <hr><a href="#tof">ˆ</a> |
| 330 | <a name="help">Usage: </a><a href="cmd_help.wiki">fossil help</a> COMMAND |
| 331 | Display information on how to use COMMAND |
| 332 | |
| 333 | <hr><a href="#tof">ˆ</a> |
| 334 | <a name="http">Usage: </a><a href="cmd_http.wiki">fossil http</a> REPOSITORY |
| 335 | Handle a single HTTP request appearing on stdin. The resulting webpage |
| 336 | is delivered on stdout. This method is used to launch an HTTP request |
| 337 | handler from inetd, for example. The argument is the name of the repository. |
| 338 | |
| 339 | <hr><a href="#tof">ˆ</a> |
| 340 | <a name="info">Usage: </a><a href="cmd_info.wiki">fossil info</a> ?ARTIFACT-ID|FILENAME? |
| 341 | With no arguments, provide information about the current tree. |
| 342 | If an argument is specified, provide information about the object |
| 343 | in the respository of the current tree that the argument refers |
| 344 | to. Or if the argument is the name of a repository, show |
| 345 | information about that repository. |
| 346 | |
| 347 | <hr><a href="#tof">ˆ</a> |
| 348 | <a name="leaves">Usage: </a><a href="cmd_leaves.wiki">fossil leaves</a> |
| 349 | Find leaves of all branches. |
| 350 | |
| 351 | <hr><a href="#tof">ˆ</a> |
| 352 | <a name="ls">Usage: </a><a href="cmd_ls.wiki">fossil ls</a> |
| 353 | Show the names of all files in the current checkout |
| 354 | |
| 355 | <hr><a href="#tof">ˆ</a> |
| 356 | <a name="merge">Usage: </a><a href="cmd_merge.wiki">fossil merge</a> VERSION |
| 357 | The argument is a version that should be merged into the current |
| 358 | checkout. |
| 359 | Only file content is merged. The result continues to use the |
| 360 | file and directory names from the current check-out even if those |
| 361 | names might have been changed in the branch being merged in. |
| 362 | |
| 363 | <hr><a href="#tof">ˆ</a> |
| 364 | <a name="mv">Usage: </a><a href="cmd_mv.wiki">fossil mv|rename</a> OLDNAME NEWNAME or: fossil mv|rename OLDNAME... DIR |
| 365 | |
| 366 | Move or rename one or more files within the tree |
| 367 | |
| 368 | This command does not rename the files on disk. All this command does is |
| 369 | record the fact that filenames have changed so that appropriate notations |
| 370 | can be made at the next commit/checkin. |
| 371 | |
| 372 | <hr><a href="#tof">ˆ</a> |
| 373 | <a name="new">Usage: </a><a href="cmd_new.wiki">fossil new</a> FILENAME |
| 374 | |
| 375 | Create a repository for a new project in the file named FILENAME. |
| 376 | This command is distinct from "clone". The "clone" command makes |
| 377 | a copy of an existing project. This command starts a new project. |
| 378 | |
| 379 | <hr><a href="#tof">ˆ</a> |
| 380 | <a name="open">Usage: </a><a href="cmd_open.wiki">fossil open</a> FILENAME |
| 381 | Open a connection to the local repository in FILENAME. A checkout |
| 382 | for the repository is created with its root at the working directory. |
| 383 | See also the "close" command. |
| 384 | |
| 385 | <hr><a href="#tof">ˆ</a> |
| 386 | <a name="rstats">Usage: </a><a href="cmd_rstats.wiki">fossil rstats</a> |
| 387 | |
| 388 | Deliver a report of the repository statistics for the |
| 389 | current checkout. |
| 390 | |
| 391 | <hr><a href="#tof">ˆ</a> |
| 392 | <a name="pull">Usage: </a><a href="cmd_pull.wiki">fossil pull</a> ?URL? ?-R|--respository REPOSITORY? |
| 393 | Pull changes in a remote repository into the local repository. |
| 394 | The repository is identified by the -R or --repository option. |
| 395 | If there is no such option then the open repository is used. |
| 396 | The URL of the remote server is specified on the command line |
| 397 | If no URL is specified then the URL used by the most recent |
| 398 | "pull", "push", or "sync" command is used. |
| 399 | |
| 400 | The URL is of the following form: |
| 401 | |
| 402 | http://USER@HOST:PORT/PATH |
| 403 | |
| 404 | The "USER@" and ":PORT" substrings are optional. |
| 405 | The "USER" substring specifies the login user. You will be |
| 406 | prompted for the password on the command-line. The PORT |
| 407 | specifies the TCP port of the server. The default port is |
| 408 | 80. |
| 409 | |
| 410 | <hr><a href="#tof">ˆ</a> |
| 411 | <a name="push">Usage: </a><a href="cmd_push.wiki">fossil push</a> ?URL? ?-R|--repository REPOSITORY? |
| 412 | Push changes in the local repository over into a remote repository. |
| 413 | See the "pull" command for additional information. |
| 414 | |
| 415 | <hr><a href="#tof">ˆ</a> |
| 416 | <a name="rebuild">Usage: </a><a href="cmd_rebuild.wiki">fossil rebuild</a> REPOSITORY |
| 417 | Reconstruct the named repository database from the core |
| 418 | records. Run this command after updating the fossil |
| 419 | executable in a way that changes the database schema. |
| 420 | |
| 421 | <hr><a href="#tof">ˆ</a> |
| 422 | COMMAND: reconstruct |
| 423 | <a name="reconstruct">Usage: </a><a href="cmd_reconstruct.wiki">fossil reconstruct</a> REPOSITORY ORIGIN |
| 424 | Creates the REPOSITORY and populates it with the artifacts in the |
| 425 | indicated ORIGIN directory. |
| 426 | |
| 427 | <hr><a href="#tof">ˆ</a> |
| 428 | <a name="redo">Usage: </a><a href="cmd_redo.wiki">fossil redo</a> ?FILENAME...? |
| 429 | Redo the an update or merge operation that has been undone by the |
| 430 | undo command. If FILENAME is specified then restore the changes |
| 431 | associated with the named file(s) but otherwise leave the update |
| 432 | or merge undone. |
| 433 | |
| 434 | A single level of undo/redo is supported. The undo/redo stack |
| 435 | is cleared by the commit and checkout commands. |
| 436 | |
| 437 | <hr><a href="#tof">ˆ</a> |
| 438 | <a name="revert">Usage: </a><a href="cmd_revert.wiki">fossil revert</a> ?--yes? ?-r CHECKIN? FILE |
| 439 | Revert to the current repository version of FILE, or to |
| 440 | the version associated with check-in CHECKIN if the -r flag |
| 441 | appears. This command will confirm your operation unless the |
| 442 | file is missing or the --yes option is used. |
| 443 | |
| 444 | <hr><a href="#tof">ˆ</a> |
| 445 | <a name="server">Usage: </a><a href="cmd_server.wiki">fossil server</a> ?-P|--port TCPPORT? ?REPOSITORY? Or: fossil ui ?-P|--port TCPPORT? ?REPOSITORY? |
| 446 | |
| 447 | Open a socket and begin listening and responding to HTTP requests on |
| 448 | TCP port 8080, or on any other TCP port defined by the -P or |
| 449 | --port option. The optional argument is the name of the repository. |
| 450 | The repository argument may be omitted if the working directory is |
| 451 | within an open checkout. |
| 452 | |
| 453 | The "ui" command automatically starts a web browser after initializing |
| 454 | the web server. |
| 455 | |
| 456 | <hr><a href="#tof">ˆ</a> |
| 457 | COMMAND: settings |
| 458 | COMMAND: unset |
| 459 | <a name="settings">Usage: </a><a href="cmd_setting.wiki">fossil settings</a> ?PROPERTY? ?VALUE? ?-global? |
| 460 | fossil unset PROPERTY ?-global? |
| 461 | |
| 462 | The "settings" command with no arguments lists all properties and their |
| 463 | values. With just a property name it shows the value of that property. |
| 464 | With a value argument it changes the property for the current repository. |
| 465 | |
| 466 | The "unset" command clears a property setting. |
| 467 | |
| 468 | autosync If enabled, automatically pull prior to |
| 469 | commit or update and automatically push |
| 470 | after commit or tag or branch creation. |
| 471 | |
| 472 | diff-command External command to run when performing a diff. |
| 473 | If undefined, the internal text diff will be used. |
| 474 | |
| 475 | editor Text editor command used for check-in comments. |
| 476 | |
| 477 | http-port The TCP/IP port number to use by the "server" |
| 478 | and "ui" commands. Default: 8080 |
| 479 | |
| 480 | gdiff-command External command to run when performing a graphical |
| 481 | diff. If undefined, text diff will be used. |
| 482 | |
| 483 | localauth If enabled, require that HTTP connections from |
| 484 | 127.0.0.1 be authenticated by password. If |
| 485 | false, all HTTP requests from localhost have |
| 486 | unrestricted access to the repository. |
| 487 | |
| 488 | clearsign When enabled (the default), fossil will attempt to |
| 489 | sign all commits with gpg. When disabled, commits will |
| 490 | be unsigned. |
| 491 | |
| 492 | pgp-command Command used to clear-sign manifests at check-in. |
| 493 | The default is "gpg --clearsign -o ". |
| 494 | |
| 495 | mtime-changes Use file modification times (mtimes) to detect when |
| 496 | files have been modified. |
| 497 | |
| 498 | proxy URL of the HTTP proxy. If undefined or "on" then |
| 499 | the "http_proxy" environment variable is consulted. |
| 500 | If the http_proxy environment variable is undefined |
| 501 | then a direct HTTP connection is used. |
| 502 | |
| 503 | web-browser A shell command used to launch your preferred |
| 504 | web browser when given a URL as an argument. |
| 505 | Defaults to "start" on windows, "open" on Mac, |
| 506 | and "firefox" on Unix. |
| 507 | |
| 508 | <hr><a href="#tof">ˆ</a> |
| 509 | <a name="status">Usage: </a><a href="cmd_status.wiki">fossil status</a> |
| 510 | Report on the status of the current checkout. |
| 511 | |
| 512 | <hr><a href="#tof">ˆ</a> |
| 513 | <a name="sync">Usage: </a><a href="cmd_sync.wiki">fossil sync</a> ?URL? ?-R|--repository REPOSITORY? |
| 514 | Synchronize the local repository with a remote repository. This is |
| 515 | the equivalent of running both "push" and "pull" at the same time. |
| 516 | See the "pull" command for additional information. |
| 517 | |
| 518 | <hr><a href="#tof">ˆ</a> |
| 519 | <a name="tag">Usage: </a><a href="cmd_tag.wiki">fossil tag</a> SUBCOMMAND ... |
| 520 | Run various subcommands to control tags and properties |
| 521 | |
| 522 | fossil tag add ?--raw? TAGNAME CHECK-IN ?VALUE? |
| 523 | |
| 524 | Add a new tag or property to CHECK-IN. The tag will |
| 525 | be usable instead of a CHECK-IN in commands such as |
| 526 | update and merge. |
| 527 | |
| 528 | fossil tag branch ?--raw? ?--nofork? TAGNAME CHECK-IN ?VALUE? |
| 529 | |
| 530 | A fork will be created so that the new checkin |
| 531 | is a sibling of CHECK-IN and identical to it except |
| 532 | for a generated comment. Then the new tag will |
| 533 | be added to the new checkin and propagated to |
| 534 | all direct children. Additionally all symbolic |
| 535 | tags of that checkin inherited from CHECK-IN will |
| 536 | be cancelled. |
| 537 | |
| 538 | However, if the option --nofork is given, no |
| 539 | fork will be created and the tag/property will be |
| 540 | added to CHECK-IN directly. No tags will be canceled. |
| 541 | |
| 542 | fossil tag cancel ?--raw? TAGNAME CHECK-IN |
| 543 | |
| 544 | Remove the tag TAGNAME from CHECK-IN, and also remove |
| 545 | the propagation of the tag to any descendants. |
| 546 | |
| 547 | fossil tag find ?--raw? TAGNAME |
| 548 | |
| 549 | List all check-ins that use TAGNAME |
| 550 | |
| 551 | fossil tag list ?--raw? ?CHECK-IN? |
| 552 | |
| 553 | List all tags, or if CHECK-IN is supplied, list |
| 554 | all tags and their values for CHECK-IN. |
| 555 | |
| 556 | The option --raw allows the manipulation of all types of |
| 557 | tags used for various internal purposes in fossil. You |
| 558 | should not use this option to make changes unless you are |
| 559 | sure what you are doing. |
| 560 | |
| 561 | If you need to use a tagname that might be confused with |
| 562 | a hexadecimal check-in or artifact ID, you can explicitly |
| 563 | disambiguate it by prefixing it with "tag:". For instance: |
| 564 | |
| 565 | fossil update decaf |
| 566 | |
| 567 | will be taken as an artifact or check-in ID and fossil will |
| 568 | probably complain that no such revision was found. However |
| 569 | |
| 570 | fossil update tag:decaf |
| 571 | |
| 572 | will assume that "decaf" is a tag/branch name. |
| 573 | |
| 574 | <hr><a href="#tof">ˆ</a> |
| 575 | <a name="timeline">Usage: </a><a href="cmd_timeline.wiki">fossil timeline</a> ?WHEN? ?CHECK-IN|DATETIME? ?-n|--count N? |
| 576 | Print a summary of activity going backwards in date and time |
| 577 | specified or from the current date and time if no arguments |
| 578 | are given. Show as many as N (default 20) check-ins. The |
| 579 | WHEN argument can be any unique abbreviation of one of these |
| 580 | keywords: |
| 581 | |
| 582 | before |
| 583 | after |
| 584 | descendants | children |
| 585 | ancestors | parents |
| 586 | |
| 587 | The CHECK-IN can be any unique prefix of 4 characters or more. |
| 588 | The DATETIME should be in the ISO8601 format. For |
| 589 | examples: "2007-08-18 07:21:21". You can also say "current" |
| 590 | for the current version or "now" for the current time. |
| 591 | |
| 592 | <hr><a href="#tof">ˆ</a> |
| 593 | <a name="undo">Usage: </a><a href="cmd_undo.wiki">fossil undo</a> ?FILENAME...? |
| 594 | Undo the most recent update or merge operation. If FILENAME is |
| 595 | specified then restore the content of the named file(s) but otherwise |
| 596 | leave the update or merge in effect. |
| 597 | |
| 598 | A single level of undo/redo is supported. The undo/redo stack |
| 599 | is cleared by the commit and checkout commands. |
| 600 | |
| 601 | <hr><a href="#tof">ˆ</a> |
| 602 | <a name="update">Usage: </a><a href="cmd_update.wiki">fossil update</a> ?VERSION? ?--latest? |
| 603 | The optional argument is a version that should become the current |
| 604 | version. If the argument is omitted, then use the leaf of the |
| 605 | tree that begins with the current version, if there is only a single leaf. If there are a multiple leaves, the latest is used |
| 606 | if the --latest flag is present. |
| 607 | |
| 608 | This command is different from the "checkout" in that edits are |
| 609 | not overwritten. Edits are merged into the new version. |
| 610 | |
| 611 | <hr><a href="#tof">ˆ</a> |
| 612 | <a name="user">Usage: </a><a href="cmd_user.wiki">fossil user</a> SUBCOMMAND ... ?-R|--repository FILE? |
| 613 | Run various subcommands on users of the open repository or of |
| 614 | the repository identified by the -R or --repository option. |
| 615 | |
| 616 | fossil user capabilities USERNAME ?STRING? |
| 617 | |
| 618 | Query or set the capabilities for user USERNAME |
| 619 | |
| 620 | fossil user default ?USERNAME? |
| 621 | |
| 622 | Query or set the default user. The default user is the |
| 623 | user for command-line interaction. |
| 624 | |
| 625 | fossil user list |
| 626 | |
| 627 | List all users known to the repository |
| 628 | |
| 629 | fossil user new ?USERNAME? |
| 630 | |
| 631 | Create a new user in the repository. Users can never be |
| 632 | deleted. They can be denied all access but they must continue |
| 633 | to exist in the database. |
| 634 | |
| 635 | fossil user password USERNAME |
| 636 | |
| 637 | Change the web access password for a user. |
| 638 | |
| 639 | <hr><a href="#tof">ˆ</a> |
| 640 | <a name="version">Usage: </a><a href="cmd_version.wiki">fossil version</a> |
| 641 | Print the source code version number for the fossil executable. |
| 642 | |
| 643 | <hr><a href="#tof">ˆ</a> |
| 644 | <a name="wiki">Usage: </a><a href="cmd_wiki.wiki">fossil wiki</a> (export|create|commit|list) WikiName |
| 645 | Run various subcommands to fetch wiki entries. |
| 646 | |
| 647 | fossil wiki export PAGENAME ?FILE? |
| 648 | |
| 649 | Sends the latest version of the PAGENAME wiki |
| 650 | entry to the given file or standard output. |
| 651 | |
| 652 | fossil wiki commit PAGENAME ?FILE? |
| 653 | |
| 654 | Commit changes to a wiki page from FILE or from standard. |
| 655 | |
| 656 | fossil wiki create PAGENAME ?FILE? |
| 657 | |
| 658 | Create a new wiki page with initial content taken from |
| 659 | FILE or from standard input. |
| 660 | |
| 661 | fossil wiki list |
| 662 | |
| 663 | Lists all wiki entries, one per line, ordered |
| 664 | case-insentively by name. |
| 665 | |
| 666 | TODOs: |
| 667 | |
| 668 | fossil wiki export ?-u ARTIFACT? WikiName ?FILE? |
| 669 | |
| 670 | Outputs the selected version of WikiName. |
| 671 | |
| 672 | fossil wiki delete ?-m MESSAGE? WikiName |
| 673 | |
| 674 | The same as deleting a file entry, but i don't know if fossil |
| 675 | supports a commit message for Wiki entries. |
| 676 | |
| 677 | fossil wiki ?-u? ?-d? ?-s=[|]? list |
| 678 | |
| 679 | Lists the artifact ID and/or Date of last change along with |
| 680 | each entry name, delimited by the -s char. |
| 681 | |
| 682 | fossil wiki diff ?ARTIFACT? ?-f infile[=stdin]? EntryName |
| 683 | |
| 684 | Diffs the local copy of a page with a given version (defaulting |
| 685 | to the head version). |
| 686 | |
| 687 | </pre></nowiki> |
| 688 | |
| 689 | <hr><a href="#tof">ˆ</a> |
| 690 | |
| 691 | <h3>Caveats</h3> |
| 692 | This is not actually a reference, it's the start of a reference. |
| 693 | There are wikilinks to uncreated pages for the commands. This was |
| 694 | created by running the fossil help for each command listed by running |
| 695 | fossil help... Duplicate commands are only listed once (I |
| 696 | <i>think</i>). There are several bits of <b>fossil</b> that are not addressed |
| 697 | in the help for commands (special wiki directories, special users, etc.) |
| 698 | so they are (currently) not addressed here. Clarity and brevity may be |
| 699 | sacrificed for expediency at the authors indiscretion. All spelling and |
| 700 | grammatical mistakes are somebody elses fault.<code> void * </code> |
| 701 | prohibited where<code> __C_PLUS_PLUS__ </code>. Title and taxes extra. |
| 702 | Not valid in Hooptigonia. |
| --- a/www/reference.wiki | |
| +++ b/www/reference.wiki | |
| @@ -1,702 +0,0 @@ | |