DELETED www/build.html Index: www/build.html ================================================================== --- www/build.html +++ /dev/null @@ -1,82 +0,0 @@ - -Building And Installing Fossil - - -

[ Index ]

-
-

Installing Fossil

- -

This page describes how to build and install Fossil. The -whole process is designed to be very easy.

- -

0.0 Using A Precompiled Binary

- -

You can skip steps 1.0 and 2.0 below by downloading -a precompiled binary -appropriate for your platform. If you use a precompiled binary -jump immediate to step 3.0.

- -

1.0 Obtaining The Source Code

- -

Fossil is self-hosting, so you can obtain a ZIP archive containing -a snapshot of the latest version directly from fossil's own fossil -repository. Follow these steps:

- -
    -

  1. Pointer your webbrowser at - -http://www.fossil-scm.org/fossil/login.

    2. - -

  2. Log in as anonymous. The password is shown on screen. -The reason for requiring this login is to prevent spiders from -walking the entire website, downloading ZIP archives -of every historical version, and thereby soaking up all our bandwidth.

    3. - -

  3. Click on the -Timeline or -Leaves link at -the top of the page.

    4. - -

  4. Select a version of of fossil you want to download. Click on its -link. Note that you must successfully log in as "anonymous" in step 1 -above in order to see the link to the detailed version information.

    5. - -

  5. On the version information page, click on the -"Zip Archive" link. This link will build a ZIP archive of the -complete source code and download it to your browser.

    6. -
- -

2.0 Compiling

- -

Follow these steps to compile:

- -
    -
  1. -

    Create a directory to hold the source code. Then unzip the -ZIP archive you downloaded into that directory. You should be -in the top-level folder of that directory

    2. - -

  2. (Optional:) -Edit the Makefile to set it up like you want. You probably do not -need to do anything. Do not be intimidated: There are only 5 -variables in the makefile that can be changed. The whole Makefile -is only a few dozen lines long and most of those lines are comments.

    - -

  3. Type "make" -

- -

3.0 Installing

- -
    -
  1. -

    The finished binary is named "fossil". Put this binary in a -directory that is somewhere on your PATH environment variable. -It does not matter where.

    - -
  2. -

    (Optional:) -To uninstall, just delete the binary.

    -
- - - DELETED www/concepts.html Index: www/concepts.html ================================================================== --- www/concepts.html +++ /dev/null @@ -1,378 +0,0 @@ - - -Fossil Concepts - - -

[ Index ]

-
-

-Fossil Concepts -

- -

1.0 Introduction

-

-Fossil is a - -software configuration management system. -Fossil is software that is designed to control and track the -development of a software project and to record the history -of the project. -There are many such systems in use today. Fossil strives to -distinguish itself from the others by being extremely simple -to setup and operate.

- -

This document is intended as a quick introduction to the concepts -behind fossil.

- -

2.0 Composition Of A Project

- - -

A software project normally consists of a "source tree". -A source tree is a hierarchy of files that are used to generate -the end product. The source tree changes over time as the -software grows and expands and as features are added and bugs -are fixed. A snapshot of the source tree at any point in time -is called a "version" or "revision" or a "baseline" of the product. -In fossil, we use the name "baseline".

- -

A "repository" is a database that contains copies of all historical -versions or baselines for a project. Baselines are normally stored in the -repository in a highly space-efficient compressed format (delta encoding). -But that is an implementation detail that you the user need not worry over. -Think of the repository as a safe place where all your old baselines are -securely stored away and available for retrieval whenever you need -them.

- -

A repository in fossil is a single file on your disk. This file -might be rather large (dozens or hundreds of megabytes for a large -or long running project) but it is nevertheless just a file. You -can move it around, rename it, write it out to a memory stick, or -do anything else you normally do with files.

- -

Each source tree that is controlled by fossil is associated with -a single repository on the local disk drive. You can tie two or more -source trees to a single repository if you want (though one -tree per repository is the most common configuration.) So a -single repository can be associated with many source trees, but -each source tree is associated with only one repository.

- -

Fossil source trees may not overlap. A fossil source tree is identified -by a file named "_FOSSIL_" in the root directory of the source tree. Every -file that is a sibling of _FOSSIL_ and every file in every subfolder is -considered potentially a part of the source tree. The _FOSSIL_ file -contains (among other things) the pathname of the repository with which -the source tree is associated. On the other hand, the repository has -no record of its source trees. So you are free to delete a source tree -or move it around without consequence. But if you move or rename or -delete a repository, then any source trees associated with that repository -will no longer be able to locate their repository and will stop working.

- -

