Overview
SHA1 Hash: | 852dbbb65d0d9f4cc7634dfe28e288396eb80ec5 |
---|---|
Date: | 2008-02-13 12:39:19 |
User: | drh |
Comment: | Update homepage with links to competing projects. |
Timelines: | ancestors | descendants | both | trunk |
Other Links: | files | ZIP archive | manifest |
Tags And Properties
- branch=trunk inherited from [a28c83647d]
- sym-trunk inherited from [a28c83647d]
Changes
[hide diffs]Modified www/fileformat.html from [66d0102569] to [40a53b49c4].
@@ -9,11 +9,11 @@ Fossil File Formats </h1> <p> The global state of a fossil repository is determined by an unordered -set of files. A file in fossil is called an "artifact". +set of artifacts. An artifact might be a source code file, the text of a wiki page, part of a trouble ticket, or one of several special control artifacts used to show the relationships between other artifacts within the project. Artifacts can be text or binary. </p>
Modified www/index.html from [834da7be86] to [0f4c91fa34].
@@ -18,11 +18,11 @@ <p>Design Goals For Fossil:</p> <ul> <li>Supports disconnected, distributed development (like <a href="http://kerneltrap.org/node/4982">git</a>, -<a href="http://www.venge.net/monotone/">monotone</a>, +<a href="http://www.monotone.ca/">monotone</a>, <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or <a href="http://www.bitkeeper.com/">bitkeeper</a>) or client/server operation (like <a href="http://www.nongnu.org/cvs/">CVS</a> or <a href="http://subversion.tigris.org/">subversion</a>) @@ -95,9 +95,22 @@ <li>The <a href="sync.html">synchronization protocol</a>. <li>There is a <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users"> mailing list</a> available for discussing fossil issues.</li> <li>The <a href="http://www.fossil-scm.org/fossil/wiki">self-hosting fossil wiki</a>. +</ul> + +<p>Competing Projects:</p> + +<ul> +<li><a href="http://www.ditrack.org/">DITrace</a> + - A Distributed Issue Tracker</li> +<li><a href="http://www.distract.wellquite.org/">DisTract</a> + - Another distributed issue tracker based on + <a href="http://www.monotone.ca/">monotone</a>. +<li><a href="http://www.monotone.ca/">Monotone</a> - distributed + SCM in a single-file executable with a single-file SQLite + database repository.</li> </ul> </body> </html>
Modified www/pop.html from [be259767d3] to [f5f93db90a].
@@ -12,12 +12,13 @@ which Fossil is built. </p> <ul> <li><p>A project consists of source files, wiki pages, and -trouble tickets. All historical copies of all these -entities are saved. The project maintains an audit +trouble tickets, and control files (collectively "artifacts"). +All historical copies of all artifacts +are saved. The project maintains an audit trail.</p></li> <li><p>A project resides in one or more repositories. Each repository is administered and operates independently of the others.</p></li> @@ -30,49 +31,49 @@ The global state represents the content of the project. The local state identifies the authorized users and access policies for a particular repository.</p></li> <li><p>The global state of a repository is an unordered -collection of files. Each file is named by -its SHA1 hash encoded in hexadecimal. +collection of artifacts. Each artifact is named by +its SHA1 hash encoded in lowercase hexadecimal. In many contexts, the name can be abbreviated to a unique prefix. A five- or six-character prefix usually suffices to uniquely identify a file.</p></li> -<li><p>Because files are named by their SHA1 hash, all files -are immutable. Any change to the content of a file also -changes the hash that forms the files name, thus -creating a new file. Both the old original version of the -file and the new change are preserved under different names.</p></li> +<li><p>Because artifacts are named by their SHA1 hash, all artifacts +are immutable. Any change to the content of a artifact also +changes the hash that forms the artifacts name, thus +creating a new artifact. Both the old original version of the +artifact and the new change are preserved under different names.</p></li> -<li><p>It is theoretically possible for two files with different +<li><p>It is theoretically possible for two artifacts with different content to share the same hash. But finding two such -files is so incredibly difficult and unlikely that we +artifacts is so incredibly difficult and unlikely that we consider it to be an impossibility.</p></li> -<li><p>The signature of a file is the SHA1 hash of the -file itself, exactly as it appears on disk. No prefix -or meta-information about the file is added before computing +<li><p>The signature of an artifact is the SHA1 hash of the +artifact itself, exactly as it would appear in a disk file. No prefix +or meta-information about the artifact is added before computing the hash. So you can always find the SHA1 signature of a file by using the "sha1sum" command-line utility.</p></li> -<li><p>The files that comprise the global state of a repository +<li><p>The artifacts that comprise the global state of a repository are the complete global state of that repository. The SQLite database that holds the repository contains additional information -about linkages between files, but all of that added information +about linkages between artifacts, but all of that added information can be discarded and reconstructed by rescanning the content -files.</p></li> +artifacts.</p></li> <li><p>Two repositories for the same project can synchronize -their global states simply by sharing files. The local +their global states simply by sharing artifacts. The local state of repositories is not normally synchronized or shared.</p></li> -<li><p>Every repository has a special file at the top-level +<li><p>Every baseline has a special file at the top-level named "manifest" which is an index of all other files in -the system. The manifest is automatically created and +that baseline. The manifest is automatically created and maintained by the system.</p></li> <li><p>The <a href="fileformat.html">file formats</a> used by Fossil are all very simple so that with access to the original content files, one can easily reconstruct