Fossil SCM
Updates to the "concepts" document.
Commit
9177ad87ba902e3767b2c6af698746abe323fc1d
Parent
e6cada82199eb79…
1 file changed
+11
-2
+11
-2
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -46,11 +46,12 @@ | ||
| 46 | 46 | tree per repository is the most common configuration.) So a |
| 47 | 47 | single repository can be associated with many source trees, but |
| 48 | 48 | each source tree is associated with only one repository. |
| 49 | 49 | |
| 50 | 50 | Fossil source trees may not overlap. A fossil source tree is identified |
| 51 | -by a file named "_FOSSIL_" in the root directory of the source tree. Every | |
| 51 | +by a file named "_FOSSIL_" (or ".fslckout", but this article will always | |
| 52 | +use the name "_FOSSIL_") in the root directory of the source tree. Every | |
| 52 | 53 | file that is a sibling of _FOSSIL_ and every file in every subfolder is |
| 53 | 54 | considered potentially a part of the source tree. The _FOSSIL_ file |
| 54 | 55 | contains (among other things) the pathname of the repository with which |
| 55 | 56 | the source tree is associated. On the other hand, the repository has |
| 56 | 57 | no record of its source trees. So you are free to delete a source tree |
| @@ -122,19 +123,27 @@ | ||
| 122 | 123 | artifacts and reconstruct the complete development history of |
| 123 | 124 | a software project. |
| 124 | 125 | |
| 125 | 126 | <h3>2.2 Manifests</h3> |
| 126 | 127 | |
| 127 | -At the root of a source tree is a special file called the | |
| 128 | +Associated with every check-in is a special file called the | |
| 128 | 129 | "manifest". The manifest is a listing of all other files in |
| 129 | 130 | that source tree. The manifest contains the (complete) artifact ID |
| 130 | 131 | of the file and the name of the file as it appears on disk, |
| 131 | 132 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 132 | 133 | of the manifest is the identifier for the entire check-in. When |
| 133 | 134 | you look at a "timeline" of changes in fossil, the ID associated |
| 134 | 135 | with each check-in or commit is really just the artifact ID of the |
| 135 | 136 | manifest for that check-in. |
| 137 | + | |
| 138 | +<p>The manifest file is not normally a real file on disk. Instead, | |
| 139 | +the manifest is computed in memory by Fossil whenever it needs it. | |
| 140 | +However, the "fossil setting manifest on" command will cause the | |
| 141 | +manifest file to be materialized to disk, if desired. Both Fossil | |
| 142 | +itself, and SQLite cause the manifest file to be materialized to disk | |
| 143 | +so that the makefiles for these project can read the manifest and | |
| 144 | +embed version information in generated binaries. | |
| 136 | 145 | |
| 137 | 146 | <p>Fossil automatically generates a manifest whenever you "commit" |
| 138 | 147 | a new check-in. So this is not something that you, the developer, |
| 139 | 148 | need to worry with. The format of a manifest is intentionally |
| 140 | 149 | designed to be simple to parse, so that if |
| 141 | 150 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -46,11 +46,12 @@ | |
| 46 | tree per repository is the most common configuration.) So a |
| 47 | single repository can be associated with many source trees, but |
| 48 | each source tree is associated with only one repository. |
| 49 | |
| 50 | Fossil source trees may not overlap. A fossil source tree is identified |
| 51 | by a file named "_FOSSIL_" in the root directory of the source tree. Every |
| 52 | file that is a sibling of _FOSSIL_ and every file in every subfolder is |
| 53 | considered potentially a part of the source tree. The _FOSSIL_ file |
| 54 | contains (among other things) the pathname of the repository with which |
| 55 | the source tree is associated. On the other hand, the repository has |
| 56 | no record of its source trees. So you are free to delete a source tree |
| @@ -122,19 +123,27 @@ | |
| 122 | artifacts and reconstruct the complete development history of |
| 123 | a software project. |
| 124 | |
| 125 | <h3>2.2 Manifests</h3> |
| 126 | |
| 127 | At the root of a source tree is a special file called the |
| 128 | "manifest". The manifest is a listing of all other files in |
| 129 | that source tree. The manifest contains the (complete) artifact ID |
| 130 | of the file and the name of the file as it appears on disk, |
| 131 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 132 | of the manifest is the identifier for the entire check-in. When |
| 133 | you look at a "timeline" of changes in fossil, the ID associated |
| 134 | with each check-in or commit is really just the artifact ID of the |
| 135 | manifest for that check-in. |
| 136 | |
| 137 | <p>Fossil automatically generates a manifest whenever you "commit" |
| 138 | a new check-in. So this is not something that you, the developer, |
| 139 | need to worry with. The format of a manifest is intentionally |
| 140 | designed to be simple to parse, so that if |
| 141 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -46,11 +46,12 @@ | |
| 46 | tree per repository is the most common configuration.) So a |
| 47 | single repository can be associated with many source trees, but |
| 48 | each source tree is associated with only one repository. |
| 49 | |
| 50 | Fossil source trees may not overlap. A fossil source tree is identified |
| 51 | by a file named "_FOSSIL_" (or ".fslckout", but this article will always |
| 52 | use the name "_FOSSIL_") in the root directory of the source tree. Every |
| 53 | file that is a sibling of _FOSSIL_ and every file in every subfolder is |
| 54 | considered potentially a part of the source tree. The _FOSSIL_ file |
| 55 | contains (among other things) the pathname of the repository with which |
| 56 | the source tree is associated. On the other hand, the repository has |
| 57 | no record of its source trees. So you are free to delete a source tree |
| @@ -122,19 +123,27 @@ | |
| 123 | artifacts and reconstruct the complete development history of |
| 124 | a software project. |
| 125 | |
| 126 | <h3>2.2 Manifests</h3> |
| 127 | |
| 128 | Associated with every check-in is a special file called the |
| 129 | "manifest". The manifest is a listing of all other files in |
| 130 | that source tree. The manifest contains the (complete) artifact ID |
| 131 | of the file and the name of the file as it appears on disk, |
| 132 | and thus serves as a mapping from artifact ID to disk name. The artifact ID |
| 133 | of the manifest is the identifier for the entire check-in. When |
| 134 | you look at a "timeline" of changes in fossil, the ID associated |
| 135 | with each check-in or commit is really just the artifact ID of the |
| 136 | manifest for that check-in. |
| 137 | |
| 138 | <p>The manifest file is not normally a real file on disk. Instead, |
| 139 | the manifest is computed in memory by Fossil whenever it needs it. |
| 140 | However, the "fossil setting manifest on" command will cause the |
| 141 | manifest file to be materialized to disk, if desired. Both Fossil |
| 142 | itself, and SQLite cause the manifest file to be materialized to disk |
| 143 | so that the makefiles for these project can read the manifest and |
| 144 | embed version information in generated binaries. |
| 145 | |
| 146 | <p>Fossil automatically generates a manifest whenever you "commit" |
| 147 | a new check-in. So this is not something that you, the developer, |
| 148 | need to worry with. The format of a manifest is intentionally |
| 149 | designed to be simple to parse, so that if |
| 150 |