When multiple developers are working on the same project, each -developer typically has his or her own local repository and an associated -source tree in which to work. Developers share their work by -"syncing" the content of their local repositories either directly -or through a central server. Changes can "push" from the local -repository into a remote repository. Or changes can "pull" from a -remote repository into a local repository. Or one can do a "sync" -which is a shortcut for doing both a push and a pull at the same time. -Fossil also has the concept of "cloning". A "clone" is like a "pull", -except that instead of beginning with an existing local repository, -a clone begins with nothing and creates a new local repository that -is a duplicate of a remote repository.

- -

Communication between repositories is via HTTP. Remote -repositories are identified by URL. You can also point a webbrowser -at a repository and get human-readable status, history, and tracking -information about the project.

- -

2.1 Identification Of Artifacts

- -

A particular version of a particular file is called an "artifact". -Each artifact has a universally unique name which is the -SHA1 hash of the content -of that file expressed as 40 characters of lower-case hexadecimal. Such -a hash is referred to as the Universally Unique Identifier or UUID -for the artifact. The SHA1 algorithm is created with the purpose of -providing a highly forgery-resistent identifier for a file. Given any -file it is simple to find the UUID for that file. But given a -UUID it is computationally intractable to generate a file that will -have that UUID.

- - -

UUIDs look something like this:

- -
-6089f0b563a9db0a6d90682fe47fd7161ff867c8
-59712614a1b3ccfd84078a37fa5b606e28434326
-19dbf73078be9779edd6a0156195e610f81c94f9
-b4104959a67175f02d6b415480be22a239f1f077
-997c9d6ae03ad114b2b57f04e9eeef17dcb82788 -
- -

When referring to an artifact using fossil, you can use a unique -prefix of the UUID that is four characters or longer. This saves -a lot of typing. When displaying UUIDs, fossil will usually only -show the first 10 digits since that is normally enough to uniquely -identify a file.

- -

Changing (or adding or removing) a single byte in a file results -in a completely different UUID. And since the UUID is the name of -the artifact, making any change to a file results in a new artifact. -In this way, artifacts are immutable.

- -

A repository is really just an unordered collection of -artifacts. New artifacts can be added to the repository, but -existing artifacts can never be removed. Fossil is designed in -such a way that it can be handed a set of artifacts in any -order and it can figure out the relationship between those -artifacts and reconstruct the complete development history of -a software project.

- -

2.2 Manifests

- -

At the root of a source tree is a special file called the -"manifest". The manifest is a listing of all other files in -that source tree. The manifest contains the (complete) UUID -of the file and the name of the file as it appears on disk, -and thus serves as a mapping from UUID to disk name. The UUID -of the manifest is the UUID that identifies a baseline. When -you look at a "timeline" of changes in fossil, the UUID associated -with each check-in or commit is really just the UUID of the -manifest for that baseline.

- -

Fossil automatically generates a manifest whenever you "commit" -a new baseline. So this is not something that you, the developer, -need to worry with. The format of a manifest is intentionally -designed to be simple to parse, so that if -you want to read and interpret a manifest, either by hand or -with a script, that is easy to do. But you will probably never -need to do so.

- -

In addition to identifying all files in the baseline, a -manifest also contains a check-in comment, the date and time -when the baseline was established, who created the baseline, -and links to other baselines from which the current baseline -is derived. There is also a couple of checksums used to verify -the integrity of the baseline. And the whole manifest might -be PGP clearsigned.

- -

2.3 Key concepts

- - - -

3.0 Fossil - The Program

- -

Fossil is software. The implementation of fossil is in the form -of a single executable named "fossil". To install fossil on your system, -all you have to do is obtain a copy of this one executable file (either -by downloading a precompiled version or compiling it yourself) and then -putting that file somewhere on your PATH.

- -

Fossil is completely self-contained. It is not necessary to -install any other software in order to use fossil. You do not need -CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL, -SQLite, patch, or any similar software on your system in order to use -fossil effectively. You will want to have some kind of text editor -for entering check-in comments. Fossil will use whatever text editor -is identified by your VISUAL environment variable. Fossil will also -use GPG to clearsign your manifests if you happen to have it installed, -but fossil will skip that step if GPG missing from your system. -You can optionally set up fossil to use external "diff" programs, -though a perfectly functional "diff" algorithm is built it and works -find for most people.

- -

To uninstall fossil, simply delete the executable.

- -

To upgrade an older version of fossil to a newer version, just -replace the old executable with the new one. You might need to -run a one-time command to restructure your repositories after -an upgrade. Check the instructions that come with the upgrade -for details.

- -

To use fossil, simply type the name of executable in your -shell, followed by one of the various built-in commands and -arguments appropriate for that command. For example:

- -
-fossil help -
- -

In the next section, when we say things like "use the help -command" we mean to use the command name "help" as the first -token after the name of the fossil executable, as shown above.

