Fossil SCM
Update homepage with links to competing projects.
Commit
852dbbb65d0d9f4cc7634dfe28e288396eb80ec5
Parent
1ce0ac53ef7c7e1…
3 files changed
+1
-1
+14
-1
+21
-20
+1
-1
| --- www/fileformat.html | ||
| +++ www/fileformat.html | ||
| @@ -9,11 +9,11 @@ | ||
| 9 | 9 | Fossil File Formats |
| 10 | 10 | </h1> |
| 11 | 11 | |
| 12 | 12 | <p> |
| 13 | 13 | The global state of a fossil repository is determined by an unordered |
| 14 | -set of files. A file in fossil is called an "artifact". | |
| 14 | +set of artifacts. | |
| 15 | 15 | An artifact might be a source code file, the text of a wiki page, |
| 16 | 16 | part of a trouble ticket, or one of several special control artifacts |
| 17 | 17 | used to show the relationships between other artifacts within the |
| 18 | 18 | project. Artifacts can be text or binary. |
| 19 | 19 | </p> |
| 20 | 20 |
| --- www/fileformat.html | |
| +++ www/fileformat.html | |
| @@ -9,11 +9,11 @@ | |
| 9 | Fossil File Formats |
| 10 | </h1> |
| 11 | |
| 12 | <p> |
| 13 | The global state of a fossil repository is determined by an unordered |
| 14 | set of files. A file in fossil is called an "artifact". |
| 15 | An artifact might be a source code file, the text of a wiki page, |
| 16 | part of a trouble ticket, or one of several special control artifacts |
| 17 | used to show the relationships between other artifacts within the |
| 18 | project. Artifacts can be text or binary. |
| 19 | </p> |
| 20 |
| --- www/fileformat.html | |
| +++ www/fileformat.html | |
| @@ -9,11 +9,11 @@ | |
| 9 | Fossil File Formats |
| 10 | </h1> |
| 11 | |
| 12 | <p> |
| 13 | The global state of a fossil repository is determined by an unordered |
| 14 | set of artifacts. |
| 15 | An artifact might be a source code file, the text of a wiki page, |
| 16 | part of a trouble ticket, or one of several special control artifacts |
| 17 | used to show the relationships between other artifacts within the |
| 18 | project. Artifacts can be text or binary. |
| 19 | </p> |
| 20 |
+14
-1
| --- www/index.html | ||
| +++ www/index.html | ||
| @@ -18,11 +18,11 @@ | ||
| 18 | 18 | <p>Design Goals For Fossil:</p> |
| 19 | 19 | |
| 20 | 20 | <ul> |
| 21 | 21 | <li>Supports disconnected, distributed development (like |
| 22 | 22 | <a href="http://kerneltrap.org/node/4982">git</a>, |
| 23 | -<a href="http://www.venge.net/monotone/">monotone</a>, | |
| 23 | +<a href="http://www.monotone.ca/">monotone</a>, | |
| 24 | 24 | <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or |
| 25 | 25 | <a href="http://www.bitkeeper.com/">bitkeeper</a>) |
| 26 | 26 | or client/server operation (like |
| 27 | 27 | <a href="http://www.nongnu.org/cvs/">CVS</a> or |
| 28 | 28 | <a href="http://subversion.tigris.org/">subversion</a>) |
| @@ -96,8 +96,21 @@ | ||
| 96 | 96 | <li>There is a <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> |
| 97 | 97 | mailing list</a> available for discussing fossil issues.</li> |
| 98 | 98 | <li>The <a href="http://www.fossil-scm.org/fossil/wiki">self-hosting |
| 99 | 99 | fossil wiki</a>. |
| 100 | 100 | </ul> |
| 101 | + | |
| 102 | +<p>Competing Projects:</p> | |
| 103 | + | |
| 104 | +<ul> | |
| 105 | +<li><a href="http://www.ditrack.org/">DITrace</a> | |
| 106 | + - A Distributed Issue Tracker</li> | |
| 107 | +<li><a href="http://www.distract.wellquite.org/">DisTract</a> | |
| 108 | + - Another distributed issue tracker based on | |
| 109 | + <a href="http://www.monotone.ca/">monotone</a>. | |
| 110 | +<li><a href="http://www.monotone.ca/">Monotone</a> - distributed | |
| 111 | + SCM in a single-file executable with a single-file SQLite | |
| 112 | + database repository.</li> | |
| 113 | +</ul> | |
| 101 | 114 | |
| 102 | 115 | </body> |
| 103 | 116 | </html> |
| 104 | 117 |
| --- www/index.html | |
| +++ www/index.html | |
| @@ -18,11 +18,11 @@ | |
| 18 | <p>Design Goals For Fossil:</p> |
| 19 | |
| 20 | <ul> |
| 21 | <li>Supports disconnected, distributed development (like |
| 22 | <a href="http://kerneltrap.org/node/4982">git</a>, |
| 23 | <a href="http://www.venge.net/monotone/">monotone</a>, |
| 24 | <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or |
| 25 | <a href="http://www.bitkeeper.com/">bitkeeper</a>) |
| 26 | or client/server operation (like |
| 27 | <a href="http://www.nongnu.org/cvs/">CVS</a> or |
| 28 | <a href="http://subversion.tigris.org/">subversion</a>) |
| @@ -96,8 +96,21 @@ | |
| 96 | <li>There is a <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> |
| 97 | mailing list</a> available for discussing fossil issues.</li> |
| 98 | <li>The <a href="http://www.fossil-scm.org/fossil/wiki">self-hosting |
| 99 | fossil wiki</a>. |
| 100 | </ul> |
| 101 | |
| 102 | </body> |
| 103 | </html> |
| 104 |
| --- www/index.html | |
| +++ www/index.html | |
| @@ -18,11 +18,11 @@ | |
| 18 | <p>Design Goals For Fossil:</p> |
| 19 | |
| 20 | <ul> |
| 21 | <li>Supports disconnected, distributed development (like |
| 22 | <a href="http://kerneltrap.org/node/4982">git</a>, |
| 23 | <a href="http://www.monotone.ca/">monotone</a>, |
| 24 | <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or |
| 25 | <a href="http://www.bitkeeper.com/">bitkeeper</a>) |
| 26 | or client/server operation (like |
| 27 | <a href="http://www.nongnu.org/cvs/">CVS</a> or |
| 28 | <a href="http://subversion.tigris.org/">subversion</a>) |
| @@ -96,8 +96,21 @@ | |
| 96 | <li>There is a <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> |
| 97 | mailing list</a> available for discussing fossil issues.</li> |
| 98 | <li>The <a href="http://www.fossil-scm.org/fossil/wiki">self-hosting |
| 99 | fossil wiki</a>. |
| 100 | </ul> |
| 101 | |
| 102 | <p>Competing Projects:</p> |
| 103 | |
| 104 | <ul> |
| 105 | <li><a href="http://www.ditrack.org/">DITrace</a> |
| 106 | - A Distributed Issue Tracker</li> |
| 107 | <li><a href="http://www.distract.wellquite.org/">DisTract</a> |
| 108 | - Another distributed issue tracker based on |
| 109 | <a href="http://www.monotone.ca/">monotone</a>. |
| 110 | <li><a href="http://www.monotone.ca/">Monotone</a> - distributed |
| 111 | SCM in a single-file executable with a single-file SQLite |
| 112 | database repository.</li> |
| 113 | </ul> |
| 114 | |
| 115 | </body> |
| 116 | </html> |
| 117 |
+21
-20
| --- www/pop.html | ||
| +++ www/pop.html | ||
| @@ -12,12 +12,13 @@ | ||
| 12 | 12 | which Fossil is built. |
| 13 | 13 | </p> |
| 14 | 14 | |
| 15 | 15 | <ul> |
| 16 | 16 | <li><p>A project consists of source files, wiki pages, and |
| 17 | -trouble tickets. All historical copies of all these | |
| 18 | -entities are saved. The project maintains an audit | |
| 17 | +trouble tickets, and control files (collectively "artifacts"). | |
| 18 | +All historical copies of all artifacts | |
| 19 | +are saved. The project maintains an audit | |
| 19 | 20 | trail.</p></li> |
| 20 | 21 | |
| 21 | 22 | <li><p>A project resides in one or more repositories. Each |
| 22 | 23 | repository is administered and operates independently |
| 23 | 24 | of the others.</p></li> |
| @@ -30,49 +31,49 @@ | ||
| 30 | 31 | The global state represents the content of the project. |
| 31 | 32 | The local state identifies the authorized users and |
| 32 | 33 | access policies for a particular repository.</p></li> |
| 33 | 34 | |
| 34 | 35 | <li><p>The global state of a repository is an unordered |
| 35 | -collection of files. Each file is named by | |
| 36 | -its SHA1 hash encoded in hexadecimal. | |
| 36 | +collection of artifacts. Each artifact is named by | |
| 37 | +its SHA1 hash encoded in lowercase hexadecimal. | |
| 37 | 38 | In many contexts, the name can be |
| 38 | 39 | abbreviated to a unique prefix. A five- or six-character |
| 39 | 40 | prefix usually suffices to uniquely identify a file.</p></li> |
| 40 | 41 | |
| 41 | -<li><p>Because files are named by their SHA1 hash, all files | |
| 42 | -are immutable. Any change to the content of a file also | |
| 43 | -changes the hash that forms the files name, thus | |
| 44 | -creating a new file. Both the old original version of the | |
| 45 | -file and the new change are preserved under different names.</p></li> | |
| 42 | +<li><p>Because artifacts are named by their SHA1 hash, all artifacts | |
| 43 | +are immutable. Any change to the content of a artifact also | |
| 44 | +changes the hash that forms the artifacts name, thus | |
| 45 | +creating a new artifact. Both the old original version of the | |
| 46 | +artifact and the new change are preserved under different names.</p></li> | |
| 46 | 47 | |
| 47 | -<li><p>It is theoretically possible for two files with different | |
| 48 | +<li><p>It is theoretically possible for two artifacts with different | |
| 48 | 49 | content to share the same hash. But finding two such |
| 49 | -files is so incredibly difficult and unlikely that we | |
| 50 | +artifacts is so incredibly difficult and unlikely that we | |
| 50 | 51 | consider it to be an impossibility.</p></li> |
| 51 | 52 | |
| 52 | -<li><p>The signature of a file is the SHA1 hash of the | |
| 53 | -file itself, exactly as it appears on disk. No prefix | |
| 54 | -or meta-information about the file is added before computing | |
| 53 | +<li><p>The signature of an artifact is the SHA1 hash of the | |
| 54 | +artifact itself, exactly as it would appear in a disk file. No prefix | |
| 55 | +or meta-information about the artifact is added before computing | |
| 55 | 56 | the hash. So you can |
| 56 | 57 | always find the SHA1 signature of a file by using the |
| 57 | 58 | "sha1sum" command-line utility.</p></li> |
| 58 | 59 | |
| 59 | -<li><p>The files that comprise the global state of a repository | |
| 60 | +<li><p>The artifacts that comprise the global state of a repository | |
| 60 | 61 | are the complete global state of that repository. The SQLite |
| 61 | 62 | database that holds the repository contains additional information |
| 62 | -about linkages between files, but all of that added information | |
| 63 | +about linkages between artifacts, but all of that added information | |
| 63 | 64 | can be discarded and reconstructed by rescanning the content |
| 64 | -files.</p></li> | |
| 65 | +artifacts.</p></li> | |
| 65 | 66 | |
| 66 | 67 | <li><p>Two repositories for the same project can synchronize |
| 67 | -their global states simply by sharing files. The local | |
| 68 | +their global states simply by sharing artifacts. The local | |
| 68 | 69 | state of repositories is not normally synchronized or |
| 69 | 70 | shared.</p></li> |
| 70 | 71 | |
| 71 | -<li><p>Every repository has a special file at the top-level | |
| 72 | +<li><p>Every baseline has a special file at the top-level | |
| 72 | 73 | named "manifest" which is an index of all other files in |
| 73 | -the system. The manifest is automatically created and | |
| 74 | +that baseline. The manifest is automatically created and | |
| 74 | 75 | maintained by the system.</p></li> |
| 75 | 76 | |
| 76 | 77 | <li><p>The <a href="fileformat.html">file formats</a> |
| 77 | 78 | used by Fossil are all very simple so that with access |
| 78 | 79 | to the original content files, one can easily reconstruct |
| 79 | 80 |
| --- www/pop.html | |
| +++ www/pop.html | |
| @@ -12,12 +12,13 @@ | |
| 12 | which Fossil is built. |
| 13 | </p> |
| 14 | |
| 15 | <ul> |
| 16 | <li><p>A project consists of source files, wiki pages, and |
| 17 | trouble tickets. All historical copies of all these |
| 18 | entities are saved. The project maintains an audit |
| 19 | trail.</p></li> |
| 20 | |
| 21 | <li><p>A project resides in one or more repositories. Each |
| 22 | repository is administered and operates independently |
| 23 | of the others.</p></li> |
| @@ -30,49 +31,49 @@ | |
| 30 | The global state represents the content of the project. |
| 31 | The local state identifies the authorized users and |
| 32 | access policies for a particular repository.</p></li> |
| 33 | |
| 34 | <li><p>The global state of a repository is an unordered |
| 35 | collection of files. Each file is named by |
| 36 | its SHA1 hash encoded in hexadecimal. |
| 37 | In many contexts, the name can be |
| 38 | abbreviated to a unique prefix. A five- or six-character |
| 39 | prefix usually suffices to uniquely identify a file.</p></li> |
| 40 | |
| 41 | <li><p>Because files are named by their SHA1 hash, all files |
| 42 | are immutable. Any change to the content of a file also |
| 43 | changes the hash that forms the files name, thus |
| 44 | creating a new file. Both the old original version of the |
| 45 | file and the new change are preserved under different names.</p></li> |
| 46 | |
| 47 | <li><p>It is theoretically possible for two files with different |
| 48 | content to share the same hash. But finding two such |
| 49 | files is so incredibly difficult and unlikely that we |
| 50 | consider it to be an impossibility.</p></li> |
| 51 | |
| 52 | <li><p>The signature of a file is the SHA1 hash of the |
| 53 | file itself, exactly as it appears on disk. No prefix |
| 54 | or meta-information about the file is added before computing |
| 55 | the hash. So you can |
| 56 | always find the SHA1 signature of a file by using the |
| 57 | "sha1sum" command-line utility.</p></li> |
| 58 | |
| 59 | <li><p>The files that comprise the global state of a repository |
| 60 | are the complete global state of that repository. The SQLite |
| 61 | database that holds the repository contains additional information |
| 62 | about linkages between files, but all of that added information |
| 63 | can be discarded and reconstructed by rescanning the content |
| 64 | files.</p></li> |
| 65 | |
| 66 | <li><p>Two repositories for the same project can synchronize |
| 67 | their global states simply by sharing files. The local |
| 68 | state of repositories is not normally synchronized or |
| 69 | shared.</p></li> |
| 70 | |
| 71 | <li><p>Every repository has a special file at the top-level |
| 72 | named "manifest" which is an index of all other files in |
| 73 | the system. The manifest is automatically created and |
| 74 | maintained by the system.</p></li> |
| 75 | |
| 76 | <li><p>The <a href="fileformat.html">file formats</a> |
| 77 | used by Fossil are all very simple so that with access |
| 78 | to the original content files, one can easily reconstruct |
| 79 |
| --- www/pop.html | |
| +++ www/pop.html | |
| @@ -12,12 +12,13 @@ | |
| 12 | which Fossil is built. |
| 13 | </p> |
| 14 | |
| 15 | <ul> |
| 16 | <li><p>A project consists of source files, wiki pages, and |
| 17 | trouble tickets, and control files (collectively "artifacts"). |
| 18 | All historical copies of all artifacts |
| 19 | are saved. The project maintains an audit |
| 20 | trail.</p></li> |
| 21 | |
| 22 | <li><p>A project resides in one or more repositories. Each |
| 23 | repository is administered and operates independently |
| 24 | of the others.</p></li> |
| @@ -30,49 +31,49 @@ | |
| 31 | The global state represents the content of the project. |
| 32 | The local state identifies the authorized users and |
| 33 | access policies for a particular repository.</p></li> |
| 34 | |
| 35 | <li><p>The global state of a repository is an unordered |
| 36 | collection of artifacts. Each artifact is named by |
| 37 | its SHA1 hash encoded in lowercase hexadecimal. |
| 38 | In many contexts, the name can be |
| 39 | abbreviated to a unique prefix. A five- or six-character |
| 40 | prefix usually suffices to uniquely identify a file.</p></li> |
| 41 | |
| 42 | <li><p>Because artifacts are named by their SHA1 hash, all artifacts |
| 43 | are immutable. Any change to the content of a artifact also |
| 44 | changes the hash that forms the artifacts name, thus |
| 45 | creating a new artifact. Both the old original version of the |
| 46 | artifact and the new change are preserved under different names.</p></li> |
| 47 | |
| 48 | <li><p>It is theoretically possible for two artifacts with different |
| 49 | content to share the same hash. But finding two such |
| 50 | artifacts is so incredibly difficult and unlikely that we |
| 51 | consider it to be an impossibility.</p></li> |
| 52 | |
| 53 | <li><p>The signature of an artifact is the SHA1 hash of the |
| 54 | artifact itself, exactly as it would appear in a disk file. No prefix |
| 55 | or meta-information about the artifact is added before computing |
| 56 | the hash. So you can |
| 57 | always find the SHA1 signature of a file by using the |
| 58 | "sha1sum" command-line utility.</p></li> |
| 59 | |
| 60 | <li><p>The artifacts that comprise the global state of a repository |
| 61 | are the complete global state of that repository. The SQLite |
| 62 | database that holds the repository contains additional information |
| 63 | about linkages between artifacts, but all of that added information |
| 64 | can be discarded and reconstructed by rescanning the content |
| 65 | artifacts.</p></li> |
| 66 | |
| 67 | <li><p>Two repositories for the same project can synchronize |
| 68 | their global states simply by sharing artifacts. The local |
| 69 | state of repositories is not normally synchronized or |
| 70 | shared.</p></li> |
| 71 | |
| 72 | <li><p>Every baseline has a special file at the top-level |
| 73 | named "manifest" which is an index of all other files in |
| 74 | that baseline. The manifest is automatically created and |
| 75 | maintained by the system.</p></li> |
| 76 | |
| 77 | <li><p>The <a href="fileformat.html">file formats</a> |
| 78 | used by Fossil are all very simple so that with access |
| 79 | to the original content files, one can easily reconstruct |
| 80 |