- -

4.0 Workflow

- - -
    -

  1. -Establish a local repository using either the new command -to start a new project, or the clone command to make a clone -of a repository for an existing project. -

    2. - -

  2. -Establish one or more source trees by changing your working directory -to where you want the root of the source tree to be, then issuing -the open command with the name of the repository file as its -argument. -

    3. - -

  3. -Use the update command followed by a UUID to cause your -source tree to change to the baseline identified by that UUID. -The timeline or leaves commands might help you to -identify an appropriate baseline. -

    4. - -

  4. -Edit the code. Add new files to the source tree using the add -command. Omit files from future baselines using the rm command. -(Even when you remove files from future baselines, those files continue -to exist in historical baselines.) Test your changes. -

    5. - -

  5. -Create a new baseline using the commit command. You will be prompted -for a check-in comment and also for your GPG key if you have GPG installed. -The commit copies the edits you have made in your local source -tree into your local repository. -

    6. - -

  6. -Share your changes with others using the push command. -Push causes the edits you committed into your local repository to be -pushed out into other repositories. -

    7. - -

  7. -When your coworkers make their own changes, you can pull those changes -into your local repository using the pull command. Note that -the pull command only pulls the changes into your local repository, -not into your local source tree. -

    8. - -

  8. -After the changes of others are in your local repository, you -can move them into your local source tree using update. If -you have made parallel -changes, you can merge your changes together with your coworkers changes -by do an update to your latest baseline, then doing a -merge with your coworkers latest baseline. After your -verify that the merged code is still functional, you can commit -a new baseline that contains both yours and your coworkers changes -and then push the new baseline back to your coworker. -

    9. - -

  9. -Repeat all of the above until you have generated great software. -

    10. -
- -

4.1 Variations

- -

The settings lets you view and modify various operating -properties of fossil. Among the available settings is "autosync" -mode. When autosync is enabled, the push and pull of content from -your local server is largely automated. Whenever you use the update -command, fossil first does a pull to see if other users have -perhaps added new baselines to the central repository. When you -commit, fossil also does a pull and issues a warning -if your check-in would cause a fork. After a commit, fossil -automatically does a push to send your changes up to the -central server.

- -

With autosync enabled, fossil works like -CVS or -Subversion. -When autosync disabled, fossil works more like -Monotone, -GIT, or -Mercurial. -The fun thing about fossil is that it will work either -way, depending on your needs of the moment. You can freely switch -between these operating modes using commands like:

- -
-fossil setting autosync off
-fossil setting autosync on -
- -

For additional information about autosync and other settings -using the help command.

- -

5.0 Setting Up A Fossil Server

- -

With other configuration management software, setting up a server is -a lot of work and normally takes time, patience, and a lot of system -knowledge. Fossil is designed to avoid this frustration. Setting up -a server with fossil is ridiculously easy. You have three options:

- -
    -

  1. Setting up a stand-alone server

    - -

    From within your source tree just use the server command and -fossil will start listening for incoming requests on TCP port 8080. -You can point your webbrowser at -http://localhost:8080/ and begin exploring. Or your coworkers -can do pushes or pulls against your server. Use the --port -option to the server command to specify a different TCP port. If -you do not have a local source tree, use the -R command-line -option to specify the repository file.

    - -

    A stand-alone server is a great way to set of transient connections -between coworkers for doing quick pushes or pulls. But you can also -set up a permanent stand-alone server if you prefer. Just make -arrangements for fossil to be launched with appropriate arguments -after every reboot.

    -
    2. - -

  2. Setting up a CGI server

    - -

    If you have a webserver running on your machine already, you can -set up fossil to be run from CGI. Simply create an executable script -that looks something like this:

    - -
    -#!/usr/local/bin/fossil
-repository: /home/me/bigproject.fossil
-
    - -

    Edit this script to use whatever pathnames are appropriate for -your project. Then point your webbrowser at the script and off you -go.

    3. - -

  3. Setting up an inetd server

    - -

    If you have inetd or xinetd running on your system, you can set -those services up to launch fossil to deal with inbound TCP/IP connections -on whatever port you want. Set up inetd or xinetd to launch fossil -like this:

    - -
    -/usr/local/bin/fossil http /home/me/bigproject.fossil
-
    - -

    As before, change the filenames to whatever is appropriate for -your system. You can have fossil run as any user that has write -permission on the repository and on the directory that contains the -repository. But it is safer to run fossil as root. When fossil -sees that it is running as root, it automatically puts itself into -a chroot jail and -drops all privileges prior to reading any information from the client. -Since fossil is a stand-alone program, you do not need to put anything -in the chroot jail with fossil in order for it to do its job.

    -
    4. -
DELETED www/delta_encoder_algorithm.html Index: www/delta_encoder_algorithm.html ================================================================== --- www/delta_encoder_algorithm.html +++ /dev/null @@ -1,236 +0,0 @@ - - -Fossil Delta Encoding Algorithm - - -

[ Index ]

-
-

-Fossil Delta Encoding Algorithm -

- -

A key component for the efficient storage of multiple revisions of -a file in fossil repositories is the use of delta-compression, i.e. to -store only the changes between revisions instead of the whole -file.

- -

This document describes the encoding algorithm used by Fossil to -generate deltas. It is targeted at developers working on either -fossil itself, or on tools compatible with -it. The exact format of the generated byte-sequences, while in general -not necessary to understand encoder operation, can be found in the -companion specification titled "Fossil -Delta Format". -

- -

The entire algorithm is inspired -by rsync.

- -

1.0 Arguments, Results, and Parameters

- -

The encoder takes two byte-sequences as input, the "original", and -the "target", and returns a single byte-sequence containing the -"delta" which transforms the original into the target upon its -application.

- -

Note that the data of a "byte-sequence" includes its length, -i.e. the number of bytes contained in the sequence.

- -

The algorithm has one parameter named "NHASH", the size of the -"sliding window" for the "rolling hash", in bytes. These two terms are -explained in the next section. The value of this parameter has to be a -power of two for the algorithm to work. For Fossil the value of this -parameter is set to "16".

- -

2.0 Operation

- -

The algorithm is split into three phases which generate -the header, -segment list, -and trailer of the delta, per -its general structure.

- -

The two phases generating header and trailer are not covered here -as their implementation trivially follows directly from the -specification of the delta format.

- -

This leaves the segment-list. Its generation is done in two phases, -a pre-processing step operating on the "original" byte-sequence, -followed by the processing of the "target" byte-sequence using the -information gathered by the first step.

- -

2.1 Preprocessing the original

- -

A major part of the processing of the "target" is to find a range -in the "original" which contains the same content as found at the -current location in the "target".

- -

A naive approach to this would be to search the whole "original" -for such content. This however is very inefficient as it would search -the same parts of the "original" over and over. What is done instead -is to sample the "original" at regular intervals, compute signatures -for the sampled locations and store them in a hash table keyed by -these signatures.

- -

That is what happens in this step. The following processing step -can then the compute signature for its current location and then has -to search only a narrow set of locations in the "original" for -possible matches, namely those which have the same signature.

- -

In detail:

- -
    -
  1. The "original" is split into chunks of NHASH bytes. Note that a -partial chunk of less than NHASH bytes at the end of "original" is -ignored. -
    2. -
  2. The rolling hash of each chunk is -computed. -
    3. -
  3. A hashtable is filled, mapping from the hashes of the chunks to -the list of chunk locations having this hash. -
    4. -
- -

2.1 Processing the target

- -

This, the main phase of the encoder, processes the target in a loop -from beginning to end. The state of the encoder is captured by two -locations, the "base" and the "slide". "base" points to the first byte -of the target for which no delta output has been generated yet, and -"slide" is the location of the window used to look in the "origin" for -commonalities. This window is NHASH bytes long.

- -

Initially both "base" and "slide" point to the beginning of the -"target". In each iteration of the loop the encoder decides whether to -

 -

- - -

To make this decision the encoder first computes the hash value for -the NHASH bytes in the window and then looks at all the locations in -the "origin" which have the same signature. This part uses the hash -table created by the pre-processing step to effiently find these -locations.

- -

For each of the possible candidates the encoder finds the maximal -range of bytes common to both "origin" and "target", going forward and -backward from "slide" in the "target", and the candidate location in -the "origin". This search is constrained on the side of the "target" -by the "base" (backward search), and the end of the "target" (forward -search), and on the side of the "origin" by the beginning and end of -the "origin", respectively.

- -

There are input files for which the hash chains generated by the -pre-processing step can become very long, leading to long search times -and affecting the performance of the delta generator. To limit the -effect such long chains can have the actual search for candidates is -bounded, looking at most N candidates. Currently N is set to 250.

- -

From the ranges for all the candidates the best (= largest) common -range is taken and it is determined how many bytes are needed to -encode the bytes between the "base" and the end of that range. If the -range extended back to the "base" then this can be done in a single -copy instruction. Otherwise, i.e if there is a gap between the "base" -and the beginning of the range then two instructions are needed, one -to insert the bytes in the gap as a literal, and a copy instruction -for the range itself. The general situation at this point can be seen -in the picture to the right.

- -

If the number of bytes needed to encode both gap (if present), and -range is less than the number of bytes we are encoding the encoder -will emit the necessary instructions as described above, set "base" -and "slide" to the end of the encoded range and start the next -iteration at that point.

- -

If, on the other hand, the encoder either did not find candidate -locations in the origin, or the best range coming out of the search -needed more bytes to encode the range than there were bytes in the -range, then no instructions are emitted and the window is moved one -byte forward. The "base" is left unchanged in that case.

- -

The processing loop stops at one of two conditions: -

    -
  1. The encoder decided to move the window forward, but the end of the -window reached the end of the "target". -
    2. -
  2. After the emission of instructions the new "base" location is -within NHASH bytes of end of the "target", i.e. there are no more than -at most NHASH bytes left. -
    3. -
-

- -

If the processing loop left bytes unencoded, i.e. "base" not -exactly at the end of the "target", as is possible for both end -conditions, then one last insert instruction is emitted to put these -bytes into the delta.

- -

3.0 Exceptions

- -

If the "original" is at most NHASH bytes long no compression of -changes is possible, and the segment-list of the delta consists of a -single literal which contains the entire "target".

- -

This is actually equivalent to the second end condition of the -processing loop described in the previous section, just checked before -actually entering the loop.

- -

4.0 The rolling hash

- -

The rolling hash described below and used to compute content -signatures was chosen not only for good hashing properties, but also -to enable the easy (incremental) recalculation of its value for a -sliding window, i.e. where the oldest byte is removed from the window -and a new byte is shifted in.

- -

4.1 Definition

- -

Assuming an array Z of NHASH bytes (indexing starting at 0) the -hash V is computed via

- -

-

-

-

-

- -where A and B are unsigned 16-bit integers (hence the mod), and -V is a 32-bit unsigned integer with B as MSB, A as LSB. - -

4.2 Incremental recalculation

- -

Assuming an array Z of NHASH bytes (indexing starting at 0) with -hash V (and components A and B), the dropped -byte , and the new byte - , the new hash can -be computed incrementally via:

- -

-

-

-

-

- -

For A, the regular sum, it can be seen easily that this the correct -way recomputing that component.

- -

For B, the weighted sum, note first that has the weight NHASH in the sum, so that is what has -to be removed. Then adding in -adds one weight factor to all the other values of Z, and at last adds -in with weight 1, also -generating the correct new sum

- - - DELETED www/delta_format.html Index: www/delta_format.html ================================================================== --- www/delta_format.html +++ /dev/null @@ -1,223 +0,0 @@ - - -Fossil Delta Format - - -

[ Index ]

-
-

-Fossil Delta Format -

- -

A key component for the efficient storage of multiple revisions of -a file in fossil repositories is the use of delta-compression, i.e. to -store only the changes between revisions instead of the whole -file.

- -

This document describes the format used to encode such changes, -also known as "delta". It is targeted at developers working on either -fossil itself, or on tools compatible with -it.

- -

1.0 Structure

- - -

A delta consists of three parts, a "header", a "trailer", and a -"segment-list" between them.

- -

Both header and trailer provide information about the target -helping the decoder, and the segment-list describes how the target can -be constructed from the original.

- -

1.1 Header

- - -

The header consists of a single number followed by a newline -character (ASCII 0x0a). The number is the length of the target in -bytes.

- -

This means that, given a delta, the decoder can compute the size of -the target (and allocate any necessary memory based on that) by simply -reading the first line of the delta and decoding the number found -there. In other words, before it has to decode everything else.

- -

1.2 Trailer

- - -

The trailer consists of a single number followed by a semicolon (ASCII -0x3b). This number is a checksum of the target and can be used by a -decoder to verify that the delta applied correctly, reconstructing the -target from the original.

- -

The checksum is computed by treating the target as a series of -32-bit integer numbers (MSB first), and summing these up, modulo -2^32-1. A target whose length is not a multiple of 4 is padded with -0-bytes (ASCII 0x00) at the end.

- -

By putting this information at the end of the delta a decoder has -it available immediately after the target has been reconstructed -fully.

- -

1.3 Segment-List

- - -

The segment-list of a delta describes how to create the target from -the original by a combination of inserting literal byte-sequences and -copying ranges of bytes from the original. This is there the -compression takes place, by encoding the large common parts of -original and target in small copy instructions.

- -

The target is constructed from beginning to end, with the data -generated by each instruction appended after the data of all previous -instructions, with no gaps.

- -

1.3.1 Insert Literal

- -

A literal is specified by two elements, the size of the literal in -bytes, and the bytes of the literal itself.

- - -

The length is written first, followed by a colon character (ASCII -0x3a), followed by the bytes of the literal.

- -

1.3.2 Copy Range

- -

A range to copy is specified by two numbers, the offset of the -first byte in the original to copy, and the size of the range, in -bytes. The size zero is special, its usage indicates that the range -extends to the end of the original.

- - -

The length is written first, followed by an "at" character (ASCII -0x40), then the offset, followed by a comma (ASCII 0x2c).

- -

2.0 Encoding of integers

- -

-The format currently handles only 32 bit integer numbers. They are -written base-64 encoded, MSB first, and without leading -"0"-characters, except if they are significant (i.e. 0 => "0"). -

- -

-The base-64 coding is described in -RFC 3548. -

- -

3.0 Examples

- -

3.1 Integer encoding

- - - - - - - - - - - - - - - - - - -
ValueEncoding
00
62461Xb
-11014387702zMM3E
- -

3.2 Delta encoding

- -

An example of a delta using the specified encoding is:

- -
-1Xb
-4E@0,2:thFN@4C,6:scenda1B@Jd,6:scenda5x@Kt,6:pieces79@Qt,F: Example: eskil~E@Y0,2zMM3E;
-
- -

This can be taken apart into the following parts:

- - - - - - - - - - - - - - - - -
What Encoding Meaning Details
Header 1Xb Size 6246
S-List 4E@0, Copy 270 @ 0
  2:th Literal 2 'th'
  FN@4C, Copy 983 @ 268
  6:scenda Literal 6 'scenda'
  1B@Jd, Copy 75 @ 1256
  6:scenda Literal 6 'scenda'
  5x@Kt, Copy 380 @ 1336
  6:pieces Literal 6 'pieces'
  79@Qt, Copy 457 @ 1720
  F: Example: eskilLiteral 15 ' Example: eskil'
  ~E@Y0, Copy 4046 @ 2176
Trailer2zMM3E Ckecksum -1101438770
- -

The unified diff behind the above delta is

- -
-bluepeak:(761) ~/Projects/Tcl/Fossil/Devel/devel > diff -u ../DELTA/old ../DELTA/new 
---- ../DELTA/old        2007-08-23 21:14:40.000000000 -0700
-+++ ../DELTA/new        2007-08-23 21:14:33.000000000 -0700
-@@ -5,7 +5,7 @@
- 
-  *  If the server does not have write permission on the database
-     file, or on the directory containing the database file (and 
--    it is thus unable to update database because it cannot create
-+    it is thus unable to update the database because it cannot create
-     a rollback journal) then it currently fails silently on a push.
-     It needs to return a helpful error.
- 
-@@ -27,8 +27,8 @@
-  *  Additional information displayed for the "vinfo" page:
- 
-      +  All leaves of this version that are not included in the
--        decendant list.  With date, user, comment, and hyperlink.
--        Leaves in the decendant table should be marked as such.
-+        descendant list.  With date, user, comment, and hyperlink.
-+        Leaves in the descendant table should be marked as such.
-         See the compute_leaves() function to see how to find all
-         leaves.
-      +  Add file diff links to the file change list.
-@@ -37,7 +37,7 @@
- 
-  *  The /xfer handler (for push, pull, and clone) does not do
-     delta compression.  This results in excess bandwidth usage.
--    There are some code in xfer.c that are sketches of ideas on
-+    There are some pieces in xfer.c that are sketches of ideas on
-     how to do delta compression, but nothing has been implemented.
- 
-  *  Enhancements to the diff and tkdiff commands in the cli.
-@@ -45,7 +45,7 @@
-     single file.  Allow diffs against any two arbitrary versions,
-     not just diffs against the current check-out.  Allow 
-     configuration options to replace tkdiff with some other
--    visual differ of the users choice.
-+    visual differ of the users choice. Example: eskil.
- 
-  *  Ticketing interface (expand this bullet)
-
-
- - - -

Notes

- - - - - DELETED www/fileformat.html Index: www/fileformat.html ================================================================== --- www/fileformat.html +++ /dev/null @@ -1,341 +0,0 @@ - - -Fossil File Format - - -

[ Index ]

-
-

-Fossil File Formats -

- -

-The global state of a fossil repository is determined by an unordered -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. -

- -

-Each artifact in the repository is named by its SHA1 hash. -No prefixes or meta information is added to a artifact before -its hash is computed. The name of a artifact in the repository -is exactly the same SHA1 hash that is computed by sha1sum -on the file as it exists in your source tree.

- -

-Some artifacts have a particular format which gives them special -meaning to fossil. Fossil recognizes:

- - - -

These five artifact types are described in the sequel.

- -

1.0 The Manifest

- -

A manifest defines a baseline or version of the project -source tree. The manifest contains a list of artifacts for -each file in the project and the corresponding filenames, as -well as information such as parent baselines, the name of the -programmer who created the baseline, the date and time when -the baseline was created, and any check-in comments associated -with the baseline.

- -

-Any artifact in the repository that follows the syntactic rules -of a manifest is a manifest. Note that a manifest can -be both a real manifest and also a content file, though this -is rare. -

- -

-A manifest is a text file. Newline characters -(ASCII 0x0a) separate the file into "cards". -Each card begins with a single -character "card type". Zero or more arguments may follow -the card type. All arguments are separated from each other -and from the card-type character by a single space -character. There is no surplus white space between arguments -and no leading or trailing whitespace except for the newline -character that acts as the card separator. -

- -

-All cards of the manifest occur in strict sorted lexicographical order. -No card may be duplicated. -The entire manifest may be PGP clear-signed, but otherwise it -may contain no additional text or data beyond what is described here. -

- -

-Allowed cards in the manifest are as follows: -

- -
-C checkin-comment
-D time-and-date-stamp
-F filename SHA1-hash
-P SHA1-hash+
-R repository-checksum
-U user-login
-Z manifest-checksum -
- -

-A manifest must have exactly one C-card. The sole argument to -the C-card is a check-in comment that describes the check-in that -the manifest defines. The check-in comment is text. The following -escape sequences are applied to the text: -A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A -newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash -(ASCII 0x5C) is represented as two backslashes "\\". Apart from -space and newline, no other whitespace characters are allowed in -the check-in comment. Nor are any unprintable characters allowed -in the comment. -

- -

-A manifest must have exactly one D-card. The sole argument to -the D-card is a date-time stamp in the ISO8601 format. The -date and time should be in coordinated universal time (UTC). -The format is: -

- -
-YYYY-MM-DDTHH:MM:SS -
- -

-A manifest has zero or more F-cards. Each F-card defines a file -(other than the manifest itself) which is part of the baseline that -the manifest defines. There are two arguments. The first argment -is the pathname of the file in the baseline relative to the root -of the project file hierarchy. No ".." or "." directories are allowed -within the filename. Space characters are escaped as in C-card -comment text. Backslash characters and newlines are not allowed -within filenames. The directory separator character is a forward -slash (ASCII 0x2F). The second argument to the F-card is the -full 40-character lower-case hexadecimal SHA1 hash of the content -artifact. -

- -

-A manifest has zero or one P-cards. Most manifests have one P-card. -The P-card has a varying number of arguments that -defines other manifests from which the current manifest -is derived. Each argument is an 40-character lowercase -hexadecimal SHA1 of the predecessor manifest. All arguments -to the P-card must be unique to that line. -The first predecessor is the direct ancestor of the manifest. -Other arguments define manifests with which the first was -merged to yield the current manifest. Most manifests have -a P-card with a single argument. The first manifest in the -project has no ancestors and thus has no P-card. -

- -

-A manifest may optionally have a single R-card. The R-card has -a single argument which is the MD5 checksum of all files in -the baseline except the manifest itself. The checksum is expressed -as 32-characters of lowercase hexadecimal. The checksum is -computed as follows: For each file in the baseline (except for -the manifest itself) in strict sorted lexicographical order, -take the pathname of the file relative to the root of the -repository, append a single space (ASCII 0x20), the -size of the file in ASCII decimal, a single newline -character (ASCII 0x0A), and the complete text of the file. -Compute the MD5 checksum of the the result. -

- -

-Each manifest has a single U-card. The argument to the U-card is -the login of the user who created the manifest. The login name -is encoded using the same character escapes as is used for the -check-in comment argument to the C-card. -

- -

-A manifest has an option Z-card as its last line. The argument -to the Z-card is a 32-character lowercase hexadecimal MD5 hash -of all prior lines of the manifest up to and including the newline -character that immediately preceeds the "Z". The Z-card is just -a sanity check to prove that the manifest is well-formed and -consistent. -

- -

2.0 Clusters

- -

-A cluster is a artifact that declares the existance of other artifacts. -Clusters are used during repository synchronization to help -reduce network traffic. -

- -

-Clusters follow a syntax that is very similar to manifests. -A Cluster is a line-oriented text file. Newline characters -(ASCII 0x0a) separate the artifact into cards. Each card begins with a single -character "card type". Zero or more arguments may follow -the card type. All arguments are separated from each other -and from the card-type character by a single space -character. There is no surplus white space between arguments -and no leading or trailing whitespace except for the newline -character that acts as the card separator. -All cards of a cluter occur in strict sorted lexicographical order. -No card may be duplicated. -The cluster may not contain additional text or data beyond -what is described here. -Unlike manifests, clusters are never PGP signed. -

- -

-Allowed cards in the cluster are as follows: -

- -
-M uuid
-Z checksum -
- -

-A cluster contains one or more "M" cards followed by a single "Z" -line. Each M card has a single argument which is the UUID of -another artifact in the repository. The Z card work exactly like -the Z card of a manifest. The argument to the Z card is the -lower-case hexadecimal representation of the MD5 checksum of all -prior cards in the cluster. Note that the Z card is required -on a cluster. -

- - -

3.0 Control Artifacts

- -

-Control artifacts are used to assign properties to other artifacts -within the repository. The basic format of a control artifact is -the same as a manifest or cluster. A control artifact is a text -files divided into cards by newline characters. Each card has a -single-character card type followed by arguments. Spaces separate -the card type and the arguments. No surplus whitespace is allowed. -All cards must occur in strict lexigraphical order. -

- -

-Allowed cards in a control artifact are as follows: -

- -
-D time-and-date-stamp
-T (+|-|*)tag-name uuid ?value?
-Z checksum
-
- -

-A control artifact must have one D card and one Z card and -one or more or more T cards. No other cards or other text is -allowed in a control artifact. Control artifacts might be PGP -clearsigned.

- -

The D card and the Z card of a control artifact are the same -as in a manifest.

- -

The T card represents a "tag" or property that is applied to -some other artifact. The T card has two or three values. The -second argument is the 40 character lowercase UUID of the artifact -to which the tag is to be applied. The -first value is the tag name. The first character of the tag -is either "+", "-", or "*". A "+" means the tag should be added -to the artifact. The "-" means the tag should be removed. -The "*" character means the tag should be added to the artifact -and all direct decendants (but not branches) of the artifact down -to but not including the first decendant that contains a -more recent "-" tag with the same name. -The optional third argument is the value of the tag. A tag -without a value is a boolean.

- -

When two or more tags with the same name are applied to the -same artifact, the tag with the latest (most recent) date is -used.

- -

Some tags have special meaning. The "comment" tag when applied -to a baseline will override the check-in comment of that baseline -for display purposes.

- -

4.0 Wiki Pages

- -

A wiki page is an artifact with a format similar to manifests, -clusters, and control artifacts. The artifact is divided into -cards by newline characters. The format of each card is as in -manifests, clusters, and control artifacts. Wiki artifacts accept -the following card types:

- -
-D time-and-date-stamp
-L wiki-title
-P parent-uuid+
-U user-name
-W size \n text \n
-Z checksum -
- -

The D card is the date and time when the wiki page was edited. -The P card specifies the parent wiki pages, if any. The L card -gives the name of the wiki page. The U card specifies the login -of the user who made this edit to the wiki page. The Z card is -the usual checksum over the either artifact.

- -

The W card is used to specify the text of the wiki page. The -argument to the W card is an integer which is the number of bytes -of text in the wiki page. That text follows the newline character -that terminates the W card. The wiki text is always followed by one -extra newline.

- -

5.0 Ticket Changes

- -

A ticket-change artifact represents a change to a trouble ticket. -The following cards are allowed on a ticket change artifact:

- -
-D time-and-date-stamp
-J ?+?name value
-K ticket-uuid
-U user-name
-Z checksum -
- -

-The D card is the usual date and time stamp and represents the point -in time when the change was entered. The U card is the login of the -programmer who entered this change. The Z card is the checksum over -the entire artifact.

- -

-Every ticket has a UUID. The ticket to which this change is applied -is specified by the K card. A ticket exists if it contains one or -more changes. The first "change" to a ticket is what brings the -ticket into existance.

- -

-J cards specify changes to "fields" of the ticket. Each fossil -server has a ticket configuration which specifies the fields its -understands. This is not a limit on the fields that can appear -on the J cards, however. If a J card specifies a field that a -particular fossil server does not recognize, then that J card -is simply ignored.

- -

-The first argument of the J card is the field name. The second -value is the field value. If the field name begins with "+" then -the value is appended to the prior value. Otherwise, the value -on the J card replaces any previous value of the field. -The field name and value are both encoded using the character -escapes defined for the C card of a manifest. -

DELETED www/index.html Index: www/index.html ================================================================== --- www/index.html +++ /dev/null @@ -1,118 +0,0 @@ - - -Fossil SCM Homepage - - -

Fossil - A Software Configuration Management System

- -

-This is a preliminary homepage for a new software configuration -management system called "Fossil". -The system is -self-hosting on -two separate servers. -You can download the lastest sources -compile it yourself using the instructions below. -Or you can grab -precompiled binaries. -

- -

Design Goals For Fossil:

- - - -

Objectives Of Fossil:

- - - -

Other Links:

- - - -

Competing Projects:

- - - - - DELETED www/pop.html Index: www/pop.html ================================================================== --- www/pop.html +++ /dev/null @@ -1,84 +0,0 @@ - - -Fossil - Principles of Operation - - -

[ Index ]

-
-

Principles Of Operation

- -

-This page attempts to define the foundational principals upon -which Fossil is built. -

- -