Fossil SCM

Merge the fork back together.

drh 2008-05-16 00:27 trunk merge
Commit f94f7e5f49b8ca4458cd54d7ae34033a3d478b5b
Parent 5cf1206dfa72a8c…
22 files changed +12 +49 -28 -82 +15 -378 +445 -236 +6 -222 +120 -341 +106 -118 +44 -19 -84 +44 -279 +140 -99 +34 -468 +39
~ src/setup.c ~ src/wiki.c - www/build.html ~ www/build.wiki - www/concepts.html ~ www/concepts.wiki - www/delta_encoder_algorithm.html ~ www/delta_encoder_algorithm.wiki - www/delta_format.html ~ www/delta_format.wiki - www/fileformat.html ~ www/fileformat.wiki - www/index.html ~ www/index.wiki - www/pop.html ~ www/pop.wiki - www/quickstart.html ~ www/quickstart.wiki - www/selfcheck.html ~ www/selfcheck.wiki - www/sync.html ~ www/sync.wiki
M src/setup.c
+12
--- src/setup.c
+++ src/setup.c
@@ -600,10 +600,22 @@
600600
 @ <hr />
601601
 textarea_attribute("Project Description", 5, 60,
602602
 "project-description", "pd", "");
603603
 @ <p>Describe your project. This will be used in page headers for search
604604
 @ engines as well as a short RSS description.</p>
605
+ @ <hr />
606
+ entry_attribute("Home page", 60, "project-home", "phome", "");
607
+ @ <p>This sets the content source for the Home page ([/home]).
608
+ @ Enter a wiki page name (as wiki/PageName) or another URL relative to
609
+ @ this server's root (%s(g.zBaseURL)/).
610
+ @ The default is to use wiki/ProjectName. Make sure to use a valid name,
611
+ @ or your /home link will likely crash! (If that happens, simply come back
612
+ @ to this page and set it to a good (or empty) value.)
613
+ @ To use .wiki or .html files in your source tree as content, use a URL
614
+ @ in the form <tt>doc/VERSION/path/to/doc.wiki</tt>, where VERSION is either
615
+ @ the UUID of a version of that page or the word 'tip' to get the most recent
616
+ @ version.</p>
605617
 @ <hr />
606618
 @ <p><input type="submit" name="submit" value="Apply Changes"></p>
607619
 @ </form>
608620
 db_end_transaction(0);
609621
 style_footer();
610622
--- src/setup.c
+++ src/setup.c
@@ -600,10 +600,22 @@
600 @ <hr />
601 textarea_attribute("Project Description", 5, 60,
602 "project-description", "pd", "");
603 @ <p>Describe your project. This will be used in page headers for search
604 @ engines as well as a short RSS description.</p>
 
 
 
 
 
 
 
 
 
 
 
 
605 @ <hr />
606 @ <p><input type="submit" name="submit" value="Apply Changes"></p>
607 @ </form>
608 db_end_transaction(0);
609 style_footer();
610
--- src/setup.c
+++ src/setup.c
@@ -600,10 +600,22 @@
600 @ <hr />
601 textarea_attribute("Project Description", 5, 60,
602 "project-description", "pd", "");
603 @ <p>Describe your project. This will be used in page headers for search
604 @ engines as well as a short RSS description.</p>
605 @ <hr />
606 entry_attribute("Home page", 60, "project-home", "phome", "");
607 @ <p>This sets the content source for the Home page ([/home]).
608 @ Enter a wiki page name (as wiki/PageName) or another URL relative to
609 @ this server's root (%s(g.zBaseURL)/).
610 @ The default is to use wiki/ProjectName. Make sure to use a valid name,
611 @ or your /home link will likely crash! (If that happens, simply come back
612 @ to this page and set it to a good (or empty) value.)
613 @ To use .wiki or .html files in your source tree as content, use a URL
614 @ in the form <tt>doc/VERSION/path/to/doc.wiki</tt>, where VERSION is either
615 @ the UUID of a version of that page or the word 'tip' to get the most recent
616 @ version.</p>
617 @ <hr />
618 @ <p><input type="submit" name="submit" value="Apply Changes"></p>
619 @ </form>
620 db_end_transaction(0);
621 style_footer();
622
M src/wiki.c
+49 -28
--- src/wiki.c
+++ src/wiki.c
@@ -1,7 +1,8 @@
11
 /*
22
 ** Copyright (c) 2007 D. Richard Hipp
3
+** Copyright (c) 2008 Stephan Beal
34
 **
45
 ** This program is free software; you can redistribute it and/or
56
 ** modify it under the terms of the GNU General Public
67
 ** License version 2 as published by the Free Software Foundation.
78
 **
@@ -76,22 +77,42 @@
7677
 ** WEBPAGE: home
7778
 ** WEBPAGE: index
7879
 ** WEBPAGE: not_found
7980
 */
8081
 void home_page(void){
81
- char *zPageName = db_get("project-name",0);
82
- if( zPageName ){
83
- login_check_credentials();
84
- g.zExtra = zPageName;
85
- cgi_set_parameter_nocopy("name", g.zExtra);
86
- g.okRdWiki = 1;
87
- g.okApndWiki = 0;
88
- g.okWrWiki = 0;
89
- g.okHistory = 0;
90
- wiki_page();
82
+ char *zHomePage; /* name of home page */
83
+ char *zProjName; /* name of project */
84
+ zProjName = db_get("project-name",0);
85
+ zHomePage = db_get("project-home", zProjName );
86
+ if( zProjName && zProjName[0] ){
87
+ /* beware: this code causes cyclic redirects on a 404 because
88
+ not_found is directed here.
89
+ */
90
+ int lenP; /* strncmp() bounder */
91
+ int lenH; /* length of zProjName */
92
+ if( zHomePage && ! zHomePage[0] ){
93
+ zHomePage = zProjName;
94
+ }
95
+ lenP = strlen(zProjName);
96
+ lenH = strlen(zHomePage);
97
+ if( lenP < lenH ) lenP = lenH;
98
+ if( (zProjName == zHomePage) || (0==strncmp(zProjName,zHomePage,lenP)) ||
99
+ (0==strncmp(zHomePage,"home",lenP)/*avoid endless loop*/) ){
100
+ login_check_credentials();
101
+ g.zExtra = zHomePage;
102
+ cgi_set_parameter_nocopy("name", g.zExtra);
103
+ g.okRdWiki = 1;
104
+ g.okApndWiki = 0;
105
+ g.okWrWiki = 0;
106
+ g.okHistory = 0;
107
+ wiki_page();
108
+ }else{
109
+ cgi_redirect( zHomePage );
110
+ }
91111
 return;
92112
 }
113
+
93114
 style_header("Home");
94115
 @ <p>This is a stub home-page for the project.
95116
 @ To fill in this page, first go to
96117
 @ <a href="%s(g.zBaseURL)/setup_config">setup/config</a>
97118
 @ and establish a "Project Name". Then create a
@@ -599,21 +620,16 @@
599620
 @ </ol>
600621
 style_footer();
601622
 }
602623
603624
 /*
604
-** wiki_cmd_commit() is the implementation of "wiki commit ...".
625
+** wiki_cmd_commit() is the implementation of "wiki commit ...".
605626
 **
606627
 ** As arguments it expects:
607628
 **
608629
 ** zPageName = the wiki entry's name.
609630
 **
610
-** rid = record ID for the zPageName entry. This func SHOULD deduce
611
-** this from zPageName, but the code which calls this func already has
612
-** the rid, so we pass it along here. If it does not match the entry
613
-** for zPageName then Undefined Behaviour.
614
-**
615631
 ** in = input file. The file is read until EOF but is not closed
616632
 ** by this function (it might be stdin!).
617633
 **
618634
 ** Returns 0 on error, non-zero on success.
619635
 **
@@ -620,19 +636,33 @@
620636
 ** TODOs:
621637
 ** - take EITHER zPageName OR rid. We don't need both.
622638
 ** - make use of the return value. Add more error checking.
623639
 ** - give the uuid back to the caller so it can be shown
624640
 ** in the status output. ("committed version XXXXX of page ...")
641
+** - return some status telling the user if there were no diffs
642
+** (i.e. no commit). How can we find this out?
625643
 */
626
-int wiki_cmd_commit( char const * zPageName, int rid, FILE * in )
644
+int wiki_cmd_commit( char const * zPageName, FILE * in )
627645
 {
628646
 Blob wiki; /* Wiki page content */
629647
 Blob content; /* read-in content */
630648
 Blob cksum; /* wiki checksum */
649
+ int rid; /* rid of existing entry. */
631650
 int nrid; /* not really sure */
632651
 char * zDate; /* timestamp */
633652
 char * zUuid; /* uuid for rid */
653
+
654
+ rid = db_int(0, "SELECT x.rid FROM tag t, tagxref x"
655
+ " WHERE x.tagid=t.tagid AND t.tagname='wiki-%q'"
656
+ " ORDER BY x.mtime DESC LIMIT 1",
657
+ zPageName
658
+ );
659
+ if( ! rid ){
660
+ fossil_fatal("wiki commit NewEntry not yet implemented.");
661
+ }
662
+
663
+
634664
 blob_read_from_channel( &content, in, -1 );
635665
 // ^^^ Reminder: we should allow empty (zero-byte) entries, so don't exit
636666
 // if read returns 0.
637667
 blob_zero(&wiki);
638668
 zDate = db_text(0, "SELECT datetime('now')");
@@ -753,25 +783,16 @@
753783
 for(i=strlen(zBody); i>0 && isspace(zBody[i-1]); i--){}
754784
 printf("%.*s\n", i, zBody);
755785
 return;
756786
 }else
757787
 if( strncmp(g.argv[2],"commit",n)==0 ){
758
- int rid;
759788
 char *zPageName;
760789
 if( g.argc!=4 ){
761790
 usage("commit PAGENAME");
762791
 }
763792
 zPageName = g.argv[3];
764
- rid = db_int(0, "SELECT x.rid FROM tag t, tagxref x"
765
- " WHERE x.tagid=t.tagid AND t.tagname='wiki-%q'"
766
- " ORDER BY x.mtime DESC LIMIT 1",
767
- zPageName
768
- );
769
- if( ! rid ){
770
- fossil_fatal("wiki commit NewEntry not yet implemented.");
771
- }
772
- wiki_cmd_commit( zPageName, rid, stdin );
793
+ wiki_cmd_commit( zPageName, stdin );
773794
 printf("Committed wiki page %s.\n", zPageName);
774795
 }else
775796
 if( strncmp(g.argv[2],"delete",n)==0 ){
776797
 if( g.argc!=5 ){
777798
 usage("delete PAGENAME");
@@ -794,7 +815,7 @@
794815
 goto wiki_cmd_usage;
795816
 }
796817
 return;
797818
798819
 wiki_cmd_usage:
799
- usage("delete|export|commit|list ...");
820
+ usage("export|commit|list ...");
800821
 }
801822
802823
DELETED www/build.html
803824
ADDED www/build.wiki
804825
DELETED www/concepts.html
805826
ADDED www/concepts.wiki
806827
DELETED www/delta_encoder_algorithm.html
807828
ADDED www/delta_encoder_algorithm.wiki
808829
DELETED www/delta_format.html
809830
ADDED www/delta_format.wiki
810831
DELETED www/fileformat.html
811832
ADDED www/fileformat.wiki
812833
DELETED www/index.html
--- src/wiki.c
+++ src/wiki.c
@@ -1,7 +1,8 @@
1 /*
2 ** Copyright (c) 2007 D. Richard Hipp
 
3 **
4 ** This program is free software; you can redistribute it and/or
5 ** modify it under the terms of the GNU General Public
6 ** License version 2 as published by the Free Software Foundation.
7 **
@@ -76,22 +77,42 @@
76 ** WEBPAGE: home
77 ** WEBPAGE: index
78 ** WEBPAGE: not_found
79 */
80 void home_page(void){
81 char *zPageName = db_get("project-name",0);
82 if( zPageName ){
83 login_check_credentials();
84 g.zExtra = zPageName;
85 cgi_set_parameter_nocopy("name", g.zExtra);
86 g.okRdWiki = 1;
87 g.okApndWiki = 0;
88 g.okWrWiki = 0;
89 g.okHistory = 0;
90 wiki_page();
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
91 return;
92 }
 
93 style_header("Home");
94 @ <p>This is a stub home-page for the project.
95 @ To fill in this page, first go to
96 @ <a href="%s(g.zBaseURL)/setup_config">setup/config</a>
97 @ and establish a "Project Name". Then create a
@@ -599,21 +620,16 @@
599 @ </ol>
600 style_footer();
601 }
602
603 /*
604 ** wiki_cmd_commit() is the implementation of "wiki commit ...".
605 **
606 ** As arguments it expects:
607 **
608 ** zPageName = the wiki entry's name.
609 **
610 ** rid = record ID for the zPageName entry. This func SHOULD deduce
611 ** this from zPageName, but the code which calls this func already has
612 ** the rid, so we pass it along here. If it does not match the entry
613 ** for zPageName then Undefined Behaviour.
614 **
615 ** in = input file. The file is read until EOF but is not closed
616 ** by this function (it might be stdin!).
617 **
618 ** Returns 0 on error, non-zero on success.
619 **
@@ -620,19 +636,33 @@
620 ** TODOs:
621 ** - take EITHER zPageName OR rid. We don't need both.
622 ** - make use of the return value. Add more error checking.
623 ** - give the uuid back to the caller so it can be shown
624 ** in the status output. ("committed version XXXXX of page ...")
 
 
625 */
626 int wiki_cmd_commit( char const * zPageName, int rid, FILE * in )
627 {
628 Blob wiki; /* Wiki page content */
629 Blob content; /* read-in content */
630 Blob cksum; /* wiki checksum */
 
631 int nrid; /* not really sure */
632 char * zDate; /* timestamp */
633 char * zUuid; /* uuid for rid */
 
 
 
 
 
 
 
 
 
 
 
634 blob_read_from_channel( &content, in, -1 );
635 // ^^^ Reminder: we should allow empty (zero-byte) entries, so don't exit
636 // if read returns 0.
637 blob_zero(&wiki);
638 zDate = db_text(0, "SELECT datetime('now')");
@@ -753,25 +783,16 @@
753 for(i=strlen(zBody); i>0 && isspace(zBody[i-1]); i--){}
754 printf("%.*s\n", i, zBody);
755 return;
756 }else
757 if( strncmp(g.argv[2],"commit",n)==0 ){
758 int rid;
759 char *zPageName;
760 if( g.argc!=4 ){
761 usage("commit PAGENAME");
762 }
763 zPageName = g.argv[3];
764 rid = db_int(0, "SELECT x.rid FROM tag t, tagxref x"
765 " WHERE x.tagid=t.tagid AND t.tagname='wiki-%q'"
766 " ORDER BY x.mtime DESC LIMIT 1",
767 zPageName
768 );
769 if( ! rid ){
770 fossil_fatal("wiki commit NewEntry not yet implemented.");
771 }
772 wiki_cmd_commit( zPageName, rid, stdin );
773 printf("Committed wiki page %s.\n", zPageName);
774 }else
775 if( strncmp(g.argv[2],"delete",n)==0 ){
776 if( g.argc!=5 ){
777 usage("delete PAGENAME");
@@ -794,7 +815,7 @@
794 goto wiki_cmd_usage;
795 }
796 return;
797
798 wiki_cmd_usage:
799 usage("delete|export|commit|list ...");
800 }
801
802 ELETED www/build.html
803 DDED www/build.wiki
804 ELETED www/concepts.html
805 DDED www/concepts.wiki
806 ELETED www/delta_encoder_algorithm.html
807 DDED www/delta_encoder_algorithm.wiki
808 ELETED www/delta_format.html
809 DDED www/delta_format.wiki
810 ELETED www/fileformat.html
811 DDED www/fileformat.wiki
812 ELETED www/index.html
--- src/wiki.c
+++ src/wiki.c
@@ -1,7 +1,8 @@
1 /*
2 ** Copyright (c) 2007 D. Richard Hipp
3 ** Copyright (c) 2008 Stephan Beal
4 **
5 ** This program is free software; you can redistribute it and/or
6 ** modify it under the terms of the GNU General Public
7 ** License version 2 as published by the Free Software Foundation.
8 **
@@ -76,22 +77,42 @@
77 ** WEBPAGE: home
78 ** WEBPAGE: index
79 ** WEBPAGE: not_found
80 */
81 void home_page(void){
82 char *zHomePage; /* name of home page */
83 char *zProjName; /* name of project */
84 zProjName = db_get("project-name",0);
85 zHomePage = db_get("project-home", zProjName );
86 if( zProjName && zProjName[0] ){
87 /* beware: this code causes cyclic redirects on a 404 because
88 not_found is directed here.
89 */
90 int lenP; /* strncmp() bounder */
91 int lenH; /* length of zProjName */
92 if( zHomePage && ! zHomePage[0] ){
93 zHomePage = zProjName;
94 }
95 lenP = strlen(zProjName);
96 lenH = strlen(zHomePage);
97 if( lenP < lenH ) lenP = lenH;
98 if( (zProjName == zHomePage) || (0==strncmp(zProjName,zHomePage,lenP)) ||
99 (0==strncmp(zHomePage,"home",lenP)/*avoid endless loop*/) ){
100 login_check_credentials();
101 g.zExtra = zHomePage;
102 cgi_set_parameter_nocopy("name", g.zExtra);
103 g.okRdWiki = 1;
104 g.okApndWiki = 0;
105 g.okWrWiki = 0;
106 g.okHistory = 0;
107 wiki_page();
108 }else{
109 cgi_redirect( zHomePage );
110 }
111 return;
112 }
113
114 style_header("Home");
115 @ <p>This is a stub home-page for the project.
116 @ To fill in this page, first go to
117 @ <a href="%s(g.zBaseURL)/setup_config">setup/config</a>
118 @ and establish a "Project Name". Then create a
@@ -599,21 +620,16 @@
620 @ </ol>
621 style_footer();
622 }
623
624 /*
625 ** wiki_cmd_commit() is the implementation of "wiki commit ...".
626 **
627 ** As arguments it expects:
628 **
629 ** zPageName = the wiki entry's name.
630 **
 
 
 
 
 
631 ** in = input file. The file is read until EOF but is not closed
632 ** by this function (it might be stdin!).
633 **
634 ** Returns 0 on error, non-zero on success.
635 **
@@ -620,19 +636,33 @@
636 ** TODOs:
637 ** - take EITHER zPageName OR rid. We don't need both.
638 ** - make use of the return value. Add more error checking.
639 ** - give the uuid back to the caller so it can be shown
640 ** in the status output. ("committed version XXXXX of page ...")
641 ** - return some status telling the user if there were no diffs
642 ** (i.e. no commit). How can we find this out?
643 */
644 int wiki_cmd_commit( char const * zPageName, FILE * in )
645 {
646 Blob wiki; /* Wiki page content */
647 Blob content; /* read-in content */
648 Blob cksum; /* wiki checksum */
649 int rid; /* rid of existing entry. */
650 int nrid; /* not really sure */
651 char * zDate; /* timestamp */
652 char * zUuid; /* uuid for rid */
653
654 rid = db_int(0, "SELECT x.rid FROM tag t, tagxref x"
655 " WHERE x.tagid=t.tagid AND t.tagname='wiki-%q'"
656 " ORDER BY x.mtime DESC LIMIT 1",
657 zPageName
658 );
659 if( ! rid ){
660 fossil_fatal("wiki commit NewEntry not yet implemented.");
661 }
662
663
664 blob_read_from_channel( &content, in, -1 );
665 // ^^^ Reminder: we should allow empty (zero-byte) entries, so don't exit
666 // if read returns 0.
667 blob_zero(&wiki);
668 zDate = db_text(0, "SELECT datetime('now')");
@@ -753,25 +783,16 @@
783 for(i=strlen(zBody); i>0 && isspace(zBody[i-1]); i--){}
784 printf("%.*s\n", i, zBody);
785 return;
786 }else
787 if( strncmp(g.argv[2],"commit",n)==0 ){
 
788 char *zPageName;
789 if( g.argc!=4 ){
790 usage("commit PAGENAME");
791 }
792 zPageName = g.argv[3];
793 wiki_cmd_commit( zPageName, stdin );
 
 
 
 
 
 
 
 
794 printf("Committed wiki page %s.\n", zPageName);
795 }else
796 if( strncmp(g.argv[2],"delete",n)==0 ){
797 if( g.argc!=5 ){
798 usage("delete PAGENAME");
@@ -794,7 +815,7 @@
815 goto wiki_cmd_usage;
816 }
817 return;
818
819 wiki_cmd_usage:
820 usage("export|commit|list ...");
821 }
822
823 ELETED www/build.html
824 DDED www/build.wiki
825 ELETED www/concepts.html
826 DDED www/concepts.wiki
827 ELETED www/delta_encoder_algorithm.html
828 DDED www/delta_encoder_algorithm.wiki
829 ELETED www/delta_format.html
830 DDED www/delta_format.wiki
831 ELETED www/fileformat.html
832 DDED www/fileformat.wiki
833 ELETED www/index.html
D www/build.html
-82
--- a/www/build.html
+++ b/www/build.html
@@ -1,82 +0,0 @@
1
-<html>
2
-<title>Building And Installing Fossil</title>
3
-</head>
4
-<body bgcolor="white">
5
-<p>[ <a href="index.html">Index</a> ]</p>
6
-<hr>
7
-<h1>Installing Fossil</h1>
8
-
9
-<p>This page describes how to build and install Fossil. The
10
-whole process is designed to be very easy.</p>
11
-
12
-<h2>0.0 Using A Precompiled Binary</h2>
13
-
14
-<p>You can skip steps 1.0 and 2.0 below by downloading
15
-a <a href="http://www.fossil-scm.org/download.html">precompiled binary</a>
16
-appropriate for your platform. If you use a precompiled binary
17
-jump immediate to step 3.0.</p>
18
-
19
-<h2>1.0 Obtaining The Source Code</h2>
20
-
21
-<p>Fossil is self-hosting, so you can obtain a ZIP archive containing
22
-a snapshot of the latest version directly from fossil's own fossil
23
-repository. Follow these steps:</p>
24
-
25
-<ol>
26
-<li><p>Pointer your webbrowser at
27
-<a href="http://www.fossil-scm.org/fossil/login">
28
-http://www.fossil-scm.org/fossil/login</a>.</p></li>
29
-
30
-<li><p>Log in as anonymous. The password is shown on screen.
31
-The reason for requiring this login is to prevent spiders from
32
-walking the entire website, downloading ZIP archives
33
-of every historical version, and thereby soaking up all our bandwidth.</p></li>
34
-
35
-<li><p>Click on the
36
-<a href="http://www.fossil-scm.org/fossil/timeline">Timeline</a> or
37
-<a href="http://www.fossil-scm.org/fossil/leaves">Leaves</a> link at
38
-the top of the page.</p></li>
39
-
40
-<li><p>Select a version of of fossil you want to download. Click on its
41
-link. Note that you must successfully log in as "anonymous" in step 1
42
-above in order to see the link to the detailed version information.</p></li>
43
-
44
-<li><p>On the version information page, click on the
45
-"Zip Archive" link. This link will build a ZIP archive of the
46
-complete source code and download it to your browser.</p></li>
47
-</ol>
48
-
49
-<h2>2.0 Compiling</h2>
50
-
51
-<p>Follow these steps to compile:</p>
52
-
53
-<ol>
54
-<li value="6">
55
-<p>Create a directory to hold the source code. Then unzip the
56
-ZIP archive you downloaded into that directory. You should be
57
-in the top-level folder of that directory</p></li>
58
-
59
-<li><p><b>(Optional:)</b>
60
-Edit the Makefile to set it up like you want. You probably do not
61
-need to do anything. Do not be intimidated: There are only 5
62
-variables in the makefile that can be changed. The whole Makefile
63
-is only a few dozen lines long and most of those lines are comments.</p>
64
-
65
-<li><p>Type "<b>make</b>"
66
-</ol>
67
-
68
-<h2>3.0 Installing</h2>
69
-
70
-<ol>
71
-<li value="9">
72
-<p>The finished binary is named "fossil". Put this binary in a
73
-directory that is somewhere on your PATH environment variable.
74
-It does not matter where.</p>
75
-
76
-<li>
77
-<p><b>(Optional:)</b>
78
-To uninstall, just delete the binary.</p>
79
-</ol>
80
-
81
-</body>
82
-</html>
--- a/www/build.html
+++ b/www/build.html
@@ -1,82 +0,0 @@
1 <html>
2 <title>Building And Installing Fossil</title>
3 </head>
4 <body bgcolor="white">
5 <p>[ <a href="index.html">Index</a> ]</p>
6 <hr>
7 <h1>Installing Fossil</h1>
8
9 <p>This page describes how to build and install Fossil. The
10 whole process is designed to be very easy.</p>
11
12 <h2>0.0 Using A Precompiled Binary</h2>
13
14 <p>You can skip steps 1.0 and 2.0 below by downloading
15 a <a href="http://www.fossil-scm.org/download.html">precompiled binary</a>
16 appropriate for your platform. If you use a precompiled binary
17 jump immediate to step 3.0.</p>
18
19 <h2>1.0 Obtaining The Source Code</h2>
20
21 <p>Fossil is self-hosting, so you can obtain a ZIP archive containing
22 a snapshot of the latest version directly from fossil's own fossil
23 repository. Follow these steps:</p>
24
25 <ol>
26 <li><p>Pointer your webbrowser at
27 <a href="http://www.fossil-scm.org/fossil/login">
28 http://www.fossil-scm.org/fossil/login</a>.</p></li>
29
30 <li><p>Log in as anonymous. The password is shown on screen.
31 The reason for requiring this login is to prevent spiders from
32 walking the entire website, downloading ZIP archives
33 of every historical version, and thereby soaking up all our bandwidth.</p></li>
34
35 <li><p>Click on the
36 <a href="http://www.fossil-scm.org/fossil/timeline">Timeline</a> or
37 <a href="http://www.fossil-scm.org/fossil/leaves">Leaves</a> link at
38 the top of the page.</p></li>
39
40 <li><p>Select a version of of fossil you want to download. Click on its
41 link. Note that you must successfully log in as "anonymous" in step 1
42 above in order to see the link to the detailed version information.</p></li>
43
44 <li><p>On the version information page, click on the
45 "Zip Archive" link. This link will build a ZIP archive of the
46 complete source code and download it to your browser.</p></li>
47 </ol>
48
49 <h2>2.0 Compiling</h2>
50
51 <p>Follow these steps to compile:</p>
52
53 <ol>
54 <li value="6">
55 <p>Create a directory to hold the source code. Then unzip the
56 ZIP archive you downloaded into that directory. You should be
57 in the top-level folder of that directory</p></li>
58
59 <li><p><b>(Optional:)</b>
60 Edit the Makefile to set it up like you want. You probably do not
61 need to do anything. Do not be intimidated: There are only 5
62 variables in the makefile that can be changed. The whole Makefile
63 is only a few dozen lines long and most of those lines are comments.</p>
64
65 <li><p>Type "<b>make</b>"
66 </ol>
67
68 <h2>3.0 Installing</h2>
69
70 <ol>
71 <li value="9">
72 <p>The finished binary is named "fossil". Put this binary in a
73 directory that is somewhere on your PATH environment variable.
74 It does not matter where.</p>
75
76 <li>
77 <p><b>(Optional:)</b>
78 To uninstall, just delete the binary.</p>
79 </ol>
80
81 </body>
82 </html>
--- a/www/build.html
+++ b/www/build.html
@@ -1,82 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/build.wiki
+15
--- a/www/build.wiki
+++ b/www/build.wiki
@@ -0,0 +1,15 @@
1
+ssil Documentation</title>
2
+<nowiki>
3
+<h1>Installing Fossil</h1<title>Fossil Documentation</title>
4
+<nowiki>
5
+<h1>Installing Fossil</1</p></li<title>Fossil Documentation</title>
6
+<nowiki>
7
+<h1>Installing Fossil</h1<title>Fossil Documentation</title>
8
+<nowiki>
9
+<h1>Instlling Fossil</h1tion</tiFIXMEtitle>
10
+<nowiki>
11
+<h11tion</title>
12
+<nowiki>
13
+<h1>Installing Fossil</h1<titl>Fossil Documentation</title>
14
+<nowiki>
15
+<h1>Installing Fossil</h1fossil/loginfossil/login</a>
--- a/www/build.wiki
+++ b/www/build.wiki
@@ -0,0 +1,15 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--- a/www/build.wiki
+++ b/www/build.wiki
@@ -0,0 +1,15 @@
1 ssil Documentation</title>
2 <nowiki>
3 <h1>Installing Fossil</h1<title>Fossil Documentation</title>
4 <nowiki>
5 <h1>Installing Fossil</1</p></li<title>Fossil Documentation</title>
6 <nowiki>
7 <h1>Installing Fossil</h1<title>Fossil Documentation</title>
8 <nowiki>
9 <h1>Instlling Fossil</h1tion</tiFIXMEtitle>
10 <nowiki>
11 <h11tion</title>
12 <nowiki>
13 <h1>Installing Fossil</h1<titl>Fossil Documentation</title>
14 <nowiki>
15 <h1>Installing Fossil</h1fossil/loginfossil/login</a>
D www/concepts.html
-378
--- a/www/concepts.html
+++ b/www/concepts.html
@@ -1,378 +0,0 @@
1
-<html>
2
-<head>
3
-<title>Fossil Concepts</title>
4
-</head>
5
-<body bgcolor="white">
6
-<p>[ <a href="index.html">Index</a> ]</p>
7
-<hr>
8
-<h1 align="center">
9
-Fossil Concepts
10
-</h1>
11
-
12
-<h2>1.0 Introduction</h2>
13
-<p>
14
-<a href="index.html">Fossil</a> is a
15
-<a href="http://en.wikipedia.org/wiki/Software_configuration_management">
16
-software configuration management</a> system.
17
-Fossil is software that is designed to control and track the
18
-development of a software project and to record the history
19
-of the project.
20
-There are many such systems in use today. Fossil strives to
21
-distinguish itself from the others by being extremely simple
22
-to setup and operate.</p>
23
-
24
-<p>This document is intended as a quick introduction to the concepts
25
-behind fossil.</p>
26
-
27
-<h2>2.0 Composition Of A Project</h2>
28
-<img src="concept1.gif" align="right" hspace="10">
29
-
30
-<p>A software project normally consists of a "source tree".
31
-A source tree is a hierarchy of files that are used to generate
32
-the end product. The source tree changes over time as the
33
-software grows and expands and as features are added and bugs
34
-are fixed. A snapshot of the source tree at any point in time
35
-is called a "version" or "revision" or a "baseline" of the product.
36
-In fossil, we use the name "baseline".</p>
37
-
38
-<p>A "repository" is a database that contains copies of all historical
39
-versions or baselines for a project. Baselines are normally stored in the
40
-repository in a highly space-efficient compressed format (delta encoding).
41
-But that is an implementation detail that you the user need not worry over.
42
-Think of the repository as a safe place where all your old baselines are
43
-securely stored away and available for retrieval whenever you need
44
-them.</p>
45
-
46
-<p>A repository in fossil is a single file on your disk. This file
47
-might be rather large (dozens or hundreds of megabytes for a large
48
-or long running project) but it is nevertheless just a file. You
49
-can move it around, rename it, write it out to a memory stick, or
50
-do anything else you normally do with files.</p>
51
-
52
-<p>Each source tree that is controlled by fossil is associated with
53
-a single repository on the local disk drive. You can tie two or more
54
-source trees to a single repository if you want (though one
55
-tree per repository is the most common configuration.) So a
56
-single repository can be associated with many source trees, but
57
-each source tree is associated with only one repository.</p>
58
-
59
-<p>Fossil source trees may not overlap. A fossil source tree is identified
60
-by a file named "_FOSSIL_" in the root directory of the source tree. Every
61
-file that is a sibling of _FOSSIL_ and every file in every subfolder is
62
-considered potentially a part of the source tree. The _FOSSIL_ file
63
-contains (among other things) the pathname of the repository with which
64
-the source tree is associated. On the other hand, the repository has
65
-no record of its source trees. So you are free to delete a source tree
66
-or move it around without consequence. But if you move or rename or
67
-delete a repository, then any source trees associated with that repository
68
-will no longer be able to locate their repository and will stop working.</p>
69
-
70
-<p>When multiple developers are working on the same project, each
71
-developer typically has his or her own local repository and an associated
72
-source tree in which to work. Developers share their work by
73
-"syncing" the content of their local repositories either directly
74
-or through a central server. Changes can "push" from the local
75
-repository into a remote repository. Or changes can "pull" from a
76
-remote repository into a local repository. Or one can do a "sync"
77
-which is a shortcut for doing both a push and a pull at the same time.
78
-Fossil also has the concept of "cloning". A "clone" is like a "pull",
79
-except that instead of beginning with an existing local repository,
80
-a clone begins with nothing and creates a new local repository that
81
-is a duplicate of a remote repository.</p>
82
-
83
-<p>Communication between repositories is via HTTP. Remote
84
-repositories are identified by URL. You can also point a webbrowser
85
-at a repository and get human-readable status, history, and tracking
86
-information about the project.</p>
87
-
88
-<h3>2.1 Identification Of Artifacts</h3>
89
-
90
-<p>A particular version of a particular file is called an "artifact".
91
-Each artifact has a universally unique name which is the
92
-<a href="http://en.wikipedia.org/wiki/SHA">SHA1</a> hash of the content
93
-of that file expressed as 40 characters of lower-case hexadecimal. Such
94
-a hash is referred to as the Universally Unique Identifier or UUID
95
-for the artifact. The SHA1 algorithm is created with the purpose of
96
-providing a highly forgery-resistent identifier for a file. Given any
97
-file it is simple to find the UUID for that file. But given a
98
-UUID it is computationally intractable to generate a file that will
99
-have that UUID.</p>
100
-
101
-
102
-<p>UUIDs look something like this:</p>
103
-
104
-<blockquote><b>
105
-6089f0b563a9db0a6d90682fe47fd7161ff867c8<br>
106
-59712614a1b3ccfd84078a37fa5b606e28434326<br>
107
-19dbf73078be9779edd6a0156195e610f81c94f9<br>
108
-b4104959a67175f02d6b415480be22a239f1f077<br>
109
-997c9d6ae03ad114b2b57f04e9eeef17dcb82788
110
-</b></blockquote>
111
-
112
-<p>When referring to an artifact using fossil, you can use a unique
113
-prefix of the UUID that is four characters or longer. This saves
114
-a lot of typing. When displaying UUIDs, fossil will usually only
115
-show the first 10 digits since that is normally enough to uniquely
116
-identify a file.</p>
117
-
118
-<p>Changing (or adding or removing) a single byte in a file results
119
-in a completely different UUID. And since the UUID is the name of
120
-the artifact, making any change to a file results in a new artifact.
121
-In this way, artifacts are immutable.</p>
122
-
123
-<p>A repository is really just an unordered collection of
124
-artifacts. New artifacts can be added to the repository, but
125
-existing artifacts can never be removed. Fossil is designed in
126
-such a way that it can be handed a set of artifacts in any
127
-order and it can figure out the relationship between those
128
-artifacts and reconstruct the complete development history of
129
-a software project.</p>
130
-
131
-<h3>2.2 Manifests</h3>
132
-
133
-<p>At the root of a source tree is a special file called the
134
-"manifest". The manifest is a listing of all other files in
135
-that source tree. The manifest contains the (complete) UUID
136
-of the file and the name of the file as it appears on disk,
137
-and thus serves as a mapping from UUID to disk name. The UUID
138
-of the manifest is the UUID that identifies a baseline. When
139
-you look at a "timeline" of changes in fossil, the UUID associated
140
-with each check-in or commit is really just the UUID of the
141
-manifest for that baseline.</p>
142
-
143
-<p>Fossil automatically generates a manifest whenever you "commit"
144
-a new baseline. So this is not something that you, the developer,
145
-need to worry with. The format of a manifest is intentionally
146
-designed to be simple to parse, so that if
147
-you want to read and interpret a manifest, either by hand or
148
-with a script, that is easy to do. But you will probably never
149
-need to do so.</p>
150
-
151
-<p>In addition to identifying all files in the baseline, a
152
-manifest also contains a check-in comment, the date and time
153
-when the baseline was established, who created the baseline,
154
-and links to other baselines from which the current baseline
155
-is derived. There is also a couple of checksums used to verify
156
-the integrity of the baseline. And the whole manifest might
157
-be PGP clearsigned.</p>
158
-
159
-<h3>2.3 Key concepts</h3>
160
-
161
-<ul>
162
-<li>A <b>baseline</b> is a set of files arranged
163
- in a hierarchy.</li>
164
-<li>A <b>repository</b> keeps a record of historical baselines.</li>
165
-<li>Repositories share their changes using <b>push</b>, <b>pull</b>,
166
- <b>sync</b>, and <b>clone</b>.</li>
167
-<li>A particular version of a particular file is an <b>artifact</b>
168
- that is identified by a <b>UUID</b>.</li>
169
-<li>Artifacts tracked by fossil are inherently immutable.</li>
170
-<li>Fossil automatically generates a <b>manifest</b> file that identifies
171
- every artifact in a baseline.</li>
172
-<li>The UUID of the manifest is the UUID of the baseline.</li>
173
-</ul>
174
-
175
-<h2>3.0 Fossil - The Program</h2>
176
-
177
-<p>Fossil is software. The implementation of fossil is in the form
178
-of a single executable named "fossil". To install fossil on your system,
179
-all you have to do is obtain a copy of this one executable file (either
180
-by downloading a precompiled version or compiling it yourself) and then
181
-putting that file somewhere on your PATH.</p>
182
-
183
-<p>Fossil is completely self-contained. It is not necessary to
184
-install any other software in order to use fossil. You do <u>not</u> need
185
-CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL,
186
-SQLite, patch, or any similar software on your system in order to use
187
-fossil effectively. You will want to have some kind of text editor
188
-for entering check-in comments. Fossil will use whatever text editor
189
-is identified by your VISUAL environment variable. Fossil will also
190
-use GPG to clearsign your manifests if you happen to have it installed,
191
-but fossil will skip that step if GPG missing from your system.
192
-You can optionally set up fossil to use external "diff" programs,
193
-though a perfectly functional "diff" algorithm is built it and works
194
-find for most people.</p>
195
-
196
-<p>To uninstall fossil, simply delete the executable.</p>
197
-
198
-<p>To upgrade an older version of fossil to a newer version, just
199
-replace the old executable with the new one. You might need to
200
-run a one-time command to restructure your repositories after
201
-an upgrade. Check the instructions that come with the upgrade
202
-for details.</p>
203
-
204
-<p>To use fossil, simply type the name of executable in your
205
-shell, followed by one of the various built-in commands and
206
-arguments appropriate for that command. For example:</p>
207
-
208
-<blockquote><b>
209
-fossil help
210
-</b></blockquote>
211
-
212
-<p>In the next section, when we say things like "use the <b>help</b>
213
-command" we mean to use the command name "help" as the first
214
-token after the name of the fossil executable, as shown above.</p>
215
-
216
-<h2>4.0 Workflow</h2>
217
-
218
-<img src="concept2.gif" align="right" hspace="10">
219
-<ol>
220
-<li><p>
221
-Establish a local repository using either the <b>new</b> command
222
-to start a new project, or the <b>clone</b> command to make a clone
223
-of a repository for an existing project.
224
-</p></li>
225
-
226
-<li><p>
227
-Establish one or more source trees by changing your working directory
228
-to where you want the root of the source tree to be, then issuing
229
-the <b>open</b> command with the name of the repository file as its
230
-argument.
231
-</p></li>
232
-
233
-<li><p>
234
-Use the <b>update</b> command followed by a UUID to cause your
235
-source tree to change to the baseline identified by that UUID.
236
-The <b>timeline</b> or <b>leaves</b> commands might help you to
237
-identify an appropriate baseline.
238
-</p></li>
239
-
240
-<li><p>
241
-Edit the code. Add new files to the source tree using the <b>add</b>
242
-command. Omit files from future baselines using the <b>rm</b> command.
243
-(Even when you remove files from future baselines, those files continue
244
-to exist in historical baselines.) Test your changes.
245
-</p></li>
246
-
247
-<li><p>
248
-Create a new baseline using the <b>commit</b> command. You will be prompted
249
-for a check-in comment and also for your GPG key if you have GPG installed.
250
-The commit copies the edits you have made in your local source
251
-tree into your local repository.
252
-</p></li>
253
-
254
-<li><p>
255
-Share your changes with others using the <b>push</b> command.
256
-Push causes the edits you committed into your local repository to be
257
-pushed out into other repositories.
258
-</p></li>
259
-
260
-<li><p>
261
-When your coworkers make their own changes, you can pull those changes
262
-into your local repository using the <b>pull</b> command. Note that
263
-the pull command only pulls the changes into your local repository,
264
-not into your local source tree.
265
-</p></li>
266
-
267
-<li><p>
268
-After the changes of others are in your local repository, you
269
-can move them into your local source tree using <b>update</b>. If
270
-you have made parallel
271
-changes, you can merge your changes together with your coworkers changes
272
-by do an <b>update</b> to your latest baseline, then doing a
273
-<b>merge</b> with your coworkers latest baseline. After your
274
-verify that the merged code is still functional, you can <b>commit</b>
275
-a new baseline that contains both yours and your coworkers changes
276
-and then push the new baseline back to your coworker.
277
-</p></li>
278
-
279
-<li><p>
280
-Repeat all of the above until you have generated great software.
281
-</p></li>
282
-</ol>
283
-
284
-<h3>4.1 Variations</h3>
285
-
286
-<p>The <b>settings</b> lets you view and modify various operating
287
-properties of fossil. Among the available settings is "autosync"
288
-mode. When autosync is enabled, the push and pull of content from
289
-your local server is largely automated. Whenever you use the <b>update</b>
290
-command, fossil first does a <b>pull</b> to see if other users have
291
-perhaps added new baselines to the central repository. When you
292
-<b>commit</b>, fossil also does a <b>pull</b> and issues a warning
293
-if your check-in would cause a fork. After a <b>commit</b>, fossil
294
-automatically does a <b>push</b> to send your changes up to the
295
-central server.</p>
296
-
297
-<p>With autosync enabled, fossil works like
298
-<a href="http://www.nongnu.org/cvs/">CVS</a> or
299
-<a href="http://subversion.tigris.org/">Subversion</a>.
300
-When autosync disabled, fossil works more like
301
-<a href="http://monotone.ca/">Monotone</a>,
302
-<a href="http://git.or.cz">GIT</a>, or
303
-<a href="http://www.selenic.com/mercurial/wiki/">Mercurial</a>.
304
-The fun thing about fossil is that it will work either
305
-way, depending on your needs of the moment. You can freely switch
306
-between these operating modes using commands like:</p>
307
-
308
-<blockquote>
309
-<b>fossil setting autosync off<br />
310
-fossil setting autosync on</b>
311
-</blockquote>
312
-
313
-<p>For additional information about autosync and other settings
314
-using the <b>help</b> command.</p>
315
-
316
-<h2>5.0 Setting Up A Fossil Server</h2>
317
-
318
-<p>With other configuration management software, setting up a server is
319
-a lot of work and normally takes time, patience, and a lot of system
320
-knowledge. Fossil is designed to avoid this frustration. Setting up
321
-a server with fossil is ridiculously easy. You have three options:</p>
322
-
323
-<ol>
324
-<li><p><b>Setting up a stand-alone server</b></p>
325
-
326
-<p>From within your source tree just use the <b>server</b> command and
327
-fossil will start listening for incoming requests on TCP port 8080.
328
-You can point your webbrowser at <a href="http://localhost:8080/">
329
-http://localhost:8080/</a> and begin exploring. Or your coworkers
330
-can do pushes or pulls against your server. Use the <b>--port</b>
331
-option to the server command to specify a different TCP port. If
332
-you do not have a local source tree, use the <b>-R</b> command-line
333
-option to specify the repository file.</p>
334
-
335
-<p>A stand-alone server is a great way to set of transient connections
336
-between coworkers for doing quick pushes or pulls. But you can also
337
-set up a permanent stand-alone server if you prefer. Just make
338
-arrangements for fossil to be launched with appropriate arguments
339
-after every reboot.</p>
340
-</li>
341
-
342
-<li><p><b>Setting up a CGI server</b></p>
343
-
344
-<p>If you have a webserver running on your machine already, you can
345
-set up fossil to be run from CGI. Simply create an executable script
346
-that looks something like this:</p>
347
-
348
-<blockquote><pre>
349
-#!/usr/local/bin/fossil
350
-repository: /home/me/bigproject.fossil
351
-</pre></blockquote>
352
-
353
-<p>Edit this script to use whatever pathnames are appropriate for
354
-your project. Then point your webbrowser at the script and off you
355
-go.</p></li>
356
-
357
-<li><p><b>Setting up an inetd server</b></p>
358
-
359
-<p>If you have inetd or xinetd running on your system, you can set
360
-those services up to launch fossil to deal with inbound TCP/IP connections
361
-on whatever port you want. Set up inetd or xinetd to launch fossil
362
-like this:</p>
363
-
364
-<blockquote><pre>
365
-/usr/local/bin/fossil http /home/me/bigproject.fossil
366
-</pre></blockquote>
367
-
368
-<p>As before, change the filenames to whatever is appropriate for
369
-your system. You can have fossil run as any user that has write
370
-permission on the repository and on the directory that contains the
371
-repository. But it is safer to run fossil as root. When fossil
372
-sees that it is running as root, it automatically puts itself into
373
-a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> and
374
-drops all privileges prior to reading any information from the client.
375
-Since fossil is a stand-alone program, you do not need to put anything
376
-in the chroot jail with fossil in order for it to do its job.</p>
377
-</li>
378
-</ol>
--- a/www/concepts.html
+++ b/www/concepts.html
@@ -1,378 +0,0 @@
1 <html>
2 <head>
3 <title>Fossil Concepts</title>
4 </head>
5 <body bgcolor="white">
6 <p>[ <a href="index.html">Index</a> ]</p>
7 <hr>
8 <h1 align="center">
9 Fossil Concepts
10 </h1>
11
12 <h2>1.0 Introduction</h2>
13 <p>
14 <a href="index.html">Fossil</a> is a
15 <a href="http://en.wikipedia.org/wiki/Software_configuration_management">
16 software configuration management</a> system.
17 Fossil is software that is designed to control and track the
18 development of a software project and to record the history
19 of the project.
20 There are many such systems in use today. Fossil strives to
21 distinguish itself from the others by being extremely simple
22 to setup and operate.</p>
23
24 <p>This document is intended as a quick introduction to the concepts
25 behind fossil.</p>
26
27 <h2>2.0 Composition Of A Project</h2>
28 <img src="concept1.gif" align="right" hspace="10">
29
30 <p>A software project normally consists of a "source tree".
31 A source tree is a hierarchy of files that are used to generate
32 the end product. The source tree changes over time as the
33 software grows and expands and as features are added and bugs
34 are fixed. A snapshot of the source tree at any point in time
35 is called a "version" or "revision" or a "baseline" of the product.
36 In fossil, we use the name "baseline".</p>
37
38 <p>A "repository" is a database that contains copies of all historical
39 versions or baselines for a project. Baselines are normally stored in the
40 repository in a highly space-efficient compressed format (delta encoding).
41 But that is an implementation detail that you the user need not worry over.
42 Think of the repository as a safe place where all your old baselines are
43 securely stored away and available for retrieval whenever you need
44 them.</p>
45
46 <p>A repository in fossil is a single file on your disk. This file
47 might be rather large (dozens or hundreds of megabytes for a large
48 or long running project) but it is nevertheless just a file. You
49 can move it around, rename it, write it out to a memory stick, or
50 do anything else you normally do with files.</p>
51
52 <p>Each source tree that is controlled by fossil is associated with
53 a single repository on the local disk drive. You can tie two or more
54 source trees to a single repository if you want (though one
55 tree per repository is the most common configuration.) So a
56 single repository can be associated with many source trees, but
57 each source tree is associated with only one repository.</p>
58
59 <p>Fossil source trees may not overlap. A fossil source tree is identified
60 by a file named "_FOSSIL_" in the root directory of the source tree. Every
61 file that is a sibling of _FOSSIL_ and every file in every subfolder is
62 considered potentially a part of the source tree. The _FOSSIL_ file
63 contains (among other things) the pathname of the repository with which
64 the source tree is associated. On the other hand, the repository has
65 no record of its source trees. So you are free to delete a source tree
66 or move it around without consequence. But if you move or rename or
67 delete a repository, then any source trees associated with that repository
68 will no longer be able to locate their repository and will stop working.</p>
69
70 <p>When multiple developers are working on the same project, each
71 developer typically has his or her own local repository and an associated
72 source tree in which to work. Developers share their work by
73 "syncing" the content of their local repositories either directly
74 or through a central server. Changes can "push" from the local
75 repository into a remote repository. Or changes can "pull" from a
76 remote repository into a local repository. Or one can do a "sync"
77 which is a shortcut for doing both a push and a pull at the same time.
78 Fossil also has the concept of "cloning". A "clone" is like a "pull",
79 except that instead of beginning with an existing local repository,
80 a clone begins with nothing and creates a new local repository that
81 is a duplicate of a remote repository.</p>
82
83 <p>Communication between repositories is via HTTP. Remote
84 repositories are identified by URL. You can also point a webbrowser
85 at a repository and get human-readable status, history, and tracking
86 information about the project.</p>
87
88 <h3>2.1 Identification Of Artifacts</h3>
89
90 <p>A particular version of a particular file is called an "artifact".
91 Each artifact has a universally unique name which is the
92 <a href="http://en.wikipedia.org/wiki/SHA">SHA1</a> hash of the content
93 of that file expressed as 40 characters of lower-case hexadecimal. Such
94 a hash is referred to as the Universally Unique Identifier or UUID
95 for the artifact. The SHA1 algorithm is created with the purpose of
96 providing a highly forgery-resistent identifier for a file. Given any
97 file it is simple to find the UUID for that file. But given a
98 UUID it is computationally intractable to generate a file that will
99 have that UUID.</p>
100
101
102 <p>UUIDs look something like this:</p>
103
104 <blockquote><b>
105 6089f0b563a9db0a6d90682fe47fd7161ff867c8<br>
106 59712614a1b3ccfd84078a37fa5b606e28434326<br>
107 19dbf73078be9779edd6a0156195e610f81c94f9<br>
108 b4104959a67175f02d6b415480be22a239f1f077<br>
109 997c9d6ae03ad114b2b57f04e9eeef17dcb82788
110 </b></blockquote>
111
112 <p>When referring to an artifact using fossil, you can use a unique
113 prefix of the UUID that is four characters or longer. This saves
114 a lot of typing. When displaying UUIDs, fossil will usually only
115 show the first 10 digits since that is normally enough to uniquely
116 identify a file.</p>
117
118 <p>Changing (or adding or removing) a single byte in a file results
119 in a completely different UUID. And since the UUID is the name of
120 the artifact, making any change to a file results in a new artifact.
121 In this way, artifacts are immutable.</p>
122
123 <p>A repository is really just an unordered collection of
124 artifacts. New artifacts can be added to the repository, but
125 existing artifacts can never be removed. Fossil is designed in
126 such a way that it can be handed a set of artifacts in any
127 order and it can figure out the relationship between those
128 artifacts and reconstruct the complete development history of
129 a software project.</p>
130
131 <h3>2.2 Manifests</h3>
132
133 <p>At the root of a source tree is a special file called the
134 "manifest". The manifest is a listing of all other files in
135 that source tree. The manifest contains the (complete) UUID
136 of the file and the name of the file as it appears on disk,
137 and thus serves as a mapping from UUID to disk name. The UUID
138 of the manifest is the UUID that identifies a baseline. When
139 you look at a "timeline" of changes in fossil, the UUID associated
140 with each check-in or commit is really just the UUID of the
141 manifest for that baseline.</p>
142
143 <p>Fossil automatically generates a manifest whenever you "commit"
144 a new baseline. So this is not something that you, the developer,
145 need to worry with. The format of a manifest is intentionally
146 designed to be simple to parse, so that if
147 you want to read and interpret a manifest, either by hand or
148 with a script, that is easy to do. But you will probably never
149 need to do so.</p>
150
151 <p>In addition to identifying all files in the baseline, a
152 manifest also contains a check-in comment, the date and time
153 when the baseline was established, who created the baseline,
154 and links to other baselines from which the current baseline
155 is derived. There is also a couple of checksums used to verify
156 the integrity of the baseline. And the whole manifest might
157 be PGP clearsigned.</p>
158
159 <h3>2.3 Key concepts</h3>
160
161 <ul>
162 <li>A <b>baseline</b> is a set of files arranged
163 in a hierarchy.</li>
164 <li>A <b>repository</b> keeps a record of historical baselines.</li>
165 <li>Repositories share their changes using <b>push</b>, <b>pull</b>,
166 <b>sync</b>, and <b>clone</b>.</li>
167 <li>A particular version of a particular file is an <b>artifact</b>
168 that is identified by a <b>UUID</b>.</li>
169 <li>Artifacts tracked by fossil are inherently immutable.</li>
170 <li>Fossil automatically generates a <b>manifest</b> file that identifies
171 every artifact in a baseline.</li>
172 <li>The UUID of the manifest is the UUID of the baseline.</li>
173 </ul>
174
175 <h2>3.0 Fossil - The Program</h2>
176
177 <p>Fossil is software. The implementation of fossil is in the form
178 of a single executable named "fossil". To install fossil on your system,
179 all you have to do is obtain a copy of this one executable file (either
180 by downloading a precompiled version or compiling it yourself) and then
181 putting that file somewhere on your PATH.</p>
182
183 <p>Fossil is completely self-contained. It is not necessary to
184 install any other software in order to use fossil. You do <u>not</u> need
185 CVS, gzip, diff, rsync, Python, Perl, Tcl, Java, apache, PostgreSQL, MySQL,
186 SQLite, patch, or any similar software on your system in order to use
187 fossil effectively. You will want to have some kind of text editor
188 for entering check-in comments. Fossil will use whatever text editor
189 is identified by your VISUAL environment variable. Fossil will also
190 use GPG to clearsign your manifests if you happen to have it installed,
191 but fossil will skip that step if GPG missing from your system.
192 You can optionally set up fossil to use external "diff" programs,
193 though a perfectly functional "diff" algorithm is built it and works
194 find for most people.</p>
195
196 <p>To uninstall fossil, simply delete the executable.</p>
197
198 <p>To upgrade an older version of fossil to a newer version, just
199 replace the old executable with the new one. You might need to
200 run a one-time command to restructure your repositories after
201 an upgrade. Check the instructions that come with the upgrade
202 for details.</p>
203
204 <p>To use fossil, simply type the name of executable in your
205 shell, followed by one of the various built-in commands and
206 arguments appropriate for that command. For example:</p>
207
208 <blockquote><b>
209 fossil help
210 </b></blockquote>
211
212 <p>In the next section, when we say things like "use the <b>help</b>
213 command" we mean to use the command name "help" as the first
214 token after the name of the fossil executable, as shown above.</p>
215
216 <h2>4.0 Workflow</h2>
217
218 <img src="concept2.gif" align="right" hspace="10">
219 <ol>
220 <li><p>
221 Establish a local repository using either the <b>new</b> command
222 to start a new project, or the <b>clone</b> command to make a clone
223 of a repository for an existing project.
224 </p></li>
225
226 <li><p>
227 Establish one or more source trees by changing your working directory
228 to where you want the root of the source tree to be, then issuing
229 the <b>open</b> command with the name of the repository file as its
230 argument.
231 </p></li>
232
233 <li><p>
234 Use the <b>update</b> command followed by a UUID to cause your
235 source tree to change to the baseline identified by that UUID.
236 The <b>timeline</b> or <b>leaves</b> commands might help you to
237 identify an appropriate baseline.
238 </p></li>
239
240 <li><p>
241 Edit the code. Add new files to the source tree using the <b>add</b>
242 command. Omit files from future baselines using the <b>rm</b> command.
243 (Even when you remove files from future baselines, those files continue
244 to exist in historical baselines.) Test your changes.
245 </p></li>
246
247 <li><p>
248 Create a new baseline using the <b>commit</b> command. You will be prompted
249 for a check-in comment and also for your GPG key if you have GPG installed.
250 The commit copies the edits you have made in your local source
251 tree into your local repository.
252 </p></li>
253
254 <li><p>
255 Share your changes with others using the <b>push</b> command.
256 Push causes the edits you committed into your local repository to be
257 pushed out into other repositories.
258 </p></li>
259
260 <li><p>
261 When your coworkers make their own changes, you can pull those changes
262 into your local repository using the <b>pull</b> command. Note that
263 the pull command only pulls the changes into your local repository,
264 not into your local source tree.
265 </p></li>
266
267 <li><p>
268 After the changes of others are in your local repository, you
269 can move them into your local source tree using <b>update</b>. If
270 you have made parallel
271 changes, you can merge your changes together with your coworkers changes
272 by do an <b>update</b> to your latest baseline, then doing a
273 <b>merge</b> with your coworkers latest baseline. After your
274 verify that the merged code is still functional, you can <b>commit</b>
275 a new baseline that contains both yours and your coworkers changes
276 and then push the new baseline back to your coworker.
277 </p></li>
278
279 <li><p>
280 Repeat all of the above until you have generated great software.
281 </p></li>
282 </ol>
283
284 <h3>4.1 Variations</h3>
285
286 <p>The <b>settings</b> lets you view and modify various operating
287 properties of fossil. Among the available settings is "autosync"
288 mode. When autosync is enabled, the push and pull of content from
289 your local server is largely automated. Whenever you use the <b>update</b>
290 command, fossil first does a <b>pull</b> to see if other users have
291 perhaps added new baselines to the central repository. When you
292 <b>commit</b>, fossil also does a <b>pull</b> and issues a warning
293 if your check-in would cause a fork. After a <b>commit</b>, fossil
294 automatically does a <b>push</b> to send your changes up to the
295 central server.</p>
296
297 <p>With autosync enabled, fossil works like
298 <a href="http://www.nongnu.org/cvs/">CVS</a> or
299 <a href="http://subversion.tigris.org/">Subversion</a>.
300 When autosync disabled, fossil works more like
301 <a href="http://monotone.ca/">Monotone</a>,
302 <a href="http://git.or.cz">GIT</a>, or
303 <a href="http://www.selenic.com/mercurial/wiki/">Mercurial</a>.
304 The fun thing about fossil is that it will work either
305 way, depending on your needs of the moment. You can freely switch
306 between these operating modes using commands like:</p>
307
308 <blockquote>
309 <b>fossil setting autosync off<br />
310 fossil setting autosync on</b>
311 </blockquote>
312
313 <p>For additional information about autosync and other settings
314 using the <b>help</b> command.</p>
315
316 <h2>5.0 Setting Up A Fossil Server</h2>
317
318 <p>With other configuration management software, setting up a server is
319 a lot of work and normally takes time, patience, and a lot of system
320 knowledge. Fossil is designed to avoid this frustration. Setting up
321 a server with fossil is ridiculously easy. You have three options:</p>
322
323 <ol>
324 <li><p><b>Setting up a stand-alone server</b></p>
325
326 <p>From within your source tree just use the <b>server</b> command and
327 fossil will start listening for incoming requests on TCP port 8080.
328 You can point your webbrowser at <a href="http://localhost:8080/">
329 http://localhost:8080/</a> and begin exploring. Or your coworkers
330 can do pushes or pulls against your server. Use the <b>--port</b>
331 option to the server command to specify a different TCP port. If
332 you do not have a local source tree, use the <b>-R</b> command-line
333 option to specify the repository file.</p>
334
335 <p>A stand-alone server is a great way to set of transient connections
336 between coworkers for doing quick pushes or pulls. But you can also
337 set up a permanent stand-alone server if you prefer. Just make
338 arrangements for fossil to be launched with appropriate arguments
339 after every reboot.</p>
340 </li>
341
342 <li><p><b>Setting up a CGI server</b></p>
343
344 <p>If you have a webserver running on your machine already, you can
345 set up fossil to be run from CGI. Simply create an executable script
346 that looks something like this:</p>
347
348 <blockquote><pre>
349 #!/usr/local/bin/fossil
350 repository: /home/me/bigproject.fossil
351 </pre></blockquote>
352
353 <p>Edit this script to use whatever pathnames are appropriate for
354 your project. Then point your webbrowser at the script and off you
355 go.</p></li>
356
357 <li><p><b>Setting up an inetd server</b></p>
358
359 <p>If you have inetd or xinetd running on your system, you can set
360 those services up to launch fossil to deal with inbound TCP/IP connections
361 on whatever port you want. Set up inetd or xinetd to launch fossil
362 like this:</p>
363
364 <blockquote><pre>
365 /usr/local/bin/fossil http /home/me/bigproject.fossil
366 </pre></blockquote>
367
368 <p>As before, change the filenames to whatever is appropriate for
369 your system. You can have fossil run as any user that has write
370 permission on the repository and on the directory that contains the
371 repository. But it is safer to run fossil as root. When fossil
372 sees that it is running as root, it automatically puts itself into
373 a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> and
374 drops all privileges prior to reading any information from the client.
375 Since fossil is a stand-alone program, you do not need to put anything
376 in the chroot jail with fossil in order for it to do its job.</p>
377 </li>
378 </ol>
--- a/www/concepts.html
+++ b/www/concepts.html
@@ -1,378 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/concepts.wiki
+445
--- a/www/concepts.wiki
+++ b/www/concepts.wiki
@@ -0,0 +1,445 @@
1
+tp://localhost:8080
2
+Fossil Concepts
3
+lhost:8080/</a> and begin explori<p>
4
+<a href="ierver. Use the <b>--port</b>
5
+opt">
6
+software</a>kia
7
+Each
8
+<a hat <a href="http://localhost:8080/">
9
+http://localhost:8080/</a> and begin exploring. Or your coworkers
10
+can do pushes or pulls against your server. Use the <b>--port</b>
11
+option to the server command to specify a different TCP port. If
12
+you do not have acasedentifier or A.wi.wikia
13
+East make
14
+arrangements for fossil to be launched with appropriate arguments
15
+after </p>every reboot.
16
+
17
+If you just want a server to browse the built-in fossil website
18
+locally, use <p>ossil website
19
+locally, use the <b>ui</b> command in place of <b>server</b>. The
20
+<b>ui</b> command starts up a local server too, but it also takes
21
+the additional step of automatically launching your webbrowser and
22
+pointing at the new server.
23
+</li>
24
+
25
+<li><b>Setting up a CGI server</b>
26
+
27
+If you have a web-server running on your machine already, you can
28
+set up fossil to be run from CGI. Simply create an executab</p>
29
+
30
+<p>sr/local/bin/fossil
31
+repository: /home/me/bigproject.fossil
32
+</pre></blocbaseline
33
+Edit this script to use whatever pathnames are appropriate for
34
+your project. versions or baselin script and off you
35
+go. The [./selfhost.wiki | self-hosting fossil repositories] are
36
+all set up this way.</li>
37
+
38
+<li><b>Setting up an inetd server</b>
39
+
40
+If you have inetd or xinetd running on your system, you </p>
41
+
42
+<p>n set
43
+those services up to launch fossil to deal with inbound TCP/IP connections
44
+on whatever port you want. Set up inetd or Artifact ID
45
+for the ar.wikia
46
+Each
47
+<a hash of the content
48
+40 characters of lower-casedentifier or Artifact ID
49
+for the ar
50
+your system. You can have fossil r</p>
51
+
52
+<p>
53
+permission onand on the directory that contains the
54
+repository. But it is safer to run fossil as root. When fossil
55
+sees that it is running as root, it automaChroot">chroot jail</a> and
56
+drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p>
57
+
58
+<p></p>
59
+
60
+<p>t <a href="http://localhost:8080/">
61
+http://localhost:8080/</a> and begin exploring. Or your coworkers
62
+can do ushes or pulls against your server. Use the <b>--port</b>
63
+option to the server command to specify a different TCP port. If
64
+you do not have acasedentifier or A.wikia
65
+Each
66
+<a hash offile.
67
+
68
+The "fossil server" command is a great way to set of transient connections
69
+between coworkers for doing quick pushes or pulls. But you can also
70
+set up a permanent stand-alone server if you prefer. Just make
71
+arrangements for fossil to be launched with appropriate arguments
72
+after every reboot.
73
+
74
+If you just want a server to browse the built-in fossil website
75
+locally, use the <b>ui</b> command in place eon to the server command to specify a different TCP port. If
76
+you do not have acasedentifier or A.wi.wikia
77
+East make
78
+arrangements for fossil to be launched with appropriate arguments
79
+after </p>every reboot.
80
+
81
+If you just want a server to browse the built-in fossil website
82
+locally, use <p>ossil website
83
+locally, use the <b>ui</b> command in place of <b>server</b>. The
84
+<b>ui</b> command starts up a local server too, but it also takes
85
+the additional step of automatically launching your webbrowser and
86
+pointing at the new server.
87
+</li>
88
+
89
+<li><b>Setting up a CGI server</b>
90
+
91
+If you have a web-server running on your machine already, you can
92
+set up fossil to be run from CGI. Simply create an executab</p>
93
+
94
+<p>sr/local/bin/fossil
95
+repository: /home/me/bigproject.fossil
96
+</pre></blockquote>
97
+
98
+Edit this script to use whatever pathnames are appropriate for
99
+your project. Then point your web browser at the script and off you
100
+go. The [./selfhost.wiki | self-hosting fossil repositories] are
101
+all set up this way.</li>
102
+
103
+<li><b>Setting up an inetd server</b>
104
+
105
+If you have inetd or xinetd running on your system, you </p>
106
+
107
+<p>n set
108
+those services up to launch fossil to deal with inbound TCP/IP connections
109
+on whatever port you want. Set up inetd or Artifact ID
110
+for the ar.wikia
111
+Each
112
+<a hash of the content
113
+40 characters of lower-casedentifier or Artifact ID
114
+for the ar
115
+your system. You can have fossil r</p>
116
+
117
+<p>
118
+permission onand on the directory that contains the
119
+repository. But it is safer to run fossil as root. When fossil
120
+sees that it is running as root, it automaChroot">chroot jail</a>Universally Unique Identifier or UUdrops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a>UUlocalhost:8080/">
121
+http://localhUUOr your coworkers
122
+can do pushes or pulls against your server. Use the <b>--UUID.</p>
123
+
124
+
125
+<p>UU</b>
126
+option to the server command to specify a different TCP port. If
127
+you do not p>
128
+
129
+<p></p>
130
+</li>
131
+
132
+<li><p</p>
133
+
134
+<p></p><p></p></li>
135
+
136
+<li><p</p>
137
+
138
+<p></p><p></p>,The interesting thing aboutbaselinench fossil to deal with inbound TCP/IP connections
139
+on whatever port you want. Set up inetd or Artifact ID
140
+for the ar.wikia
141
+Each
142
+<a hash of the conteUUier or Artifact ID
143
+for the ar
144
+your system. You can have fossil r</p>
145
+
146
+<p>
147
+permissioUUns the
148
+repository. But it is safer to run fossil as root. When fossil
149
+sees that it is running as root, it automaChroot">chroot jail</a> and
150
+drops all privileget the root of a source treenew check-in. new check-UUID. And since the UU</a>. or compiling it yourselfS</a></p>
151
+
152
+<p></p>
153
+
154
+<p>t <a href="http://localhost:8080/">
155
+http://localhost:8080/</a> and begin exploring. Or your coworkers
156
+can do pushes or pulls against your server. Use the <b>--port</b>
157
+option to the server command to specify a different TCP port. If
158
+you do not have acasedentifier or A.wikia
159
+Each
160
+<a hash offile.
161
+
162
+The "fossil server" command is a great way to set of transient connections
163
+between coworkers for doing quick pushes or pulls. But you can also
164
+set up a permanent stand-alone server if you prefer. Just make
165
+arrangements for fossil to be launched with appropriate arguments
166
+after every reboot.
167
+
168
+If you just want a server to browse the built-in fossil website
169
+localUUssil website
170
+locally, use the <b>ui</b> command in place of <b>server</b>. The
171
+<b>ui</b> command UUID to disk name. The UUID
172
+se the <b>ui</b> commanUUID that identifies a Use the <b>--port</b>
173
+opt">
174
+software</a>kia
175
+Each
176
+<a hat <a href="htnnowikihttp://localhost:8080
177
+Fossil Concepts
178
+lhost:8080/</a> and begin explori<p>
179
+<a href="ierver. Use the <b>--port</b>
180
+opt">
181
+software</a>kia
182
+Each
183
+<a hat <a href="http://localhost:8080/">
184
+http://localhost:8080/</a> and begin exploring. Or your coworkers
185
+can do pushes or pulls against your server. Use the <b>--port</b>
186
+option to the server command to specify a different TCP port. If
187
+you do not have acasedentifier or A.wi.wikia
188
+East make
189
+arrangements for fossil to be launched with appropriate arguments
190
+after </p>every reboot.
191
+
192
+If you just want a server to browse the built-in fossil website
193
+locally, use <p>ossil website
194
+locally, use the <b>ui</b> command in place of <b>server</b>. The
195
+<b>ui</b> command starts up a local server too, but it also takes
196
+the additional step of automatically launching your webbrowser and
197
+pointing at the new server.
198
+</li>
199
+
200
+<li><b>Setting up a CGI server</b>
201
+
202
+If you have a web-server running on your machine already, you can
203
+set up fossil to be run from CGI. Simply create an executab</p>
204
+
205
+<p>sr/local/bin/fossil
206
+repository: /home/me/bigproject.fossil
207
+</pre></blocbaseline
208
+Edit this script to use whatever pathnames are appropriate for
209
+your project. versions or baselin script and off you
210
+go. The [./selfhost.wiki | self-hosting fossil repositories] are
211
+all set up this way.</li>
212
+
213
+<li><b>Setting up an inetd server</b>
214
+
215
+If you have inetd or xinetd running on your system, you </p>
216
+
217
+<p>n set
218
+those services up to launch fossil to deal with inbound TCP/IP connections
219
+on whatever port you want. Set up inetd or Artifact ID
220
+for the ar.wikia
221
+Each
222
+<a hash of the content
223
+40 characters of lower-casedentifier or Artifact ID
224
+for the ar
225
+your system. You can have fossil r</p>
226
+
227
+<p>
228
+permission onand on the directory that contains the
229
+repository. But it is safer to run fossil as root. When fossil
230
+sees that it is running as root, it automaChroot">chroot jail</a> and
231
+drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p>
232
+
233
+<p></p>
234
+
235
+<p>t <a href="http://localhost:8080/">
236
+http://localhost:8080/</a> and begin exploring. Or your coworkers
237
+can do ushes or pulls against your server. Use the <b>--port</b>
238
+option to the server command to specify a different TCP port. If
239
+you do not have acasedentifier or A.wikia
240
+Each
241
+<a hash offile.
242
+
243
+The "fossil server" command is a great way to set of transient connections
244
+between coworkers for doing quick pushes or pulls. But you can also
245
+set up a permanent stand-alone server if you prefer. Just make
246
+arrangements for fossil to be launched with apa perfectly functional "diffant a server to browse the built-in fdssil website
247
+locally, use the <b>ui</b> command in place eon to the server command to specify a different TCP port. If
248
+you do not have acasedentifier or A.wi.wikia
249
+East make
250
+arrangements for fossil to be launched with appropriate arguments
251
+after </p>every reboot.
252
+
253
+If you just want a server to browse the built-in fossil website
254
+locally, use <p>ossil website
255
+locally, use the <b>ui</b> command in place of <b>server</b>. The
256
+<b>ui</b> command starts up a local server too, but it also takes
257
+the additional step of automatically launching your webbrowser and
258
+pointing at the new server.
259
+</li>
260
+
261
+<li><b>Setting up a CGI server</b>
262
+
263
+If you have a web-server running on your machine already, you can
264
+set up fossil to be run from CGI. Simply create an executab</p>
265
+
266
+<p>sr/local/bin/fossil
267
+repository: /home/me/bigproject.fossil
268
+</pre></blockquote>
269
+
270
+Edit this script to use whatever patnames are appropriate for
271
+your project. Then point your web browser at the script and off you
272
+go. The [./selfhost.wiki | self-hosting fossil repositories] are
273
+all set up this way.</li>
274
+
275
+<li><b>Setting up an inetd server</b>
276
+
277
+If you have inetd or xinetd running on your system, you </p>
278
+
279
+<p>n set
280
+those services up to launch fossil to deal with inbound TCP/IP connections
281
+on whatever port you want. Set up inetd or Artifact ID
282
+for the ar.wikia
283
+Each
284
+<a hash of the content
285
+40 characters of lower-casedentifier or Artifact ID
286
+for the ar
287
+your system. You can have fossil r</p>
288
+
289
+<p>
290
+permission onand on the directory that contains the
291
+repository. But it is safer to run fossil as root. When fossil
292
+sees that it is running as root, it automaChroot">chroot jail</a> and
293
+drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p>
294
+
295
+<p></p>
296
+
297
+<p>t <a href="http://localhost:8080/">
298
+http://localhost:8080/</a> and begin exploring. Or your coworkers
299
+can do pushes or pulls against your server. Use the <b>--port</b>
300
+option to the server command to specify a different TCP port. If
301
+you do not p>
302
+
303
+<p></p>
304
+</li>
305
+
306
+<li><p</p>
307
+
308
+<p></p><p></p></li>
309
+
310
+<li><p</p>
311
+
312
+<p></p><p></p>,The interesting thing aboutbaselinench fossil to deal with inbound TCP/IP connections
313
+on whatever port you want. Set up inetd or Artifact ID
314
+for the ar.wikia
315
+Each
316
+<a hash of the content
317
+40 characters of lower-casedentifier or Artifact ID
318
+for the ar
319
+your system. You can have fossil r</p>
320
+
321
+<p>
322
+permission onand on the directory that contains the
323
+repository. But it is safer to run fossil as root. When fossil
324
+sees that it is running as root, it automaChroot">chroot jail</a> and
325
+drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p>
326
+
327
+<p></p>
328
+
329
+<p>t <a href="http://localhost:8080/">
330
+http://localhost:8080/</a> and begin exploring. Or your coworkers
331
+can do pushes or pulls against your server. Use the <b>--port</b>
332
+option to the server command to specify a different TCP port. If
333
+you do not have acasedentifier or A.wikia
334
+Each
335
+<a hash offile.
336
+
337
+The "fossil server" command is a great way to set of transient connections
338
+between coworkers for doing quick pushes or pulls. But you can also
339
+set up a permanent stand-alone server if you prefer. Just make
340
+arrangements for fossil to be launched with appropriate arguments
341
+after every reboot.
342
+
343
+If you just want a server to browse the built-in fossil website
344
+locally, use the <b>ui</b> command in place of <b>server</b>. The
345
+<b>ui</b> command starts up a local server too, but .wikia
346
+Ea/a> and
347
+drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p><p></p>
348
+
349
+
350
+<p></p><p></p>
351
+
352
+<p></p>
353
+
354
+<p></p><p></p><p>wikia
355
+Each
356
+<a hat <a href="http://localhost:8080/">
357
+http://localhost:8080/</a> and begin exploring. Or your coworkers
358
+can do pushes or pulls against your server. Use the <b>--port</b>
359
+option to the server command to specify a different TCP port. If
360
+you do not have acasedentifier or A.wikia
361
+Each
362
+<a hash offile.
363
+
364
+The "fo
365
+<a hat </p>
366
+
367
+<p></p>
368
+
369
+<p>a one-time commandCheck the instructions that come with the upgrade
370
+for details.</p>
371
+
372
+<p></p><p></p>
373
+<p>"autosync" and "non-awork in sync with the central server. Non-autosync is
374
+more like GIT or Bitkeeperikia
375
+Each
376
+<a hat <a href="http://localhost:8080/">
377
+http://localhost:8080/</a> and begin explohttp://localhost:8080/">
378
+http://l</p><p>when autosync is only
379
+dis<pp></li>
380
+
381
+<li><pp></li>
382
+
383
+<li><pp></li>
384
+
385
+<li><pp></li>
386
+
387
+<li><pp></li>
388
+
389
+<li><pp></li>
390
+
391
+<li><pp></li>
392
+</ol>
393
+
394
+<h3>4.2 Non-p></p>
395
+
396
+<ol>
397
+<li><p p></li>
398
+
399
+<li><pp></li>
400
+
401
+<li><pp></li>
402
+
403
+<li><pp></li>
404
+
405
+<li><pp></li>
406
+
407
+<li><p>p></li>
408
+
409
+<li><pp></li>
410
+
411
+<li><pp></li>
412
+
413
+<li><pp><p>p</p>
414
+
415
+<p></p>
416
+
417
+<p>A</p>
418
+
419
+<p></p>
420
+</li>
421
+
422
+<li><p</p>
423
+
424
+<p></p><p></p></li>
425
+
426
+<li><p</p>
427
+
428
+<p></p><p></p>2.3tnowikihttp://localhost:8080
429
+Fos//localhost:8080
430
+Fossil Concepts
431
+lhost:8080/</a> and begin explori<p>
432
+<a href="ierver. Use the <b>--port</b>
433
+opt">
434
+software</a>kia
435
+Each
436
+<a hat <a href="http://localhost:8080/">
437
+http://localhost:8080/</a> and begin exploring. Or your coworkers
438
+can do pushes or pulls against your server. Use the <b>--port</b>
439
+option to the server command to specify a different TCP port. If
440
+you do not have acasedentifier or A.wi.wikia
441
+East make
442
+arrangements for fossil to be launched with appropriate arguments
443
+after </p>every reboot.
444
+
445
+If you just want a serv
--- a/www/concepts.wiki
+++ b/www/concepts.wiki
@@ -0,0 +1,445 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--- a/www/concepts.wiki
+++ b/www/concepts.wiki
@@ -0,0 +1,445 @@
1 tp://localhost:8080
2 Fossil Concepts
3 lhost:8080/</a> and begin explori<p>
4 <a href="ierver. Use the <b>--port</b>
5 opt">
6 software</a>kia
7 Each
8 <a hat <a href="http://localhost:8080/">
9 http://localhost:8080/</a> and begin exploring. Or your coworkers
10 can do pushes or pulls against your server. Use the <b>--port</b>
11 option to the server command to specify a different TCP port. If
12 you do not have acasedentifier or A.wi.wikia
13 East make
14 arrangements for fossil to be launched with appropriate arguments
15 after </p>every reboot.
16
17 If you just want a server to browse the built-in fossil website
18 locally, use <p>ossil website
19 locally, use the <b>ui</b> command in place of <b>server</b>. The
20 <b>ui</b> command starts up a local server too, but it also takes
21 the additional step of automatically launching your webbrowser and
22 pointing at the new server.
23 </li>
24
25 <li><b>Setting up a CGI server</b>
26
27 If you have a web-server running on your machine already, you can
28 set up fossil to be run from CGI. Simply create an executab</p>
29
30 <p>sr/local/bin/fossil
31 repository: /home/me/bigproject.fossil
32 </pre></blocbaseline
33 Edit this script to use whatever pathnames are appropriate for
34 your project. versions or baselin script and off you
35 go. The [./selfhost.wiki | self-hosting fossil repositories] are
36 all set up this way.</li>
37
38 <li><b>Setting up an inetd server</b>
39
40 If you have inetd or xinetd running on your system, you </p>
41
42 <p>n set
43 those services up to launch fossil to deal with inbound TCP/IP connections
44 on whatever port you want. Set up inetd or Artifact ID
45 for the ar.wikia
46 Each
47 <a hash of the content
48 40 characters of lower-casedentifier or Artifact ID
49 for the ar
50 your system. You can have fossil r</p>
51
52 <p>
53 permission onand on the directory that contains the
54 repository. But it is safer to run fossil as root. When fossil
55 sees that it is running as root, it automaChroot">chroot jail</a> and
56 drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p>
57
58 <p></p>
59
60 <p>t <a href="http://localhost:8080/">
61 http://localhost:8080/</a> and begin exploring. Or your coworkers
62 can do ushes or pulls against your server. Use the <b>--port</b>
63 option to the server command to specify a different TCP port. If
64 you do not have acasedentifier or A.wikia
65 Each
66 <a hash offile.
67
68 The "fossil server" command is a great way to set of transient connections
69 between coworkers for doing quick pushes or pulls. But you can also
70 set up a permanent stand-alone server if you prefer. Just make
71 arrangements for fossil to be launched with appropriate arguments
72 after every reboot.
73
74 If you just want a server to browse the built-in fossil website
75 locally, use the <b>ui</b> command in place eon to the server command to specify a different TCP port. If
76 you do not have acasedentifier or A.wi.wikia
77 East make
78 arrangements for fossil to be launched with appropriate arguments
79 after </p>every reboot.
80
81 If you just want a server to browse the built-in fossil website
82 locally, use <p>ossil website
83 locally, use the <b>ui</b> command in place of <b>server</b>. The
84 <b>ui</b> command starts up a local server too, but it also takes
85 the additional step of automatically launching your webbrowser and
86 pointing at the new server.
87 </li>
88
89 <li><b>Setting up a CGI server</b>
90
91 If you have a web-server running on your machine already, you can
92 set up fossil to be run from CGI. Simply create an executab</p>
93
94 <p>sr/local/bin/fossil
95 repository: /home/me/bigproject.fossil
96 </pre></blockquote>
97
98 Edit this script to use whatever pathnames are appropriate for
99 your project. Then point your web browser at the script and off you
100 go. The [./selfhost.wiki | self-hosting fossil repositories] are
101 all set up this way.</li>
102
103 <li><b>Setting up an inetd server</b>
104
105 If you have inetd or xinetd running on your system, you </p>
106
107 <p>n set
108 those services up to launch fossil to deal with inbound TCP/IP connections
109 on whatever port you want. Set up inetd or Artifact ID
110 for the ar.wikia
111 Each
112 <a hash of the content
113 40 characters of lower-casedentifier or Artifact ID
114 for the ar
115 your system. You can have fossil r</p>
116
117 <p>
118 permission onand on the directory that contains the
119 repository. But it is safer to run fossil as root. When fossil
120 sees that it is running as root, it automaChroot">chroot jail</a>Universally Unique Identifier or UUdrops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a>UUlocalhost:8080/">
121 http://localhUUOr your coworkers
122 can do pushes or pulls against your server. Use the <b>--UUID.</p>
123
124
125 <p>UU</b>
126 option to the server command to specify a different TCP port. If
127 you do not p>
128
129 <p></p>
130 </li>
131
132 <li><p</p>
133
134 <p></p><p></p></li>
135
136 <li><p</p>
137
138 <p></p><p></p>,The interesting thing aboutbaselinench fossil to deal with inbound TCP/IP connections
139 on whatever port you want. Set up inetd or Artifact ID
140 for the ar.wikia
141 Each
142 <a hash of the conteUUier or Artifact ID
143 for the ar
144 your system. You can have fossil r</p>
145
146 <p>
147 permissioUUns the
148 repository. But it is safer to run fossil as root. When fossil
149 sees that it is running as root, it automaChroot">chroot jail</a> and
150 drops all privileget the root of a source treenew check-in. new check-UUID. And since the UU</a>. or compiling it yourselfS</a></p>
151
152 <p></p>
153
154 <p>t <a href="http://localhost:8080/">
155 http://localhost:8080/</a> and begin exploring. Or your coworkers
156 can do pushes or pulls against your server. Use the <b>--port</b>
157 option to the server command to specify a different TCP port. If
158 you do not have acasedentifier or A.wikia
159 Each
160 <a hash offile.
161
162 The "fossil server" command is a great way to set of transient connections
163 between coworkers for doing quick pushes or pulls. But you can also
164 set up a permanent stand-alone server if you prefer. Just make
165 arrangements for fossil to be launched with appropriate arguments
166 after every reboot.
167
168 If you just want a server to browse the built-in fossil website
169 localUUssil website
170 locally, use the <b>ui</b> command in place of <b>server</b>. The
171 <b>ui</b> command UUID to disk name. The UUID
172 se the <b>ui</b> commanUUID that identifies a Use the <b>--port</b>
173 opt">
174 software</a>kia
175 Each
176 <a hat <a href="htnnowikihttp://localhost:8080
177 Fossil Concepts
178 lhost:8080/</a> and begin explori<p>
179 <a href="ierver. Use the <b>--port</b>
180 opt">
181 software</a>kia
182 Each
183 <a hat <a href="http://localhost:8080/">
184 http://localhost:8080/</a> and begin exploring. Or your coworkers
185 can do pushes or pulls against your server. Use the <b>--port</b>
186 option to the server command to specify a different TCP port. If
187 you do not have acasedentifier or A.wi.wikia
188 East make
189 arrangements for fossil to be launched with appropriate arguments
190 after </p>every reboot.
191
192 If you just want a server to browse the built-in fossil website
193 locally, use <p>ossil website
194 locally, use the <b>ui</b> command in place of <b>server</b>. The
195 <b>ui</b> command starts up a local server too, but it also takes
196 the additional step of automatically launching your webbrowser and
197 pointing at the new server.
198 </li>
199
200 <li><b>Setting up a CGI server</b>
201
202 If you have a web-server running on your machine already, you can
203 set up fossil to be run from CGI. Simply create an executab</p>
204
205 <p>sr/local/bin/fossil
206 repository: /home/me/bigproject.fossil
207 </pre></blocbaseline
208 Edit this script to use whatever pathnames are appropriate for
209 your project. versions or baselin script and off you
210 go. The [./selfhost.wiki | self-hosting fossil repositories] are
211 all set up this way.</li>
212
213 <li><b>Setting up an inetd server</b>
214
215 If you have inetd or xinetd running on your system, you </p>
216
217 <p>n set
218 those services up to launch fossil to deal with inbound TCP/IP connections
219 on whatever port you want. Set up inetd or Artifact ID
220 for the ar.wikia
221 Each
222 <a hash of the content
223 40 characters of lower-casedentifier or Artifact ID
224 for the ar
225 your system. You can have fossil r</p>
226
227 <p>
228 permission onand on the directory that contains the
229 repository. But it is safer to run fossil as root. When fossil
230 sees that it is running as root, it automaChroot">chroot jail</a> and
231 drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p>
232
233 <p></p>
234
235 <p>t <a href="http://localhost:8080/">
236 http://localhost:8080/</a> and begin exploring. Or your coworkers
237 can do ushes or pulls against your server. Use the <b>--port</b>
238 option to the server command to specify a different TCP port. If
239 you do not have acasedentifier or A.wikia
240 Each
241 <a hash offile.
242
243 The "fossil server" command is a great way to set of transient connections
244 between coworkers for doing quick pushes or pulls. But you can also
245 set up a permanent stand-alone server if you prefer. Just make
246 arrangements for fossil to be launched with apa perfectly functional "diffant a server to browse the built-in fdssil website
247 locally, use the <b>ui</b> command in place eon to the server command to specify a different TCP port. If
248 you do not have acasedentifier or A.wi.wikia
249 East make
250 arrangements for fossil to be launched with appropriate arguments
251 after </p>every reboot.
252
253 If you just want a server to browse the built-in fossil website
254 locally, use <p>ossil website
255 locally, use the <b>ui</b> command in place of <b>server</b>. The
256 <b>ui</b> command starts up a local server too, but it also takes
257 the additional step of automatically launching your webbrowser and
258 pointing at the new server.
259 </li>
260
261 <li><b>Setting up a CGI server</b>
262
263 If you have a web-server running on your machine already, you can
264 set up fossil to be run from CGI. Simply create an executab</p>
265
266 <p>sr/local/bin/fossil
267 repository: /home/me/bigproject.fossil
268 </pre></blockquote>
269
270 Edit this script to use whatever patnames are appropriate for
271 your project. Then point your web browser at the script and off you
272 go. The [./selfhost.wiki | self-hosting fossil repositories] are
273 all set up this way.</li>
274
275 <li><b>Setting up an inetd server</b>
276
277 If you have inetd or xinetd running on your system, you </p>
278
279 <p>n set
280 those services up to launch fossil to deal with inbound TCP/IP connections
281 on whatever port you want. Set up inetd or Artifact ID
282 for the ar.wikia
283 Each
284 <a hash of the content
285 40 characters of lower-casedentifier or Artifact ID
286 for the ar
287 your system. You can have fossil r</p>
288
289 <p>
290 permission onand on the directory that contains the
291 repository. But it is safer to run fossil as root. When fossil
292 sees that it is running as root, it automaChroot">chroot jail</a> and
293 drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p>
294
295 <p></p>
296
297 <p>t <a href="http://localhost:8080/">
298 http://localhost:8080/</a> and begin exploring. Or your coworkers
299 can do pushes or pulls against your server. Use the <b>--port</b>
300 option to the server command to specify a different TCP port. If
301 you do not p>
302
303 <p></p>
304 </li>
305
306 <li><p</p>
307
308 <p></p><p></p></li>
309
310 <li><p</p>
311
312 <p></p><p></p>,The interesting thing aboutbaselinench fossil to deal with inbound TCP/IP connections
313 on whatever port you want. Set up inetd or Artifact ID
314 for the ar.wikia
315 Each
316 <a hash of the content
317 40 characters of lower-casedentifier or Artifact ID
318 for the ar
319 your system. You can have fossil r</p>
320
321 <p>
322 permission onand on the directory that contains the
323 repository. But it is safer to run fossil as root. When fossil
324 sees that it is running as root, it automaChroot">chroot jail</a> and
325 drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p>
326
327 <p></p>
328
329 <p>t <a href="http://localhost:8080/">
330 http://localhost:8080/</a> and begin exploring. Or your coworkers
331 can do pushes or pulls against your server. Use the <b>--port</b>
332 option to the server command to specify a different TCP port. If
333 you do not have acasedentifier or A.wikia
334 Each
335 <a hash offile.
336
337 The "fossil server" command is a great way to set of transient connections
338 between coworkers for doing quick pushes or pulls. But you can also
339 set up a permanent stand-alone server if you prefer. Just make
340 arrangements for fossil to be launched with appropriate arguments
341 after every reboot.
342
343 If you just want a server to browse the built-in fossil website
344 locally, use the <b>ui</b> command in place of <b>server</b>. The
345 <b>ui</b> command starts up a local server too, but .wikia
346 Ea/a> and
347 drops all privileget the root of a source treenew check-in. new check-in. baselineh3><a name="keyconc">2.3</a>. or compiling it yourselfS</a></p><p></p>
348
349
350 <p></p><p></p>
351
352 <p></p>
353
354 <p></p><p></p><p>wikia
355 Each
356 <a hat <a href="http://localhost:8080/">
357 http://localhost:8080/</a> and begin exploring. Or your coworkers
358 can do pushes or pulls against your server. Use the <b>--port</b>
359 option to the server command to specify a different TCP port. If
360 you do not have acasedentifier or A.wikia
361 Each
362 <a hash offile.
363
364 The "fo
365 <a hat </p>
366
367 <p></p>
368
369 <p>a one-time commandCheck the instructions that come with the upgrade
370 for details.</p>
371
372 <p></p><p></p>
373 <p>"autosync" and "non-awork in sync with the central server. Non-autosync is
374 more like GIT or Bitkeeperikia
375 Each
376 <a hat <a href="http://localhost:8080/">
377 http://localhost:8080/</a> and begin explohttp://localhost:8080/">
378 http://l</p><p>when autosync is only
379 dis<pp></li>
380
381 <li><pp></li>
382
383 <li><pp></li>
384
385 <li><pp></li>
386
387 <li><pp></li>
388
389 <li><pp></li>
390
391 <li><pp></li>
392 </ol>
393
394 <h3>4.2 Non-p></p>
395
396 <ol>
397 <li><p p></li>
398
399 <li><pp></li>
400
401 <li><pp></li>
402
403 <li><pp></li>
404
405 <li><pp></li>
406
407 <li><p>p></li>
408
409 <li><pp></li>
410
411 <li><pp></li>
412
413 <li><pp><p>p</p>
414
415 <p></p>
416
417 <p>A</p>
418
419 <p></p>
420 </li>
421
422 <li><p</p>
423
424 <p></p><p></p></li>
425
426 <li><p</p>
427
428 <p></p><p></p>2.3tnowikihttp://localhost:8080
429 Fos//localhost:8080
430 Fossil Concepts
431 lhost:8080/</a> and begin explori<p>
432 <a href="ierver. Use the <b>--port</b>
433 opt">
434 software</a>kia
435 Each
436 <a hat <a href="http://localhost:8080/">
437 http://localhost:8080/</a> and begin exploring. Or your coworkers
438 can do pushes or pulls against your server. Use the <b>--port</b>
439 option to the server command to specify a different TCP port. If
440 you do not have acasedentifier or A.wi.wikia
441 East make
442 arrangements for fossil to be launched with appropriate arguments
443 after </p>every reboot.
444
445 If you just want a serv
D www/delta_encoder_algorithm.html
-236
--- a/www/delta_encoder_algorithm.html
+++ b/www/delta_encoder_algorithm.html
@@ -1,236 +0,0 @@
1
-<html>
2
-<head>
3
-<title>Fossil Delta Encoding Algorithm</title>
4
-</head>
5
-<body bgcolor="white">
6
-<p>[ <a href="index.html">Index</a> ]</p>
7
-<hr>
8
-<h1 align="center">
9
-Fossil Delta Encoding Algorithm
10
-</h1>
11
-
12
-<p>A key component for the efficient storage of multiple revisions of
13
-a file in fossil repositories is the use of delta-compression, i.e. to
14
-store only the changes between revisions instead of the whole
15
-file.</p>
16
-
17
-<p>This document describes the encoding algorithm used by Fossil to
18
-generate deltas. It is targeted at developers working on either
19
-<a href="index.html">fossil</a> itself, or on tools compatible with
20
-it. The exact format of the generated byte-sequences, while in general
21
-not necessary to understand encoder operation, can be found in the
22
-companion specification titled "<a href="delta_format.html">Fossil
23
-Delta Format</a>".
24
-</p>
25
-
26
-<p>The entire algorithm is inspired
27
-by <a href="http://samba.anu.edu.au/rsync/">rsync</a>.</p>
28
-
29
-<a name="argresparam"><h2>1.0 Arguments, Results, and Parameters</h2>
30
-
31
-<p>The encoder takes two byte-sequences as input, the "original", and
32
-the "target", and returns a single byte-sequence containing the
33
-"delta" which transforms the original into the target upon its
34
-application.</p>
35
-
36
-<p>Note that the data of a "byte-sequence" includes its length,
37
-i.e. the number of bytes contained in the sequence.</p>
38
-
39
-<p>The algorithm has one parameter named "NHASH", the size of the
40
-"sliding window" for the "rolling hash", in bytes. These two terms are
41
-explained in the next section. The value of this parameter has to be a
42
-power of two for the algorithm to work. For Fossil the value of this
43
-parameter is set to "16".</p>
44
-
45
-<a name="operation"><h2>2.0 Operation</h2>
46
-
47
-<p>The algorithm is split into three phases which generate
48
-the <a href="delta_format.html#header">header</a>,
49
-<a href="delta_format.html#slist">segment list</a>,
50
-and <a href="delta_format.html#trailer">trailer</a> of the delta, per
51
-its general <a href="delta_format.html#structure">structure</a>.</p>
52
-
53
-<p>The two phases generating header and trailer are not covered here
54
-as their implementation trivially follows directly from the
55
-specification of the <a href="delta_format.html">delta format</a>.</p>
56
-
57
-<p>This leaves the segment-list. Its generation is done in two phases,
58
-a pre-processing step operating on the "original" byte-sequence,
59
-followed by the processing of the "target" byte-sequence using the
60
-information gathered by the first step.</p>
61
-
62
-<a name="preprocessing"><h3>2.1 Preprocessing the original</h3>
63
-
64
-<p>A major part of the processing of the "target" is to find a range
65
-in the "original" which contains the same content as found at the
66
-current location in the "target".</p>
67
-
68
-<p>A naive approach to this would be to search the whole "original"
69
-for such content. This however is very inefficient as it would search
70
-the same parts of the "original" over and over. What is done instead
71
-is to sample the "original" at regular intervals, compute signatures
72
-for the sampled locations and store them in a hash table keyed by
73
-these signatures.</p>
74
-
75
-<p>That is what happens in this step. The following processing step
76
-can then the compute signature for its current location and then has
77
-to search only a narrow set of locations in the "original" for
78
-possible matches, namely those which have the same signature.</p>
79
-
80
-<p>In detail:</p>
81
-
82
-<ol>
83
-<li>The "original" is split into chunks of NHASH bytes. Note that a
84
-partial chunk of less than NHASH bytes at the end of "original" is
85
-ignored.
86
-</li>
87
-<li>The <a href="#rollhash">rolling hash</a> of each chunk is
88
-computed.
89
-</li>
90
-<li>A hashtable is filled, mapping from the hashes of the chunks to
91
-the list of chunk locations having this hash.
92
-</li>
93
-</ol>
94
-
95
-<a name="processing"><h3>2.1 Processing the target</h3>
96
-
97
-<p>This, the main phase of the encoder, processes the target in a loop
98
-from beginning to end. The state of the encoder is captured by two
99
-locations, the "base" and the "slide". "base" points to the first byte
100
-of the target for which no delta output has been generated yet, and
101
-"slide" is the location of the window used to look in the "origin" for
102
-commonalities. This window is NHASH bytes long.</p>
103
-
104
-<p>Initially both "base" and "slide" point to the beginning of the
105
-"target". In each iteration of the loop the encoder decides whether to
106
-<ul>
107
-<li>emit a single instruction
108
-to <a href="delta_format.html#copyrange">copy a range</a>, or
109
-</li>
110
-<li>emit two instructions, first
111
-to <a href="delta_format.html#insertlit">insert a literal</a>, then
112
-to <a href="delta_format.html#copyrange">copy a range</a>, or
113
-</li>
114
-<li>move the window forward one byte.
115
-</li>
116
-</ul>
117
-</p>
118
-
119
-<img src="encode10.gif" align="right" hspace="10">
120
-<p>To make this decision the encoder first computes the hash value for
121
-the NHASH bytes in the window and then looks at all the locations in
122
-the "origin" which have the same signature. This part uses the hash
123
-table created by the pre-processing step to effiently find these
124
-locations.</p>
125
-
126
-<p>For each of the possible candidates the encoder finds the maximal
127
-range of bytes common to both "origin" and "target", going forward and
128
-backward from "slide" in the "target", and the candidate location in
129
-the "origin". This search is constrained on the side of the "target"
130
-by the "base" (backward search), and the end of the "target" (forward
131
-search), and on the side of the "origin" by the beginning and end of
132
-the "origin", respectively.</p>
133
-
134
-<p>There are input files for which the hash chains generated by the
135
-pre-processing step can become very long, leading to long search times
136
-and affecting the performance of the delta generator. To limit the
137
-effect such long chains can have the actual search for candidates is
138
-bounded, looking at most N candidates. Currently N is set to 250.</p>
139
-
140
-<p>From the ranges for all the candidates the best (= largest) common
141
-range is taken and it is determined how many bytes are needed to
142
-encode the bytes between the "base" and the end of that range. If the
143
-range extended back to the "base" then this can be done in a single
144
-copy instruction. Otherwise, i.e if there is a gap between the "base"
145
-and the beginning of the range then two instructions are needed, one
146
-to insert the bytes in the gap as a literal, and a copy instruction
147
-for the range itself. The general situation at this point can be seen
148
-in the picture to the right.</p>
149
-
150
-<p>If the number of bytes needed to encode both gap (if present), and
151
-range is less than the number of bytes we are encoding the encoder
152
-will emit the necessary instructions as described above, set "base"
153
-and "slide" to the end of the encoded range and start the next
154
-iteration at that point.</p>
155
-
156
-<p>If, on the other hand, the encoder either did not find candidate
157
-locations in the origin, or the best range coming out of the search
158
-needed more bytes to encode the range than there were bytes in the
159
-range, then no instructions are emitted and the window is moved one
160
-byte forward. The "base" is left unchanged in that case.</p>
161
-
162
-<p>The processing loop stops at one of two conditions:
163
-<ol>
164
-<li>The encoder decided to move the window forward, but the end of the
165
-window reached the end of the "target".
166
-</li>
167
-<li>After the emission of instructions the new "base" location is
168
-within NHASH bytes of end of the "target", i.e. there are no more than
169
-at most NHASH bytes left.
170
-</li>
171
-</ol>
172
-</p>
173
-
174
-<p>If the processing loop left bytes unencoded, i.e. "base" not
175
-exactly at the end of the "target", as is possible for both end
176
-conditions, then one last insert instruction is emitted to put these
177
-bytes into the delta.<p>
178
-
179
-<a name="exceptions"><h2>3.0 Exceptions</h2>
180
-
181
-<p>If the "original" is at most NHASH bytes long no compression of
182
-changes is possible, and the segment-list of the delta consists of a
183
-single literal which contains the entire "target".</p>
184
-
185
-<p>This is actually equivalent to the second end condition of the
186
-processing loop described in the previous section, just checked before
187
-actually entering the loop.</p>
188
-
189
-<a name="rollhash"><h2>4.0 The rolling hash</h2>
190
-
191
-<p>The rolling hash described below and used to compute content
192
-signatures was chosen not only for good hashing properties, but also
193
-to enable the easy (incremental) recalculation of its value for a
194
-sliding window, i.e. where the oldest byte is removed from the window
195
-and a new byte is shifted in.<p>
196
-
197
-<a name="rhdef"><h3>4.1 Definition</h3>
198
-
199
-<p>Assuming an array Z of NHASH bytes (indexing starting at 0) the
200
-hash V is computed via</p>
201
-
202
-<p align=center><table><tr><td>
203
-<p><img src="encode1.gif" align="center"></p>
204
-<p><img src="encode2.gif" align="center"></p>
205
-<p><img src="encode3.gif" align="center"></p>
206
-</td></tr></table></p>
207
-
208
-where A and B are unsigned 16-bit integers (hence the <u>mod</u>), and
209
-V is a 32-bit unsigned integer with B as MSB, A as LSB.
210
-
211
-<a name="rhincr"><h3>4.2 Incremental recalculation</h3>
212
-
213
-<p>Assuming an array Z of NHASH bytes (indexing starting at 0) with
214
-hash V (and components A and B), the dropped
215
-byte <img src="encode4.gif" align="center">, and the new byte
216
-<img src="encode5.gif" align="center"> , the new hash can
217
-be computed incrementally via: </p>
218
-
219
-<p align=center><table><tr><td>
220
-<p><img src="encode6.gif" align="center"></p>
221
-<p><img src="encode7.gif" align="center"></p>
222
-<p><img src="encode8.gif" align="center"></p>
223
-</td></tr></table></p>
224
-
225
-<p>For A, the regular sum, it can be seen easily that this the correct
226
-way recomputing that component.</p>
227
-
228
-<p>For B, the weighted sum, note first that <img src="encode4.gif"
229
-align="center"> has the weight NHASH in the sum, so that is what has
230
-to be removed. Then adding in <img src="encode9.gif" align="center">
231
-adds one weight factor to all the other values of Z, and at last adds
232
-in <img src="encode5.gif" align="center"> with weight 1, also
233
-generating the correct new sum</p>
234
-
235
-</body>
236
-</html>
--- a/www/delta_encoder_algorithm.html
+++ b/www/delta_encoder_algorithm.html
@@ -1,236 +0,0 @@
1 <html>
2 <head>
3 <title>Fossil Delta Encoding Algorithm</title>
4 </head>
5 <body bgcolor="white">
6 <p>[ <a href="index.html">Index</a> ]</p>
7 <hr>
8 <h1 align="center">
9 Fossil Delta Encoding Algorithm
10 </h1>
11
12 <p>A key component for the efficient storage of multiple revisions of
13 a file in fossil repositories is the use of delta-compression, i.e. to
14 store only the changes between revisions instead of the whole
15 file.</p>
16
17 <p>This document describes the encoding algorithm used by Fossil to
18 generate deltas. It is targeted at developers working on either
19 <a href="index.html">fossil</a> itself, or on tools compatible with
20 it. The exact format of the generated byte-sequences, while in general
21 not necessary to understand encoder operation, can be found in the
22 companion specification titled "<a href="delta_format.html">Fossil
23 Delta Format</a>".
24 </p>
25
26 <p>The entire algorithm is inspired
27 by <a href="http://samba.anu.edu.au/rsync/">rsync</a>.</p>
28
29 <a name="argresparam"><h2>1.0 Arguments, Results, and Parameters</h2>
30
31 <p>The encoder takes two byte-sequences as input, the "original", and
32 the "target", and returns a single byte-sequence containing the
33 "delta" which transforms the original into the target upon its
34 application.</p>
35
36 <p>Note that the data of a "byte-sequence" includes its length,
37 i.e. the number of bytes contained in the sequence.</p>
38
39 <p>The algorithm has one parameter named "NHASH", the size of the
40 "sliding window" for the "rolling hash", in bytes. These two terms are
41 explained in the next section. The value of this parameter has to be a
42 power of two for the algorithm to work. For Fossil the value of this
43 parameter is set to "16".</p>
44
45 <a name="operation"><h2>2.0 Operation</h2>
46
47 <p>The algorithm is split into three phases which generate
48 the <a href="delta_format.html#header">header</a>,
49 <a href="delta_format.html#slist">segment list</a>,
50 and <a href="delta_format.html#trailer">trailer</a> of the delta, per
51 its general <a href="delta_format.html#structure">structure</a>.</p>
52
53 <p>The two phases generating header and trailer are not covered here
54 as their implementation trivially follows directly from the
55 specification of the <a href="delta_format.html">delta format</a>.</p>
56
57 <p>This leaves the segment-list. Its generation is done in two phases,
58 a pre-processing step operating on the "original" byte-sequence,
59 followed by the processing of the "target" byte-sequence using the
60 information gathered by the first step.</p>
61
62 <a name="preprocessing"><h3>2.1 Preprocessing the original</h3>
63
64 <p>A major part of the processing of the "target" is to find a range
65 in the "original" which contains the same content as found at the
66 current location in the "target".</p>
67
68 <p>A naive approach to this would be to search the whole "original"
69 for such content. This however is very inefficient as it would search
70 the same parts of the "original" over and over. What is done instead
71 is to sample the "original" at regular intervals, compute signatures
72 for the sampled locations and store them in a hash table keyed by
73 these signatures.</p>
74
75 <p>That is what happens in this step. The following processing step
76 can then the compute signature for its current location and then has
77 to search only a narrow set of locations in the "original" for
78 possible matches, namely those which have the same signature.</p>
79
80 <p>In detail:</p>
81
82 <ol>
83 <li>The "original" is split into chunks of NHASH bytes. Note that a
84 partial chunk of less than NHASH bytes at the end of "original" is
85 ignored.
86 </li>
87 <li>The <a href="#rollhash">rolling hash</a> of each chunk is
88 computed.
89 </li>
90 <li>A hashtable is filled, mapping from the hashes of the chunks to
91 the list of chunk locations having this hash.
92 </li>
93 </ol>
94
95 <a name="processing"><h3>2.1 Processing the target</h3>
96
97 <p>This, the main phase of the encoder, processes the target in a loop
98 from beginning to end. The state of the encoder is captured by two
99 locations, the "base" and the "slide". "base" points to the first byte
100 of the target for which no delta output has been generated yet, and
101 "slide" is the location of the window used to look in the "origin" for
102 commonalities. This window is NHASH bytes long.</p>
103
104 <p>Initially both "base" and "slide" point to the beginning of the
105 "target". In each iteration of the loop the encoder decides whether to
106 <ul>
107 <li>emit a single instruction
108 to <a href="delta_format.html#copyrange">copy a range</a>, or
109 </li>
110 <li>emit two instructions, first
111 to <a href="delta_format.html#insertlit">insert a literal</a>, then
112 to <a href="delta_format.html#copyrange">copy a range</a>, or
113 </li>
114 <li>move the window forward one byte.
115 </li>
116 </ul>
117 </p>
118
119 <img src="encode10.gif" align="right" hspace="10">
120 <p>To make this decision the encoder first computes the hash value for
121 the NHASH bytes in the window and then looks at all the locations in
122 the "origin" which have the same signature. This part uses the hash
123 table created by the pre-processing step to effiently find these
124 locations.</p>
125
126 <p>For each of the possible candidates the encoder finds the maximal
127 range of bytes common to both "origin" and "target", going forward and
128 backward from "slide" in the "target", and the candidate location in
129 the "origin". This search is constrained on the side of the "target"
130 by the "base" (backward search), and the end of the "target" (forward
131 search), and on the side of the "origin" by the beginning and end of
132 the "origin", respectively.</p>
133
134 <p>There are input files for which the hash chains generated by the
135 pre-processing step can become very long, leading to long search times
136 and affecting the performance of the delta generator. To limit the
137 effect such long chains can have the actual search for candidates is
138 bounded, looking at most N candidates. Currently N is set to 250.</p>
139
140 <p>From the ranges for all the candidates the best (= largest) common
141 range is taken and it is determined how many bytes are needed to
142 encode the bytes between the "base" and the end of that range. If the
143 range extended back to the "base" then this can be done in a single
144 copy instruction. Otherwise, i.e if there is a gap between the "base"
145 and the beginning of the range then two instructions are needed, one
146 to insert the bytes in the gap as a literal, and a copy instruction
147 for the range itself. The general situation at this point can be seen
148 in the picture to the right.</p>
149
150 <p>If the number of bytes needed to encode both gap (if present), and
151 range is less than the number of bytes we are encoding the encoder
152 will emit the necessary instructions as described above, set "base"
153 and "slide" to the end of the encoded range and start the next
154 iteration at that point.</p>
155
156 <p>If, on the other hand, the encoder either did not find candidate
157 locations in the origin, or the best range coming out of the search
158 needed more bytes to encode the range than there were bytes in the
159 range, then no instructions are emitted and the window is moved one
160 byte forward. The "base" is left unchanged in that case.</p>
161
162 <p>The processing loop stops at one of two conditions:
163 <ol>
164 <li>The encoder decided to move the window forward, but the end of the
165 window reached the end of the "target".
166 </li>
167 <li>After the emission of instructions the new "base" location is
168 within NHASH bytes of end of the "target", i.e. there are no more than
169 at most NHASH bytes left.
170 </li>
171 </ol>
172 </p>
173
174 <p>If the processing loop left bytes unencoded, i.e. "base" not
175 exactly at the end of the "target", as is possible for both end
176 conditions, then one last insert instruction is emitted to put these
177 bytes into the delta.<p>
178
179 <a name="exceptions"><h2>3.0 Exceptions</h2>
180
181 <p>If the "original" is at most NHASH bytes long no compression of
182 changes is possible, and the segment-list of the delta consists of a
183 single literal which contains the entire "target".</p>
184
185 <p>This is actually equivalent to the second end condition of the
186 processing loop described in the previous section, just checked before
187 actually entering the loop.</p>
188
189 <a name="rollhash"><h2>4.0 The rolling hash</h2>
190
191 <p>The rolling hash described below and used to compute content
192 signatures was chosen not only for good hashing properties, but also
193 to enable the easy (incremental) recalculation of its value for a
194 sliding window, i.e. where the oldest byte is removed from the window
195 and a new byte is shifted in.<p>
196
197 <a name="rhdef"><h3>4.1 Definition</h3>
198
199 <p>Assuming an array Z of NHASH bytes (indexing starting at 0) the
200 hash V is computed via</p>
201
202 <p align=center><table><tr><td>
203 <p><img src="encode1.gif" align="center"></p>
204 <p><img src="encode2.gif" align="center"></p>
205 <p><img src="encode3.gif" align="center"></p>
206 </td></tr></table></p>
207
208 where A and B are unsigned 16-bit integers (hence the <u>mod</u>), and
209 V is a 32-bit unsigned integer with B as MSB, A as LSB.
210
211 <a name="rhincr"><h3>4.2 Incremental recalculation</h3>
212
213 <p>Assuming an array Z of NHASH bytes (indexing starting at 0) with
214 hash V (and components A and B), the dropped
215 byte <img src="encode4.gif" align="center">, and the new byte
216 <img src="encode5.gif" align="center"> , the new hash can
217 be computed incrementally via: </p>
218
219 <p align=center><table><tr><td>
220 <p><img src="encode6.gif" align="center"></p>
221 <p><img src="encode7.gif" align="center"></p>
222 <p><img src="encode8.gif" align="center"></p>
223 </td></tr></table></p>
224
225 <p>For A, the regular sum, it can be seen easily that this the correct
226 way recomputing that component.</p>
227
228 <p>For B, the weighted sum, note first that <img src="encode4.gif"
229 align="center"> has the weight NHASH in the sum, so that is what has
230 to be removed. Then adding in <img src="encode9.gif" align="center">
231 adds one weight factor to all the other values of Z, and at last adds
232 in <img src="encode5.gif" align="center"> with weight 1, also
233 generating the correct new sum</p>
234
235 </body>
236 </html>
--- a/www/delta_encoder_algorithm.html
+++ b/www/delta_encoder_algorithm.html
@@ -1,236 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/delta_encoder_algorithm.wiki
+6
--- a/www/delta_encoder_algorithm.wiki
+++ b/www/delta_encoder_algorithm.wiki
@@ -0,0 +1,6 @@
1
+<h1
2
+Fossil Delta <nowiki>Encoding A
3
+</h1>
4
+
5
+<p>A key component for the efficient storage of multiple revisions of
6
+a file in fossil repositories is the
--- a/www/delta_encoder_algorithm.wiki
+++ b/www/delta_encoder_algorithm.wiki
@@ -0,0 +1,6 @@
 
 
 
 
 
 
--- a/www/delta_encoder_algorithm.wiki
+++ b/www/delta_encoder_algorithm.wiki
@@ -0,0 +1,6 @@
1 <h1
2 Fossil Delta <nowiki>Encoding A
3 </h1>
4
5 <p>A key component for the efficient storage of multiple revisions of
6 a file in fossil repositories is the
D www/delta_format.html
-222
--- a/www/delta_format.html
+++ b/www/delta_format.html
@@ -1,223 +0,0 @@
1
-<html>
2
-<head>
3
-<title>Fossil Delta Format</title>
4
-</head>
5
-<body bgcolor="white">
6
-<p>[ <a href="index.html">Index</a> ]</p>
7
-<hr>
8
-<h1 align="center">
9
-Fossil Delta Format
10
-</h1>
11
-
12
-<p>A key component for the efficient storage of multiple revisions of
13
-a file in fossil repositories is the use of delta-compression, i.e. to
14
-store only the changes between revisions instead of the whole
15
-file.</p>
16
-
17
-<p>This document describes the format used to encode such changes,
18
-also known as "delta". It is targeted at developers working on either
19
-<a href="index.html">fossil</a> itself, or on tools compatible with
20
-it.</p>
21
-
22
-<a name="structure"><h2>1.0 Structure</h2>
23
-<img src="delta1.gif" align="left" hspace="10">
24
-
25
-<p>A delta consists of three parts, a "header", a "trailer", and a
26
-"segment-list" between them.</p>
27
-
28
-<p>Both header and trailer provide information about the target
29
-helping the decoder, and the segment-list describes how the target can
30
-be constructed from the original.</p>
31
-
32
-<a name="header"><h3>1.1 Header</h3>
33
-<img src="delta6.gif" align="left" hspace="10">
34
-
35
-<p>The header consists of a single number followed by a newline
36
-character (ASCII 0x0a). The number is the length of the target in
37
-bytes.</p>
38
-
39
-<p>This means that, given a delta, the decoder can compute the size of
40
-the target (and allocate any necessary memory based on that) by simply
41
-reading the first line of the delta and decoding the number found
42
-there. In other words, before it has to decode everything else.</p>
43
-
44
-<a name="trailer"><h3>1.2 Trailer</h3>
45
-<img src="delta5.gif" align="left" hspace="10">
46
-
47
-<p>The trailer consists of a single number followed by a semicolon (ASCII
48
-0x3b). This number is a checksum of the target and can be used by a
49
-decoder to verify that the delta applied correctly, reconstructing the
50
-target from the original.</p>
51
-
52
-<p>The checksum is computed by treating the target as a series of
53
-32-bit integer numbers (MSB first), and summing these up, modulo
54
-2^32-1. A target whose length is not a multiple of 4 is padded with
55
-0-bytes (ASCII 0x00) at the end.</p>
56
-
57
-<p>By putting this information at the end of the delta a decoder has
58
-it available immediately after the target has been reconstructed
59
-fully.</p>
60
-
61
-<a name="slist"><h3>1.3 Segment-List</h3>
62
-<img src="delta2.gif" align="left" hspace="10">
63
-
64
-<p>The segment-list of a delta describes how to create the target from
65
-the original by a combination of inserting literal byte-sequences and
66
-copying ranges of bytes from the original. This is there the
67
-compression takes place, by encoding the large common parts of
68
-original and target in small copy instructions.</p>
69
-
70
-<p>The target is constructed from beginning to end, with the data
71
-generated by each instruction appended after the data of all previous
72
-instructions, with no gaps.</p>
73
-
74
-<a name="insertlit"><h4>1.3.1 Insert Literal</h4>
75
-
76
-<p>A literal is specified by two elements, the size of the literal in
77
-bytes, and the bytes of the literal itself.</p>
78
-
79
-<img src="delta4.gif" align="left" hspace="10">
80
-<p>The length is written first, followed by a colon character (ASCII
81
-0x3a), followed by the bytes of the literal.</p>
82
-
83
-<a name="copyrange"><h4>1.3.2 Copy Range</h4>
84
-
85
-<p>A range to copy is specified by two numbers, the offset of the
86
-first byte in the original to copy, and the size of the range, in
87
-bytes. The size zero is special, its usage indicates that the range
88
-extends to the end of the original.</p>
89
-
90
-<img src="delta3.gif" align="left" hspace="10">
91
-<p>The length is written first, followed by an "at" character (ASCII
92
-0x40), then the offset, followed by a comma (ASCII 0x2c).</p>
93
-
94
-<a name="intcoding"><h2>2.0 Encoding of integers</h2>
95
-
96
-<p>
97
-The format currently handles only 32 bit integer numbers. They are
98
-written base-64 encoded, MSB first, and without leading
99
-"0"-characters, except if they are significant (i.e. 0 => "0").
100
-</p>
101
-
102
-<p>
103
-The base-64 coding is described in
104
-<a href="http://www.ietf.org/rfc/rfc3548.txt">RFC 3548</a>.
105
-</p>
106
-
107
-<a name="examples"><h2>3.0 Examples</h2>
108
-
109
-<a name="examplesint"><h3>3.1 Integer encoding</h3>
110
-
111
-<table border=1>
112
-<tr>
113
-<th>Value</th>
114
-<th>Encoding</th>
115
-</tr>
116
-<tr>
117
-<td>0</td>
118
-<td>0</td>
119
-</tr>
120
-<tr>
121
-<td>6246</td>
122
-<td>1Xb</td>
123
-</tr>
124
-<tr>
125
-<td>-1101438770</td>
126
-<td>2zMM3E</td>
127
-</tr>
128
-</table>
129
-
130
-<a name="examplesdelta"><h3>3.2 Delta encoding</h3>
131
-
132
-<p>An example of a delta using the specified encoding is:</p>
133
-
134
-<table border=1><tr><td><pre>
135
-1Xb
136
-4E@0,2:thFN@4C,6:scenda1B@Jd,6:scenda5x@Kt,6:pieces79@Qt,F: Example: eskil~E@Y0,2zMM3E;</pre>
137
-</td></tr></table>
138
-
139
-<p>This can be taken apart into the following parts:</p>
140
-
141
-<table border=1>
142
-<tr><th>What </th> <th>Encoding </th><th>Meaning </th><th>Details</th></tr>
143
-<tr><td>Header</td> <td>1Xb </td><td>Size </td><td> 6246 </td></tr>
144
-<tr><td>S-List</td> <td>4E@0, </td><td>Copy </td><td> 270 @ 0 </td></tr>
145
-<tr><td>&nbsp;</td> <td>2:th </td><td>Literal </td><td> 2 'th' </td></tr>
146
-<tr><td>&nbsp;</td> <td>FN@4C, </td><td>Copy </td><td> 983 @ 268 </td></tr>
147
-<tr><td>&nbsp;</td> <td>6:scenda </td><td>Literal </td><td> 6 'scenda' </td></tr>
148
-<tr><td>&nbsp;</td> <td>1B@Jd, </td><td>Copy </td><td> 75 @ 1256 </td></tr>
149
-<tr><td>&nbsp;</td> <td>6:scenda </td><td>Literal </td><td> 6 'scenda' </td></tr>
150
-<tr><td>&nbsp;</td> <td>5x@Kt, </td><td>Copy </td><td> 380 @ 1336 </td></tr>
151
-<tr><td>&nbsp;</td> <td>6:pieces </td><td>Literal </td><td> 6 'pieces' </td></tr>
152
-<tr><td>&nbsp;</td> <td>79@Qt, </td><td>Copy </td><td> 457 @ 1720 </td></tr>
153
-<tr><td>&nbsp;</td> <td>F: Example: eskil</td><td>Literal </td><td> 15 ' Example: eskil'</td></tr>
154
-<tr><td>&nbsp;</td> <td>~E@Y0, </td><td>Copy </td><td> 4046 @ 2176 </td></tr>
155
-<tr><td>Trailer</td><td>2zMM3E </td><td>Ckecksum</td><td> -1101438770 </td></tr>
156
-</table>
157
-
158
-<p>The unified diff behind the above delta is</p>
159
-
160
-<table border=1><tr><td><pre>
161
-bluepeak:(761) ~/Projects/Tcl/Fossil/Devel/devel > diff -u ../DELTA/old ../DELTA/new
---- ../DELTA/old 2007-08-23 21:14:40.000000000 -0700
162
-+++ ../DELTA/new 2007-08-23 21:14:33.000000000 -0700
163
-@@ -5,7 +5,7 @@
164
-
165
- * If the server does not have write permission on the database
166
- file, or on the directory containing the database file (and
167
-- it is thus unable to update database because it cannot create
168
-+ it is thus unable to update the database because it cannot create
169
- a rollback journal) then it currently fails silently on a push.
170
- It needs to return a helpful error.
171
-
172
-@@ -27,8 +27,8 @@
173
- * Additional information displayed for the "vinfo" page:
174
-
175
- + All leaves of this version that are not included in the
176
-- decendant list. With date, user, comment, and hyperlink.
177
-- Leaves in the decendant table should be marked as such.
178
-+ descendant list. With date, user, comment, and hyperlink.
179
-+ Leaves in the descendant table should be marked as such.
180
- See the compute_leaves() function to see how to find all
181
- leaves.
182
- + Add file diff links to the file change list.
183
-@@ -37,7 +37,7 @@
184
-
185
- * The /xfer handler (for push, pull, and clone) does not do
186
- delta compression. This results in excess bandwidth usage.
187
-- There are some code in xfer.c that are sketches of ideas on
188
-+ There are some pieces in xfer.c that are sketches of ideas on
189
- how to do delta compression, but nothing has been implemented.
190
-
191
- * Enhancements to the diff and tkdiff commands in the cli.
192
-@@ -45,7 +45,7 @@
193
- single file. Allow diffs against any two arbitrary versions,
194
- not just diffs against the current check-out. Allow
195
- configuration options to replace tkdiff with some other
196
-- visual differ of the users choice.
197
-+ visual differ of the users choice. Example: eskil.
198
-
199
- * Ticketing interface (expand this bullet)
200
-
201
-</pre></td></tr></table>
202
-
203
-
204
-
205
-<a name="notes"><h2>Notes</h2>
206
-
207
-<ul>
208
-<li>Pure text files generate a pure text delta.
209
-</li>
210
-<li>Binary files generate a delta that may contain some binary data.
211
-</li>
212
-<li>Instead of putting special instructions for general compression
213
-into the delta-format itself, specifically the segment-list, like
214
-run-length encoding of literals, etc. it was considered to be much
215
-more sensible to keep the various concern separate and use a general
216
-compression library, like <a href="http://www.zlib.net">zlib</a>, to
217
-compress the full delta after its generation.
218
-</li>
219
-</ul>
220
-
221
-</body>
222
-</html>
--- a/www/delta_format.html
+++ b/www/delta_format.html
@@ -1,223 +0,0 @@
1 <html>
2 <head>
3 <title>Fossil Delta Format</title>
4 </head>
5 <body bgcolor="white">
6 <p>[ <a href="index.html">Index</a> ]</p>
7 <hr>
8 <h1 align="center">
9 Fossil Delta Format
10 </h1>
11
12 <p>A key component for the efficient storage of multiple revisions of
13 a file in fossil repositories is the use of delta-compression, i.e. to
14 store only the changes between revisions instead of the whole
15 file.</p>
16
17 <p>This document describes the format used to encode such changes,
18 also known as "delta". It is targeted at developers working on either
19 <a href="index.html">fossil</a> itself, or on tools compatible with
20 it.</p>
21
22 <a name="structure"><h2>1.0 Structure</h2>
23 <img src="delta1.gif" align="left" hspace="10">
24
25 <p>A delta consists of three parts, a "header", a "trailer", and a
26 "segment-list" between them.</p>
27
28 <p>Both header and trailer provide information about the target
29 helping the decoder, and the segment-list describes how the target can
30 be constructed from the original.</p>
31
32 <a name="header"><h3>1.1 Header</h3>
33 <img src="delta6.gif" align="left" hspace="10">
34
35 <p>The header consists of a single number followed by a newline
36 character (ASCII 0x0a). The number is the length of the target in
37 bytes.</p>
38
39 <p>This means that, given a delta, the decoder can compute the size of
40 the target (and allocate any necessary memory based on that) by simply
41 reading the first line of the delta and decoding the number found
42 there. In other words, before it has to decode everything else.</p>
43
44 <a name="trailer"><h3>1.2 Trailer</h3>
45 <img src="delta5.gif" align="left" hspace="10">
46
47 <p>The trailer consists of a single number followed by a semicolon (ASCII
48 0x3b). This number is a checksum of the target and can be used by a
49 decoder to verify that the delta applied correctly, reconstructing the
50 target from the original.</p>
51
52 <p>The checksum is computed by treating the target as a series of
53 32-bit integer numbers (MSB first), and summing these up, modulo
54 2^32-1. A target whose length is not a multiple of 4 is padded with
55 0-bytes (ASCII 0x00) at the end.</p>
56
57 <p>By putting this information at the end of the delta a decoder has
58 it available immediately after the target has been reconstructed
59 fully.</p>
60
61 <a name="slist"><h3>1.3 Segment-List</h3>
62 <img src="delta2.gif" align="left" hspace="10">
63
64 <p>The segment-list of a delta describes how to create the target from
65 the original by a combination of inserting literal byte-sequences and
66 copying ranges of bytes from the original. This is there the
67 compression takes place, by encoding the large common parts of
68 original and target in small copy instructions.</p>
69
70 <p>The target is constructed from beginning to end, with the data
71 generated by each instruction appended after the data of all previous
72 instructions, with no gaps.</p>
73
74 <a name="insertlit"><h4>1.3.1 Insert Literal</h4>
75
76 <p>A literal is specified by two elements, the size of the literal in
77 bytes, and the bytes of the literal itself.</p>
78
79 <img src="delta4.gif" align="left" hspace="10">
80 <p>The length is written first, followed by a colon character (ASCII
81 0x3a), followed by the bytes of the literal.</p>
82
83 <a name="copyrange"><h4>1.3.2 Copy Range</h4>
84
85 <p>A range to copy is specified by two numbers, the offset of the
86 first byte in the original to copy, and the size of the range, in
87 bytes. The size zero is special, its usage indicates that the range
88 extends to the end of the original.</p>
89
90 <img src="delta3.gif" align="left" hspace="10">
91 <p>The length is written first, followed by an "at" character (ASCII
92 0x40), then the offset, followed by a comma (ASCII 0x2c).</p>
93
94 <a name="intcoding"><h2>2.0 Encoding of integers</h2>
95
96 <p>
97 The format currently handles only 32 bit integer numbers. They are
98 written base-64 encoded, MSB first, and without leading
99 "0"-characters, except if they are significant (i.e. 0 => "0").
100 </p>
101
102 <p>
103 The base-64 coding is described in
104 <a href="http://www.ietf.org/rfc/rfc3548.txt">RFC 3548</a>.
105 </p>
106
107 <a name="examples"><h2>3.0 Examples</h2>
108
109 <a name="examplesint"><h3>3.1 Integer encoding</h3>
110
111 <table border=1>
112 <tr>
113 <th>Value</th>
114 <th>Encoding</th>
115 </tr>
116 <tr>
117 <td>0</td>
118 <td>0</td>
119 </tr>
120 <tr>
121 <td>6246</td>
122 <td>1Xb</td>
123 </tr>
124 <tr>
125 <td>-1101438770</td>
126 <td>2zMM3E</td>
127 </tr>
128 </table>
129
130 <a name="examplesdelta"><h3>3.2 Delta encoding</h3>
131
132 <p>An example of a delta using the specified encoding is:</p>
133
134 <table border=1><tr><td><pre>
135 1Xb
136 4E@0,2:thFN@4C,6:scenda1B@Jd,6:scenda5x@Kt,6:pieces79@Qt,F: Example: eskil~E@Y0,2zMM3E;</pre>
137 </td></tr></table>
138
139 <p>This can be taken apart into the following parts:</p>
140
141 <table border=1>
142 <tr><th>What </th> <th>Encoding </th><th>Meaning </th><th>Details</th></tr>
143 <tr><td>Header</td> <td>1Xb </td><td>Size </td><td> 6246 </td></tr>
144 <tr><td>S-List</td> <td>4E@0, </td><td>Copy </td><td> 270 @ 0 </td></tr>
145 <tr><td>&nbsp;</td> <td>2:th </td><td>Literal </td><td> 2 'th' </td></tr>
146 <tr><td>&nbsp;</td> <td>FN@4C, </td><td>Copy </td><td> 983 @ 268 </td></tr>
147 <tr><td>&nbsp;</td> <td>6:scenda </td><td>Literal </td><td> 6 'scenda' </td></tr>
148 <tr><td>&nbsp;</td> <td>1B@Jd, </td><td>Copy </td><td> 75 @ 1256 </td></tr>
149 <tr><td>&nbsp;</td> <td>6:scenda </td><td>Literal </td><td> 6 'scenda' </td></tr>
150 <tr><td>&nbsp;</td> <td>5x@Kt, </td><td>Copy </td><td> 380 @ 1336 </td></tr>
151 <tr><td>&nbsp;</td> <td>6:pieces </td><td>Literal </td><td> 6 'pieces' </td></tr>
152 <tr><td>&nbsp;</td> <td>79@Qt, </td><td>Copy </td><td> 457 @ 1720 </td></tr>
153 <tr><td>&nbsp;</td> <td>F: Example: eskil</td><td>Literal </td><td> 15 ' Example: eskil'</td></tr>
154 <tr><td>&nbsp;</td> <td>~E@Y0, </td><td>Copy </td><td> 4046 @ 2176 </td></tr>
155 <tr><td>Trailer</td><td>2zMM3E </td><td>Ckecksum</td><td> -1101438770 </td></tr>
156 </table>
157
158 <p>The unified diff behind the above delta is</p>
159
160 <table border=1><tr><td><pre>
161 bluepeak:(761) ~/Projects/Tcl/Fossil/Devel/devel > diff -u ../DELTA/old ../DELTA/new
---- ../DELTA/old 2007-08-23 21:14:40.000000000 -0700
162 +++ ../DELTA/new 2007-08-23 21:14:33.000000000 -0700
163 @@ -5,7 +5,7 @@
164
165 * If the server does not have write permission on the database
166 file, or on the directory containing the database file (and
167 - it is thus unable to update database because it cannot create
168 + it is thus unable to update the database because it cannot create
169 a rollback journal) then it currently fails silently on a push.
170 It needs to return a helpful error.
171
172 @@ -27,8 +27,8 @@
173 * Additional information displayed for the "vinfo" page:
174
175 + All leaves of this version that are not included in the
176 - decendant list. With date, user, comment, and hyperlink.
177 - Leaves in the decendant table should be marked as such.
178 + descendant list. With date, user, comment, and hyperlink.
179 + Leaves in the descendant table should be marked as such.
180 See the compute_leaves() function to see how to find all
181 leaves.
182 + Add file diff links to the file change list.
183 @@ -37,7 +37,7 @@
184
185 * The /xfer handler (for push, pull, and clone) does not do
186 delta compression. This results in excess bandwidth usage.
187 - There are some code in xfer.c that are sketches of ideas on
188 + There are some pieces in xfer.c that are sketches of ideas on
189 how to do delta compression, but nothing has been implemented.
190
191 * Enhancements to the diff and tkdiff commands in the cli.
192 @@ -45,7 +45,7 @@
193 single file. Allow diffs against any two arbitrary versions,
194 not just diffs against the current check-out. Allow
195 configuration options to replace tkdiff with some other
196 - visual differ of the users choice.
197 + visual differ of the users choice. Example: eskil.
198
199 * Ticketing interface (expand this bullet)
200
201 </pre></td></tr></table>
202
203
204
205 <a name="notes"><h2>Notes</h2>
206
207 <ul>
208 <li>Pure text files generate a pure text delta.
209 </li>
210 <li>Binary files generate a delta that may contain some binary data.
211 </li>
212 <li>Instead of putting special instructions for general compression
213 into the delta-format itself, specifically the segment-list, like
214 run-length encoding of literals, etc. it was considered to be much
215 more sensible to keep the various concern separate and use a general
216 compression library, like <a href="http://www.zlib.net">zlib</a>, to
217 compress the full delta after its generation.
218 </li>
219 </ul>
220
221 </body>
222 </html>
--- a/www/delta_format.html
+++ b/www/delta_format.html
@@ -1,223 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
---- ../DELTA/old 2007-08-23 21:14:40.000000000 -0700
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/delta_format.wiki
+120
--- a/www/delta_format.wiki
+++ b/www/delta_format.wiki
@@ -0,0 +1,120 @@
1
+<h1 align="centerit<p><A key component for the efficient storage of multiple revisions of
2
+a file in fossil repositories ishe intended audience is devel, i.e. to
3
+store only the changes between revisions instead of the whole
4
+file.ired for
5
+oformat used to encode such changes,
6
+also known as "delta". It is targeted atate document] defohtmls document iis not a fitn="centerit<p></p>
7
+
8
+<p>ve to<nowiki>
9
+<h1 align="centerit<p></p>
10
+
11
+<p>ve to a related artifact.
12
+
13
+This document describes the delta-encoding format used by Fossil.
14
+The intended audience is developers working on eitfsil</a> itself, or on tools compatible with
15
+Fossil. Understanding of this document is <em>not</em> required for
16
+ordinary users of Fossil. Thifcument onl fossil that used a different delta-encoding
17
+or did no This document iat all. However,l. This document idescribed here is both efficient to compute and
18
+results in very small deltas, so its continly
19
+a name="structure"></a><h2>1.0 Structure</h2>
20
+<img src="delta1.gif" align="left" hspace="10"a delta that converts file X into file Y. Output that delta.
21
+
22
+ * [/help?cmd=lp/test-delta-ap* [/help/test-delta-apply|fossil test-delta-apply X D] &rarr; apply
23
+ delta D?cmd=telta-analyze X Y] &rarr; compute
24
+ a name="header"></a><h3>1.1 Header</h3>
25
+<img src="delta6.gif" align="left" hspace="10"interactive SQL session connected to the repository, the following
26
+additional SQL functions are provided:
27
+
28
+ * <b>delta_create(</b><i>X</i><b>,</b><i>Y</i><b>)</b> &rarr;
29
+ Compute a data that carries blob X into blob Y and return that delta
30
+ as a blob.
31
+
32
+ * <b>delta_apply(</b><i>X</i><b>,</b><i>D</i><b>)</b> &rarr;
33
+ a name="trailer"></a><h2 blob which is the result.
34
+
35
+
36
+ * <b>delta_output_s3>1.2 Trailer</h3>
37
+<img src="delta5.gif" align="left" hspace="10"; This is a table-valued function
38
+ that returns one row for the header, for the trailer, and for each s Thifcument only describes the delta file format. A
39
+[./delta_encoder_algorithm.wiki|sfparate document] defossil.</p>
40
+
41
+<p>Note thatil. This document iis not a fundamental element of the
42
+state of a fossil repository. A state of a fossil tepository is
43
+defined by the uncompressed and undeltaed content of all artifacts.
44
+The fact the artifacts
45
+are stored on disk using this This document i</p>
46
+
47
+<is merely an
48
+optimization. One could, in theory, create an entirely new and
49
+compatible implementation of fossil that used a different delta-encoding
50
+or did no This document iat all. Horit<p></p>
51
+
52
+<p>ve to a related artifact.
53
+
54
+This document describes the delta-encoding format used by Fossil.
55
+The intended audience is developers working on eitfsil</a> itself, or on tools compatible with
56
+Fossil. Understanding of this document is <em>not</em> required for
57
+ordinary users of Fossil. Thifcument only describes the delta fil<nowiki>
58
+<h1 align="centerit<p></p>
59
+
60
+<p>ve to a related artifact.
61
+
62
+This document describes the delta-encoding format used by Fossil.
63
+The intended audience is developers working on eitfsil</a> itself, or on tools compatible with
64
+Fossil. Understanding of this document is <em>not</em> required for
65
+ordinary users of Fossil. Thifcument only describes the delta file format. A
66
+[./delta_encoder_algorithm.wiki|sfparate document] defossil.</p>
67
+
68
+<p>Note thatil. This docuy two<p> elements, of integers</h2s border=1of the literal </p> leftmargin = 0.1
69
+ box "Length" height 50%
70
+ box "\"@\"" same
71
+ box "Offset" sa and low-bandwidt<tin first, followed by a colon character (ASCII
72
+0x3a), followed by ed in
73
+<a href="http://www.ietf.org/rfc/rfc3548.txt">RFC 3548</a>.
74
+</pe2>3.0 Examples</h2ribes the delta-enco<title>Fossil
75
+ PART2: [
76
+ ""
77
+ box "Length" height 50%
78
+ right
79
+ box "\":\"" same
80
+ box "Bytes" same
81
+ </p>
82
+
83
+<p>/verbatim>
84
+
85
+The segment-list of a delta describes how to create the target from
86
+3tended audience is <title>Fossil Delta Format</tit<p></p>
87
+
88
+<p>ve to a related artifact.
89
+
90
+This document describes the delta-encoding format used by Fossil.
91
+The intended audience is developers working on either
92
+<a href="index3>3.2 Delta encoding</h3and
93
+copying ranges of bytes from the <p>akes place, by encoding the large common parts of
94
+original and target in small copy instructions.
95
+
96
+The target is coh no gaps.
97
+
98
+<h3 id="insertlitbes the delta-encoding fo<nowiki>
99
+<h1 + copy instructions.
100
+
101
+The target is constructed from beginning to en+by each instruction appended after the data of all previous
102
+instrteral in
103
+ length is written firstS-List</td
104
+- writ2 'th' length is wrFN@4C, </p> by two elemen length is wr1s writ2 'th' length is wrFN@4C, 983 @ 268 length is wrpecified </p> by two elemen length is wr1B@Jd, 75 @ 1256 length is wrpecified </p> by two elemen 1336 length is wr6:pieces irst, followed by a colon ch6 'pieces' length is wr itten 457 @ 1720 length is wrcopy is specified b2>Notes</h2s, except if they are significant (i.e. 0 => "0").
105
+
106
+The base-64 encoding uses one character for each 6 bits of
107
+the integer to be encoded. The encoding characters are:
108
+
109
+<pre>
110
+0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~
111
+</pre>
112
+
113
+The least significant 6 bits of the integer are encoded by
114
+the first character, followed by
115
+the nex delta-encoding format used by Fossil.
116
+The intended audience is developers working on eitfsil</a> itself, or on tools compatible with
117
+Fossil. Understanding of this document is <em>not</em> required for
118
+ordinary users of Fossil. Thifcument onInstead of putting special instructions for general compression
119
+into the delta-format itself, specifically the segment-list, like
120
+run-length ekeep the various concern
--- a/www/delta_format.wiki
+++ b/www/delta_format.wiki
@@ -0,0 +1,120 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--- a/www/delta_format.wiki
+++ b/www/delta_format.wiki
@@ -0,0 +1,120 @@
1 <h1 align="centerit<p><A key component for the efficient storage of multiple revisions of
2 a file in fossil repositories ishe intended audience is devel, i.e. to
3 store only the changes between revisions instead of the whole
4 file.ired for
5 oformat used to encode such changes,
6 also known as "delta". It is targeted atate document] defohtmls document iis not a fitn="centerit<p></p>
7
8 <p>ve to<nowiki>
9 <h1 align="centerit<p></p>
10
11 <p>ve to a related artifact.
12
13 This document describes the delta-encoding format used by Fossil.
14 The intended audience is developers working on eitfsil</a> itself, or on tools compatible with
15 Fossil. Understanding of this document is <em>not</em> required for
16 ordinary users of Fossil. Thifcument onl fossil that used a different delta-encoding
17 or did no This document iat all. However,l. This document idescribed here is both efficient to compute and
18 results in very small deltas, so its continly
19 a name="structure"></a><h2>1.0 Structure</h2>
20 <img src="delta1.gif" align="left" hspace="10"a delta that converts file X into file Y. Output that delta.
21
22 * [/help?cmd=lp/test-delta-ap* [/help/test-delta-apply|fossil test-delta-apply X D] &rarr; apply
23 delta D?cmd=telta-analyze X Y] &rarr; compute
24 a name="header"></a><h3>1.1 Header</h3>
25 <img src="delta6.gif" align="left" hspace="10"interactive SQL session connected to the repository, the following
26 additional SQL functions are provided:
27
28 * <b>delta_create(</b><i>X</i><b>,</b><i>Y</i><b>)</b> &rarr;
29 Compute a data that carries blob X into blob Y and return that delta
30 as a blob.
31
32 * <b>delta_apply(</b><i>X</i><b>,</b><i>D</i><b>)</b> &rarr;
33 a name="trailer"></a><h2 blob which is the result.
34
35
36 * <b>delta_output_s3>1.2 Trailer</h3>
37 <img src="delta5.gif" align="left" hspace="10"; This is a table-valued function
38 that returns one row for the header, for the trailer, and for each s Thifcument only describes the delta file format. A
39 [./delta_encoder_algorithm.wiki|sfparate document] defossil.</p>
40
41 <p>Note thatil. This document iis not a fundamental element of the
42 state of a fossil repository. A state of a fossil tepository is
43 defined by the uncompressed and undeltaed content of all artifacts.
44 The fact the artifacts
45 are stored on disk using this This document i</p>
46
47 <is merely an
48 optimization. One could, in theory, create an entirely new and
49 compatible implementation of fossil that used a different delta-encoding
50 or did no This document iat all. Horit<p></p>
51
52 <p>ve to a related artifact.
53
54 This document describes the delta-encoding format used by Fossil.
55 The intended audience is developers working on eitfsil</a> itself, or on tools compatible with
56 Fossil. Understanding of this document is <em>not</em> required for
57 ordinary users of Fossil. Thifcument only describes the delta fil<nowiki>
58 <h1 align="centerit<p></p>
59
60 <p>ve to a related artifact.
61
62 This document describes the delta-encoding format used by Fossil.
63 The intended audience is developers working on eitfsil</a> itself, or on tools compatible with
64 Fossil. Understanding of this document is <em>not</em> required for
65 ordinary users of Fossil. Thifcument only describes the delta file format. A
66 [./delta_encoder_algorithm.wiki|sfparate document] defossil.</p>
67
68 <p>Note thatil. This docuy two<p> elements, of integers</h2s border=1of the literal </p> leftmargin = 0.1
69 box "Length" height 50%
70 box "\"@\"" same
71 box "Offset" sa and low-bandwidt<tin first, followed by a colon character (ASCII
72 0x3a), followed by ed in
73 <a href="http://www.ietf.org/rfc/rfc3548.txt">RFC 3548</a>.
74 </pe2>3.0 Examples</h2ribes the delta-enco<title>Fossil
75 PART2: [
76 ""
77 box "Length" height 50%
78 right
79 box "\":\"" same
80 box "Bytes" same
81 </p>
82
83 <p>/verbatim>
84
85 The segment-list of a delta describes how to create the target from
86 3tended audience is <title>Fossil Delta Format</tit<p></p>
87
88 <p>ve to a related artifact.
89
90 This document describes the delta-encoding format used by Fossil.
91 The intended audience is developers working on either
92 <a href="index3>3.2 Delta encoding</h3and
93 copying ranges of bytes from the <p>akes place, by encoding the large common parts of
94 original and target in small copy instructions.
95
96 The target is coh no gaps.
97
98 <h3 id="insertlitbes the delta-encoding fo<nowiki>
99 <h1 + copy instructions.
100
101 The target is constructed from beginning to en+by each instruction appended after the data of all previous
102 instrteral in
103 length is written firstS-List</td
104 - writ2 'th' length is wrFN@4C, </p> by two elemen length is wr1s writ2 'th' length is wrFN@4C, 983 @ 268 length is wrpecified </p> by two elemen length is wr1B@Jd, 75 @ 1256 length is wrpecified </p> by two elemen 1336 length is wr6:pieces irst, followed by a colon ch6 'pieces' length is wr itten 457 @ 1720 length is wrcopy is specified b2>Notes</h2s, except if they are significant (i.e. 0 => "0").
105
106 The base-64 encoding uses one character for each 6 bits of
107 the integer to be encoded. The encoding characters are:
108
109 <pre>
110 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~
111 </pre>
112
113 The least significant 6 bits of the integer are encoded by
114 the first character, followed by
115 the nex delta-encoding format used by Fossil.
116 The intended audience is developers working on eitfsil</a> itself, or on tools compatible with
117 Fossil. Understanding of this document is <em>not</em> required for
118 ordinary users of Fossil. Thifcument onInstead of putting special instructions for general compression
119 into the delta-format itself, specifically the segment-list, like
120 run-length ekeep the various concern
D www/fileformat.html
-341
--- a/www/fileformat.html
+++ b/www/fileformat.html
@@ -1,341 +0,0 @@
1
-<html>
2
-<head>
3
-<title>Fossil File Format</title>
4
-</head>
5
-<body bgcolor="white">
6
-<p>[ <a href="index.html">Index</a> ]</p>
7
-<hr>
8
-<h1 align="center">
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
-
21
-<p>
22
-Each artifact in the repository is named by its SHA1 hash.
23
-No prefixes or meta information is added to a artifact before
24
-its hash is computed. The name of a artifact in the repository
25
-is exactly the same SHA1 hash that is computed by sha1sum
26
-on the file as it exists in your source tree.</p>
27
-
28
-<p>
29
-Some artifacts have a particular format which gives them special
30
-meaning to fossil. Fossil recognizes:</p>
31
-
32
-<ul>
33
-<li> Manifests </li>
34
-<li> Clusters </li>
35
-<li> Control Artifacts </li>
36
-<li> Wiki Pages </li>
37
-<li> Ticket Changes </li>
38
-</ul>
39
-
40
-<p>These five artifact types are described in the sequel.</p>
41
-
42
-<h2>1.0 The Manifest</h2>
43
-
44
-<p>A manifest defines a baseline or version of the project
45
-source tree. The manifest contains a list of artifacts for
46
-each file in the project and the corresponding filenames, as
47
-well as information such as parent baselines, the name of the
48
-programmer who created the baseline, the date and time when
49
-the baseline was created, and any check-in comments associated
50
-with the baseline.</p>
51
-
52
-<p>
53
-Any artifact in the repository that follows the syntactic rules
54
-of a manifest is a manifest. Note that a manifest can
55
-be both a real manifest and also a content file, though this
56
-is rare.
57
-</p>
58
-
59
-<p>
60
-A manifest is a text file. Newline characters
61
-(ASCII 0x0a) separate the file into "cards".
62
-Each card begins with a single
63
-character "card type". Zero or more arguments may follow
64
-the card type. All arguments are separated from each other
65
-and from the card-type character by a single space
66
-character. There is no surplus white space between arguments
67
-and no leading or trailing whitespace except for the newline
68
-character that acts as the card separator.
69
-</p>
70
-
71
-<p>
72
-All cards of the manifest occur in strict sorted lexicographical order.
73
-No card may be duplicated.
74
-The entire manifest may be PGP clear-signed, but otherwise it
75
-may contain no additional text or data beyond what is described here.
76
-</p>
77
-
78
-<p>
79
-Allowed cards in the manifest are as follows:
80
-</p>
81
-
82
-<blockquote>
83
-<b>C</b> <i>checkin-comment</i><br>
84
-<b>D</b> <i>time-and-date-stamp</i><br>
85
-<b>F</b> <i>filename</i> <i>SHA1-hash</i><br>
86
-<b>P</b> <i>SHA1-hash</i>+<br>
87
-<b>R</b> <i>repository-checksum</i><br>
88
-<b>U</b> <i>user-login</i><br>
89
-<b>Z</b> <i>manifest-checksum</i>
90
-</blockquote>
91
-
92
-<p>
93
-A manifest must have exactly one C-card. The sole argument to
94
-the C-card is a check-in comment that describes the check-in that
95
-the manifest defines. The check-in comment is text. The following
96
-escape sequences are applied to the text:
97
-A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
98
-newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
99
-(ASCII 0x5C) is represented as two backslashes "\\". Apart from
100
-space and newline, no other whitespace characters are allowed in
101
-the check-in comment. Nor are any unprintable characters allowed
102
-in the comment.
103
-</p>
104
-
105
-<p>
106
-A manifest must have exactly one D-card. The sole argument to
107
-the D-card is a date-time stamp in the ISO8601 format. The
108
-date and time should be in coordinated universal time (UTC).
109
-The format is:
110
-</p>
111
-
112
-<blockquote>
113
-<i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i>
114
-</blockquote>
115
-
116
-<p>
117
-A manifest has zero or more F-cards. Each F-card defines a file
118
-(other than the manifest itself) which is part of the baseline that
119
-the manifest defines. There are two arguments. The first argment
120
-is the pathname of the file in the baseline relative to the root
121
-of the project file hierarchy. No ".." or "." directories are allowed
122
-within the filename. Space characters are escaped as in C-card
123
-comment text. Backslash characters and newlines are not allowed
124
-within filenames. The directory separator character is a forward
125
-slash (ASCII 0x2F). The second argument to the F-card is the
126
-full 40-character lower-case hexadecimal SHA1 hash of the content
127
-artifact.
128
-</p>
129
-
130
-<p>
131
-A manifest has zero or one P-cards. Most manifests have one P-card.
132
-The P-card has a varying number of arguments that
133
-defines other manifests from which the current manifest
134
-is derived. Each argument is an 40-character lowercase
135
-hexadecimal SHA1 of the predecessor manifest. All arguments
136
-to the P-card must be unique to that line.
137
-The first predecessor is the direct ancestor of the manifest.
138
-Other arguments define manifests with which the first was
139
-merged to yield the current manifest. Most manifests have
140
-a P-card with a single argument. The first manifest in the
141
-project has no ancestors and thus has no P-card.
142
-</p>
143
-
144
-<p>
145
-A manifest may optionally have a single R-card. The R-card has
146
-a single argument which is the MD5 checksum of all files in
147
-the baseline except the manifest itself. The checksum is expressed
148
-as 32-characters of lowercase hexadecimal. The checksum is
149
-computed as follows: For each file in the baseline (except for
150
-the manifest itself) in strict sorted lexicographical order,
151
-take the pathname of the file relative to the root of the
152
-repository, append a single space (ASCII 0x20), the
153
-size of the file in ASCII decimal, a single newline
154
-character (ASCII 0x0A), and the complete text of the file.
155
-Compute the MD5 checksum of the the result.
156
-</p>
157
-
158
-<p>
159
-Each manifest has a single U-card. The argument to the U-card is
160
-the login of the user who created the manifest. The login name
161
-is encoded using the same character escapes as is used for the
162
-check-in comment argument to the C-card.
163
-</p>
164
-
165
-<p>
166
-A manifest has an option Z-card as its last line. The argument
167
-to the Z-card is a 32-character lowercase hexadecimal MD5 hash
168
-of all prior lines of the manifest up to and including the newline
169
-character that immediately preceeds the "Z". The Z-card is just
170
-a sanity check to prove that the manifest is well-formed and
171
-consistent.
172
-</p>
173
-
174
-<h2>2.0 Clusters</h2>
175
-
176
-<p>
177
-A cluster is a artifact that declares the existance of other artifacts.
178
-Clusters are used during repository synchronization to help
179
-reduce network traffic.
180
-</p>
181
-
182
-<p>
183
-Clusters follow a syntax that is very similar to manifests.
184
-A Cluster is a line-oriented text file. Newline characters
185
-(ASCII 0x0a) separate the artifact into cards. Each card begins with a single
186
-character "card type". Zero or more arguments may follow
187
-the card type. All arguments are separated from each other
188
-and from the card-type character by a single space
189
-character. There is no surplus white space between arguments
190
-and no leading or trailing whitespace except for the newline
191
-character that acts as the card separator.
192
-All cards of a cluter occur in strict sorted lexicographical order.
193
-No card may be duplicated.
194
-The cluster may not contain additional text or data beyond
195
-what is described here.
196
-Unlike manifests, clusters are never PGP signed.
197
-</p>
198
-
199
-<p>
200
-Allowed cards in the cluster are as follows:
201
-</p>
202
-
203
-<blockquote>
204
-<b>M</b> <i>uuid</i><br />
205
-<b>Z</b> <i>checksum</i>
206
-</blockquote>
207
-
208
-<p>
209
-A cluster contains one or more "M" cards followed by a single "Z"
210
-line. Each M card has a single argument which is the UUID of
211
-another artifact in the repository. The Z card work exactly like
212
-the Z card of a manifest. The argument to the Z card is the
213
-lower-case hexadecimal representation of the MD5 checksum of all
214
-prior cards in the cluster. Note that the Z card is required
215
-on a cluster.
216
-</p>
217
-
218
-
219
-<h2>3.0 Control Artifacts</h2>
220
-
221
-<p>
222
-Control artifacts are used to assign properties to other artifacts
223
-within the repository. The basic format of a control artifact is
224
-the same as a manifest or cluster. A control artifact is a text
225
-files divided into cards by newline characters. Each card has a
226
-single-character card type followed by arguments. Spaces separate
227
-the card type and the arguments. No surplus whitespace is allowed.
228
-All cards must occur in strict lexigraphical order.
229
-</p>
230
-
231
-<p>
232
-Allowed cards in a control artifact are as follows:
233
-</p>
234
-
235
-<blockquote>
236
-<b>D</b> <i>time-and-date-stamp</i><br />
237
-<b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name uuid ?value?</i><br />
238
-<b>Z</b> <i>checksum</i><br />
239
-</blockquote>
240
-
241
-<p>
242
-A control artifact must have one D card and one Z card and
243
-one or more or more T cards. No other cards or other text is
244
-allowed in a control artifact. Control artifacts might be PGP
245
-clearsigned.</p>
246
-
247
-<p>The D card and the Z card of a control artifact are the same
248
-as in a manifest.</p>
249
-
250
-<p>The T card represents a "tag" or property that is applied to
251
-some other artifact. The T card has two or three values. The
252
-second argument is the 40 character lowercase UUID of the artifact
253
-to which the tag is to be applied. The
254
-first value is the tag name. The first character of the tag
255
-is either "+", "-", or "*". A "+" means the tag should be added
256
-to the artifact. The "-" means the tag should be removed.
257
-The "*" character means the tag should be added to the artifact
258
-and all direct decendants (but not branches) of the artifact down
259
-to but not including the first decendant that contains a
260
-more recent "-" tag with the same name.
261
-The optional third argument is the value of the tag. A tag
262
-without a value is a boolean.</p>
263
-
264
-<p>When two or more tags with the same name are applied to the
265
-same artifact, the tag with the latest (most recent) date is
266
-used.</p>
267
-
268
-<p>Some tags have special meaning. The "comment" tag when applied
269
-to a baseline will override the check-in comment of that baseline
270
-for display purposes.</p>
271
-
272
-<h2>4.0 Wiki Pages</h2>
273
-
274
-<p>A wiki page is an artifact with a format similar to manifests,
275
-clusters, and control artifacts. The artifact is divided into
276
-cards by newline characters. The format of each card is as in
277
-manifests, clusters, and control artifacts. Wiki artifacts accept
278
-the following card types:</p>
279
-
280
-<blockquote>
281
-<b>D</b> <i>time-and-date-stamp</i><br />
282
-<b>L</b> <i>wiki-title</i><br />
283
-<b>P</b> <i>parent-uuid</i>+<br />
284
-<b>U</b> <i>user-name</i><br />
285
-<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
286
-<b>Z</b> <i>checksum</i>
287
-</blockquote>
288
-
289
-<p>The D card is the date and time when the wiki page was edited.
290
-The P card specifies the parent wiki pages, if any. The L card
291
-gives the name of the wiki page. The U card specifies the login
292
-of the user who made this edit to the wiki page. The Z card is
293
-the usual checksum over the either artifact.</p>
294
-
295
-<p>The W card is used to specify the text of the wiki page. The
296
-argument to the W card is an integer which is the number of bytes
297
-of text in the wiki page. That text follows the newline character
298
-that terminates the W card. The wiki text is always followed by one
299
-extra newline.</p>
300
-
301
-<h2>5.0 Ticket Changes</h2>
302
-
303
-<p>A ticket-change artifact represents a change to a trouble ticket.
304
-The following cards are allowed on a ticket change artifact:</p>
305
-
306
-<blockquote>
307
-<b>D</b> <i>time-and-date-stamp</i><br />
308
-<b>J</b> ?<b>+</b>?<i>name value</i><br />
309
-<b>K</b> <i>ticket-uuid</i><br />
310
-<b>U</b> <i>user-name</i><br />
311
-<b>Z</b> <i>checksum</i>
312
-</blockquote>
313
-
314
-<p>
315
-The D card is the usual date and time stamp and represents the point
316
-in time when the change was entered. The U card is the login of the
317
-programmer who entered this change. The Z card is the checksum over
318
-the entire artifact.</p>
319
-
320
-<p>
321
-Every ticket has a UUID. The ticket to which this change is applied
322
-is specified by the K card. A ticket exists if it contains one or
323
-more changes. The first "change" to a ticket is what brings the
324
-ticket into existance.</p>
325
-
326
-<p>
327
-J cards specify changes to "fields" of the ticket. Each fossil
328
-server has a ticket configuration which specifies the fields its
329
-understands. This is not a limit on the fields that can appear
330
-on the J cards, however. If a J card specifies a field that a
331
-particular fossil server does not recognize, then that J card
332
-is simply ignored.</p>
333
-
334
-<p>
335
-The first argument of the J card is the field name. The second
336
-value is the field value. If the field name begins with "+" then
337
-the value is appended to the prior value. Otherwise, the value
338
-on the J card replaces any previous value of the field.
339
-The field name and value are both encoded using the character
340
-escapes defined for the C card of a manifest.
341
-</p>
--- a/www/fileformat.html
+++ b/www/fileformat.html
@@ -1,341 +0,0 @@
1 <html>
2 <head>
3 <title>Fossil File Format</title>
4 </head>
5 <body bgcolor="white">
6 <p>[ <a href="index.html">Index</a> ]</p>
7 <hr>
8 <h1 align="center">
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
21 <p>
22 Each artifact in the repository is named by its SHA1 hash.
23 No prefixes or meta information is added to a artifact before
24 its hash is computed. The name of a artifact in the repository
25 is exactly the same SHA1 hash that is computed by sha1sum
26 on the file as it exists in your source tree.</p>
27
28 <p>
29 Some artifacts have a particular format which gives them special
30 meaning to fossil. Fossil recognizes:</p>
31
32 <ul>
33 <li> Manifests </li>
34 <li> Clusters </li>
35 <li> Control Artifacts </li>
36 <li> Wiki Pages </li>
37 <li> Ticket Changes </li>
38 </ul>
39
40 <p>These five artifact types are described in the sequel.</p>
41
42 <h2>1.0 The Manifest</h2>
43
44 <p>A manifest defines a baseline or version of the project
45 source tree. The manifest contains a list of artifacts for
46 each file in the project and the corresponding filenames, as
47 well as information such as parent baselines, the name of the
48 programmer who created the baseline, the date and time when
49 the baseline was created, and any check-in comments associated
50 with the baseline.</p>
51
52 <p>
53 Any artifact in the repository that follows the syntactic rules
54 of a manifest is a manifest. Note that a manifest can
55 be both a real manifest and also a content file, though this
56 is rare.
57 </p>
58
59 <p>
60 A manifest is a text file. Newline characters
61 (ASCII 0x0a) separate the file into "cards".
62 Each card begins with a single
63 character "card type". Zero or more arguments may follow
64 the card type. All arguments are separated from each other
65 and from the card-type character by a single space
66 character. There is no surplus white space between arguments
67 and no leading or trailing whitespace except for the newline
68 character that acts as the card separator.
69 </p>
70
71 <p>
72 All cards of the manifest occur in strict sorted lexicographical order.
73 No card may be duplicated.
74 The entire manifest may be PGP clear-signed, but otherwise it
75 may contain no additional text or data beyond what is described here.
76 </p>
77
78 <p>
79 Allowed cards in the manifest are as follows:
80 </p>
81
82 <blockquote>
83 <b>C</b> <i>checkin-comment</i><br>
84 <b>D</b> <i>time-and-date-stamp</i><br>
85 <b>F</b> <i>filename</i> <i>SHA1-hash</i><br>
86 <b>P</b> <i>SHA1-hash</i>+<br>
87 <b>R</b> <i>repository-checksum</i><br>
88 <b>U</b> <i>user-login</i><br>
89 <b>Z</b> <i>manifest-checksum</i>
90 </blockquote>
91
92 <p>
93 A manifest must have exactly one C-card. The sole argument to
94 the C-card is a check-in comment that describes the check-in that
95 the manifest defines. The check-in comment is text. The following
96 escape sequences are applied to the text:
97 A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
98 newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
99 (ASCII 0x5C) is represented as two backslashes "\\". Apart from
100 space and newline, no other whitespace characters are allowed in
101 the check-in comment. Nor are any unprintable characters allowed
102 in the comment.
103 </p>
104
105 <p>
106 A manifest must have exactly one D-card. The sole argument to
107 the D-card is a date-time stamp in the ISO8601 format. The
108 date and time should be in coordinated universal time (UTC).
109 The format is:
110 </p>
111
112 <blockquote>
113 <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i>
114 </blockquote>
115
116 <p>
117 A manifest has zero or more F-cards. Each F-card defines a file
118 (other than the manifest itself) which is part of the baseline that
119 the manifest defines. There are two arguments. The first argment
120 is the pathname of the file in the baseline relative to the root
121 of the project file hierarchy. No ".." or "." directories are allowed
122 within the filename. Space characters are escaped as in C-card
123 comment text. Backslash characters and newlines are not allowed
124 within filenames. The directory separator character is a forward
125 slash (ASCII 0x2F). The second argument to the F-card is the
126 full 40-character lower-case hexadecimal SHA1 hash of the content
127 artifact.
128 </p>
129
130 <p>
131 A manifest has zero or one P-cards. Most manifests have one P-card.
132 The P-card has a varying number of arguments that
133 defines other manifests from which the current manifest
134 is derived. Each argument is an 40-character lowercase
135 hexadecimal SHA1 of the predecessor manifest. All arguments
136 to the P-card must be unique to that line.
137 The first predecessor is the direct ancestor of the manifest.
138 Other arguments define manifests with which the first was
139 merged to yield the current manifest. Most manifests have
140 a P-card with a single argument. The first manifest in the
141 project has no ancestors and thus has no P-card.
142 </p>
143
144 <p>
145 A manifest may optionally have a single R-card. The R-card has
146 a single argument which is the MD5 checksum of all files in
147 the baseline except the manifest itself. The checksum is expressed
148 as 32-characters of lowercase hexadecimal. The checksum is
149 computed as follows: For each file in the baseline (except for
150 the manifest itself) in strict sorted lexicographical order,
151 take the pathname of the file relative to the root of the
152 repository, append a single space (ASCII 0x20), the
153 size of the file in ASCII decimal, a single newline
154 character (ASCII 0x0A), and the complete text of the file.
155 Compute the MD5 checksum of the the result.
156 </p>
157
158 <p>
159 Each manifest has a single U-card. The argument to the U-card is
160 the login of the user who created the manifest. The login name
161 is encoded using the same character escapes as is used for the
162 check-in comment argument to the C-card.
163 </p>
164
165 <p>
166 A manifest has an option Z-card as its last line. The argument
167 to the Z-card is a 32-character lowercase hexadecimal MD5 hash
168 of all prior lines of the manifest up to and including the newline
169 character that immediately preceeds the "Z". The Z-card is just
170 a sanity check to prove that the manifest is well-formed and
171 consistent.
172 </p>
173
174 <h2>2.0 Clusters</h2>
175
176 <p>
177 A cluster is a artifact that declares the existance of other artifacts.
178 Clusters are used during repository synchronization to help
179 reduce network traffic.
180 </p>
181
182 <p>
183 Clusters follow a syntax that is very similar to manifests.
184 A Cluster is a line-oriented text file. Newline characters
185 (ASCII 0x0a) separate the artifact into cards. Each card begins with a single
186 character "card type". Zero or more arguments may follow
187 the card type. All arguments are separated from each other
188 and from the card-type character by a single space
189 character. There is no surplus white space between arguments
190 and no leading or trailing whitespace except for the newline
191 character that acts as the card separator.
192 All cards of a cluter occur in strict sorted lexicographical order.
193 No card may be duplicated.
194 The cluster may not contain additional text or data beyond
195 what is described here.
196 Unlike manifests, clusters are never PGP signed.
197 </p>
198
199 <p>
200 Allowed cards in the cluster are as follows:
201 </p>
202
203 <blockquote>
204 <b>M</b> <i>uuid</i><br />
205 <b>Z</b> <i>checksum</i>
206 </blockquote>
207
208 <p>
209 A cluster contains one or more "M" cards followed by a single "Z"
210 line. Each M card has a single argument which is the UUID of
211 another artifact in the repository. The Z card work exactly like
212 the Z card of a manifest. The argument to the Z card is the
213 lower-case hexadecimal representation of the MD5 checksum of all
214 prior cards in the cluster. Note that the Z card is required
215 on a cluster.
216 </p>
217
218
219 <h2>3.0 Control Artifacts</h2>
220
221 <p>
222 Control artifacts are used to assign properties to other artifacts
223 within the repository. The basic format of a control artifact is
224 the same as a manifest or cluster. A control artifact is a text
225 files divided into cards by newline characters. Each card has a
226 single-character card type followed by arguments. Spaces separate
227 the card type and the arguments. No surplus whitespace is allowed.
228 All cards must occur in strict lexigraphical order.
229 </p>
230
231 <p>
232 Allowed cards in a control artifact are as follows:
233 </p>
234
235 <blockquote>
236 <b>D</b> <i>time-and-date-stamp</i><br />
237 <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name uuid ?value?</i><br />
238 <b>Z</b> <i>checksum</i><br />
239 </blockquote>
240
241 <p>
242 A control artifact must have one D card and one Z card and
243 one or more or more T cards. No other cards or other text is
244 allowed in a control artifact. Control artifacts might be PGP
245 clearsigned.</p>
246
247 <p>The D card and the Z card of a control artifact are the same
248 as in a manifest.</p>
249
250 <p>The T card represents a "tag" or property that is applied to
251 some other artifact. The T card has two or three values. The
252 second argument is the 40 character lowercase UUID of the artifact
253 to which the tag is to be applied. The
254 first value is the tag name. The first character of the tag
255 is either "+", "-", or "*". A "+" means the tag should be added
256 to the artifact. The "-" means the tag should be removed.
257 The "*" character means the tag should be added to the artifact
258 and all direct decendants (but not branches) of the artifact down
259 to but not including the first decendant that contains a
260 more recent "-" tag with the same name.
261 The optional third argument is the value of the tag. A tag
262 without a value is a boolean.</p>
263
264 <p>When two or more tags with the same name are applied to the
265 same artifact, the tag with the latest (most recent) date is
266 used.</p>
267
268 <p>Some tags have special meaning. The "comment" tag when applied
269 to a baseline will override the check-in comment of that baseline
270 for display purposes.</p>
271
272 <h2>4.0 Wiki Pages</h2>
273
274 <p>A wiki page is an artifact with a format similar to manifests,
275 clusters, and control artifacts. The artifact is divided into
276 cards by newline characters. The format of each card is as in
277 manifests, clusters, and control artifacts. Wiki artifacts accept
278 the following card types:</p>
279
280 <blockquote>
281 <b>D</b> <i>time-and-date-stamp</i><br />
282 <b>L</b> <i>wiki-title</i><br />
283 <b>P</b> <i>parent-uuid</i>+<br />
284 <b>U</b> <i>user-name</i><br />
285 <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
286 <b>Z</b> <i>checksum</i>
287 </blockquote>
288
289 <p>The D card is the date and time when the wiki page was edited.
290 The P card specifies the parent wiki pages, if any. The L card
291 gives the name of the wiki page. The U card specifies the login
292 of the user who made this edit to the wiki page. The Z card is
293 the usual checksum over the either artifact.</p>
294
295 <p>The W card is used to specify the text of the wiki page. The
296 argument to the W card is an integer which is the number of bytes
297 of text in the wiki page. That text follows the newline character
298 that terminates the W card. The wiki text is always followed by one
299 extra newline.</p>
300
301 <h2>5.0 Ticket Changes</h2>
302
303 <p>A ticket-change artifact represents a change to a trouble ticket.
304 The following cards are allowed on a ticket change artifact:</p>
305
306 <blockquote>
307 <b>D</b> <i>time-and-date-stamp</i><br />
308 <b>J</b> ?<b>+</b>?<i>name value</i><br />
309 <b>K</b> <i>ticket-uuid</i><br />
310 <b>U</b> <i>user-name</i><br />
311 <b>Z</b> <i>checksum</i>
312 </blockquote>
313
314 <p>
315 The D card is the usual date and time stamp and represents the point
316 in time when the change was entered. The U card is the login of the
317 programmer who entered this change. The Z card is the checksum over
318 the entire artifact.</p>
319
320 <p>
321 Every ticket has a UUID. The ticket to which this change is applied
322 is specified by the K card. A ticket exists if it contains one or
323 more changes. The first "change" to a ticket is what brings the
324 ticket into existance.</p>
325
326 <p>
327 J cards specify changes to "fields" of the ticket. Each fossil
328 server has a ticket configuration which specifies the fields its
329 understands. This is not a limit on the fields that can appear
330 on the J cards, however. If a J card specifies a field that a
331 particular fossil server does not recognize, then that J card
332 is simply ignored.</p>
333
334 <p>
335 The first argument of the J card is the field name. The second
336 value is the field value. If the field name begins with "+" then
337 the value is appended to the prior value. Otherwise, the value
338 on the J card replaces any previous value of the field.
339 The field name and value are both encoded using the character
340 escapes defined for the C card of a manifest.
341 </p>
--- a/www/fileformat.html
+++ b/www/fileformat.html
@@ -1,341 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/fileformat.wiki
+106
--- a/www/fileformat.wiki
+++ b/www/fileformat.wiki
@@ -0,0 +1,106 @@
1
+</b> card is used to smo the <b>W</b> cadetermined by card is used to smore N-cards. Each N card recartifacts N card records a name changes
2
+to one of the files in the manifest. The firstb> card is used t text of tn the parent check-inis the
3
+t to the <b>W</b> </b> card i/b> card is used to specify the text of the wi<p>f ts used to smore N-cards. Each N card records a name changes
4
+to one of the files in the manifest. The firstb> card is used t text of tn the parent check-inis the
5
+t to the <b>W</b> </b> card i/b> card is used to specify the text of the wi<p>f text in the wik <b>W</b> card. The wiki gument to the <b>W</b> card is an iblockquote the <b>W</b> card is an integer which is the number of bytes
6
+of text in the wiki page. That text fol</p>
7
+
8
+<p>
9
+f text in the wik <b>W</b> card. The wiki text is always followedR</bf text in the wiki page.might be a source<titl border=1 walldefines a file
10
+(other than) whichre arefive/7b2f5fd0e0?txt=1the <b>W</b> cn of the ID ofitself. cter
11
+that terminates the <b>W</b> card. The wiki text is always followedR</bf text in the wiki page.might be a source<ti</p>
12
+
13
+<p>ile
14
+(other than) whichre arefive/7b2f5fd0e0?txt=1the <b>W</b> card is Pa <b>B</b> card isired.
15
+
16
+The wiki
17
+artifact.
18
+
19
+summary76C</b> <i>coment-textD/tr>
20
+</table>
21
+rtifact | Artifac(<b>+</b>|<b>-</b>)filename is preceeded by "+" to ad or "-" to
22
+remove the attachment The
23
+argument to the <b>W</b> Pa <b>B</b> card isired.
24
+
25
+The <b>W</b> card is used to specify the text of the ID ofitself. EveryA car(<b>+</b>|<b>-</b>)</p>
26
+
27
+<p></p>
28
+
29
+<p></p><p>C</p>
30
+
31
+<p></p><p></p>
32
+
33
+<p></p>
34
+
35
+<p></p>
36
+
37
+<p></p>
38
+
39
+<p></p>
40
+
41
+<p></p>
42
+
43
+<p><p></p>
44
+
45
+<p></p>
46
+
47
+<baseline. If card isired.
48
+
49
+The wikbaseline/b> <i>coment-textD/tr>extD/tr>
50
+</table>
51
+rtifact | Artbaseline<ul>
52
+<li> Manifests </li>
53
+<li> Clusters </li>
54
+<li> Control Artifacts </li>
55
+<li> Wiki Pages </li>
56
+<li> Ticket Changes </li>
57
+</ul>
58
+
59
+<p></p>
60
+
61
+<p></p>
62
+iki page.might be a source<t<p>ki page.might be a source<titl border=1 walldefines a file
63
+(other t arguments. properties "tag" or property <b>B</b> card isired.
64
+
65
+The <b>W</b> card is used to specify the text </p>
66
+
67
+<p>ment to the <b>W</b> card isbaselineckquote the <b>W</b> card is an integer which is the number of bytes
68
+of text in the wiki page. That text follows the newline character
69
+that terminates the baselineways followedR</bf baselineurce<titl border=1 walldefinebaselineve/7b2f5fd0e0?txt=1the <b>W</b> cbaselinebaselinee
70
+argument to the <b>W</b> card is an D/tr>
71
+</table>
72
+rtifact | Artbaseline<ul>
73
+<li> Manifests </li>
74
+<li> Clusters </li>
75
+<li> Control Artifacts </li>
76
+<li> Wiki Pages </li>
77
+<li> Ticket Changes </li>
78
+</ul>
79
+
80
+<p></p>
81
+
82
+<p></p>
83
+iki page.might be a source<t<p>ki page.might be a source<titl border=1 walldefinent check-inis the
84
+t to the <b>W</b> </b> card i/b> card is used to specify the te</b> card is used to smore N-cards. Each N card records a name changes
85
+to one of the files in the manifest. The firstb> card is used t text of tn the parent check-inis the
86
+t to the <b>W</b> </b> card i/b> card is used to specify the text of the wi<p>f text in the wik <b>W</b> card. The wiki gument to the <b>W</b> card is an iblockquote the <b>W</b> card is an integer which is the number of bytes
87
+of text in the wiki page. That text fol</p>
88
+
89
+<p>
90
+f text in the wik <b>W</b> card. The wiki text is always followedR</bf text in the wiki page.might be a source<titl border=1 walldefines a file
91
+(other than) whichre arefive/7b2f5fd0e0?txt=1the <b>W</b> card is Pa <b>B</b> card isired.
92
+
93
+The wiki
94
+artifact.
95
+
96
+ tags or
97
+properties "tag" or property <b>B</b> card isired.
98
+
99
+The <b>W</b> aspecify the text of the wi<p>f text in the wik <b>W</b> card. The wiki gument to the <b>W</b> card is an iblockquote the <b>W</b> card is an integer which is the number of bytes
100
+of text in the wiki page. That text fol</p>
101
+
102
+<p>
103
+f text in the wik <b>W</b> card. The wiki text is always followedR</bf text in the wiki page.might be a source<titl border=1 walldefines a file
104
+(other than) whichre< value</i>"fields" ois is not a limit on the fields that can appear
105
+on the J cards, howeverfield that a
106
+particular fossiuuidUUuuUUuuid</i>+uuUU
--- a/www/fileformat.wiki
+++ b/www/fileformat.wiki
@@ -0,0 +1,106 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--- a/www/fileformat.wiki
+++ b/www/fileformat.wiki
@@ -0,0 +1,106 @@
1 </b> card is used to smo the <b>W</b> cadetermined by card is used to smore N-cards. Each N card recartifacts N card records a name changes
2 to one of the files in the manifest. The firstb> card is used t text of tn the parent check-inis the
3 t to the <b>W</b> </b> card i/b> card is used to specify the text of the wi<p>f ts used to smore N-cards. Each N card records a name changes
4 to one of the files in the manifest. The firstb> card is used t text of tn the parent check-inis the
5 t to the <b>W</b> </b> card i/b> card is used to specify the text of the wi<p>f text in the wik <b>W</b> card. The wiki gument to the <b>W</b> card is an iblockquote the <b>W</b> card is an integer which is the number of bytes
6 of text in the wiki page. That text fol</p>
7
8 <p>
9 f text in the wik <b>W</b> card. The wiki text is always followedR</bf text in the wiki page.might be a source<titl border=1 walldefines a file
10 (other than) whichre arefive/7b2f5fd0e0?txt=1the <b>W</b> cn of the ID ofitself. cter
11 that terminates the <b>W</b> card. The wiki text is always followedR</bf text in the wiki page.might be a source<ti</p>
12
13 <p>ile
14 (other than) whichre arefive/7b2f5fd0e0?txt=1the <b>W</b> card is Pa <b>B</b> card isired.
15
16 The wiki
17 artifact.
18
19 summary76C</b> <i>coment-textD/tr>
20 </table>
21 rtifact | Artifac(<b>+</b>|<b>-</b>)filename is preceeded by "+" to ad or "-" to
22 remove the attachment The
23 argument to the <b>W</b> Pa <b>B</b> card isired.
24
25 The <b>W</b> card is used to specify the text of the ID ofitself. EveryA car(<b>+</b>|<b>-</b>)</p>
26
27 <p></p>
28
29 <p></p><p>C</p>
30
31 <p></p><p></p>
32
33 <p></p>
34
35 <p></p>
36
37 <p></p>
38
39 <p></p>
40
41 <p></p>
42
43 <p><p></p>
44
45 <p></p>
46
47 <baseline. If card isired.
48
49 The wikbaseline/b> <i>coment-textD/tr>extD/tr>
50 </table>
51 rtifact | Artbaseline<ul>
52 <li> Manifests </li>
53 <li> Clusters </li>
54 <li> Control Artifacts </li>
55 <li> Wiki Pages </li>
56 <li> Ticket Changes </li>
57 </ul>
58
59 <p></p>
60
61 <p></p>
62 iki page.might be a source<t<p>ki page.might be a source<titl border=1 walldefines a file
63 (other t arguments. properties "tag" or property <b>B</b> card isired.
64
65 The <b>W</b> card is used to specify the text </p>
66
67 <p>ment to the <b>W</b> card isbaselineckquote the <b>W</b> card is an integer which is the number of bytes
68 of text in the wiki page. That text follows the newline character
69 that terminates the baselineways followedR</bf baselineurce<titl border=1 walldefinebaselineve/7b2f5fd0e0?txt=1the <b>W</b> cbaselinebaselinee
70 argument to the <b>W</b> card is an D/tr>
71 </table>
72 rtifact | Artbaseline<ul>
73 <li> Manifests </li>
74 <li> Clusters </li>
75 <li> Control Artifacts </li>
76 <li> Wiki Pages </li>
77 <li> Ticket Changes </li>
78 </ul>
79
80 <p></p>
81
82 <p></p>
83 iki page.might be a source<t<p>ki page.might be a source<titl border=1 walldefinent check-inis the
84 t to the <b>W</b> </b> card i/b> card is used to specify the te</b> card is used to smore N-cards. Each N card records a name changes
85 to one of the files in the manifest. The firstb> card is used t text of tn the parent check-inis the
86 t to the <b>W</b> </b> card i/b> card is used to specify the text of the wi<p>f text in the wik <b>W</b> card. The wiki gument to the <b>W</b> card is an iblockquote the <b>W</b> card is an integer which is the number of bytes
87 of text in the wiki page. That text fol</p>
88
89 <p>
90 f text in the wik <b>W</b> card. The wiki text is always followedR</bf text in the wiki page.might be a source<titl border=1 walldefines a file
91 (other than) whichre arefive/7b2f5fd0e0?txt=1the <b>W</b> card is Pa <b>B</b> card isired.
92
93 The wiki
94 artifact.
95
96 tags or
97 properties "tag" or property <b>B</b> card isired.
98
99 The <b>W</b> aspecify the text of the wi<p>f text in the wik <b>W</b> card. The wiki gument to the <b>W</b> card is an iblockquote the <b>W</b> card is an integer which is the number of bytes
100 of text in the wiki page. That text fol</p>
101
102 <p>
103 f text in the wik <b>W</b> card. The wiki text is always followedR</bf text in the wiki page.might be a source<titl border=1 walldefines a file
104 (other than) whichre< value</i>"fields" ois is not a limit on the fields that can appear
105 on the J cards, howeverfield that a
106 particular fossiuuidUUuuUUuuid</i>+uuUU
D www/index.html
-118
--- a/www/index.html
+++ b/www/index.html
@@ -1,118 +0,0 @@
1
-<html>
2
-<head>
3
-<title>Fossil SCM Homepage</title>
4
-</head>
5
-<body bgcolor="white">
6
-<h1>Fossil - A Software Configuration Management System</h1>
7
-
8
-<p>
9
-This is a preliminary homepage for a new software configuration
10
-management system called "Fossil".
11
-The system is
12
-<a href="http://www.fossil-scm.org/fossil/timeline">self-hosting</a> on
13
-<a href="http://www.hwaci.com/cgi-bin/fossil/timeline">two separate servers</a>.
14
-You can download the lastest sources
15
-compile it yourself using the instructions below.
16
-Or you can grab
17
-<a href="http://www.fossil-scm.org/download.html">precompiled binaries</a>.
18
-</p>
19
-
20
-<p>Design Goals For Fossil:</p>
21
-
22
-<ul>
23
-<li>Supports disconnected, distributed development (like
24
-<a href="http://kerneltrap.org/node/4982">git</a>,
25
-<a href="http://www.monotone.ca/">monotone</a>,
26
-<a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or
27
-<a href="http://www.bitkeeper.com/">bitkeeper</a>)
28
-or client/server operation (like
29
-<a href="http://www.nongnu.org/cvs/">CVS</a> or
30
-<a href="http://subversion.tigris.org/">subversion</a>)
31
-or both at the same time</li>
32
-<li>Integrated bug tracking and wiki, along the lines of
33
-<a href="http://www.cvstrac.org/">CVSTrac</a> and
34
-<a href="http://www.edgewall.com/trac/">Trac</a>.</li>
35
-<li>Built-in web interface that supports deep archaeological digs through
36
-historical source code.</li>
37
-<li>All network communication via
38
-<a href="http://en.wikipedia.org/wiki/HTTP">HTTP</a>
39
-(so that everything works from behind restrictive firewalls).</li>
40
-<li>Everything included in a single self-contained executable -
41
- trivial to install</li>
42
-<li>Server runs as <a href="http://www.w3.org/CGI/">CGI</a>, using
43
-<a href="http://en.wikipedia.org/wiki/inetd">inetd</a> or
44
-<a href="http://www.xinetd.org/">xinetd</a> or using its own built-in,
45
-standalone web server.</li>
46
-<li>An entire project contained in single disk file (which also
47
-happens to be an <a href="http://www.sqlite.org/">SQLite</a> database.)</li>
48
-<li>Trivial to setup and administer</li>
49
-<li>Files and versions are identified by their
50
-<a href="http://en.wikipedia.org/wiki/SHA-1">SHA1</a> signature.</a>
51
-Any unique prefix is sufficient to identify a file
52
-or version - usually the first 4 or 5 characters suffice.</li>
53
-<li>The file format is trival and requires nothing more complex
54
-than a text editor and the "sha1sum" command-line utility to decode.</li>
55
-<li>Automatic <a href="selfcheck.html">self-check</a>
56
-on repository changes makes it exceedingly
57
-unlikely that data will ever be lost because of a software bug.</li>
58
-</ul>
59
-
60
-<p>Objectives Of Fossil:</p>
61
-
62
-<ul>
63
-<li>Fossil should be ridiculously easy to
64
-<a href="build.html">install</a> and
65
-<a href="quickstart.html">operate</a>.</li>
66
-<li>With fossil, it should be possible (and
67
-<a href="quickstart.html#serversetup">easy</a>) to set up a project
68
-on an inexpensive shared-hosting ISP
69
-(example: <a href="http://www.he.net/hosting.html">Hurricane Electric</a>)
70
-that provides nothing more than web space and CGI capability.
71
-Here is <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">a demo</a>.</li>
72
-<li>Fossil should provide in-depth historical and status information about the
73
-project through a web interface</li>
74
-<li>The integration of <a href="http://wiki.org/wiki.cgi?WhatIsWiki">Wiki</a>
75
-and the ability to safely support anonymous check-in are features sometimes
76
-described as
77
-<a href="http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html">Web 2.0</a>.
78
-Fossil attempts to better capture "collective intelligence" and
79
-"the wisdom of crowds" by opening up write access to the masses.</li>
80
-</ul>
81
-
82
-<p>Other Links:</p>
83
-
84
-<ul>
85
-<li>The <a href="concepts.html">concepts</b> behind fossil</li>
86
-<li><a href="build.html">Building And Installing</a></li>
87
-<li><a href="quickstart.html">Quick Start</a> guide to using fossil
88
-<li><a href="pop.html">Principles Of Operation</a></li>
89
-<li>The <a href="selfcheck.html">automatic self-check</a> mechanism
90
-helps insure project integrity.</li>
91
-<li>The <a href="fileformat.html">file format</a> used by every content
92
-file stored in the repository.</li>
93
-<li>The <a href="delta_format.html">format of deltas</a> used to
94
-efficiently store changes between file revisions.</li>
95
-<li>The <a href="delta_encoder_algorithm.html">encoder algorithm</a> used to
96
-efficiently generate deltas.</li>
97
-<li>The <a href="sync.html">synchronization protocol</a>.
98
-<li>There is a <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users">
99
- mailing list</a> available for discussing fossil issues.</li>
100
-<li>The <a href="http://www.fossil-scm.org/fossil/wiki">self-hosting
101
- fossil wiki</a>.
102
-</ul>
103
-
104
-<p>Competing Projects:</p>
105
-
106
-<ul>
107
-<li><a href="http://www.ditrack.org/">DITrace</a>
108
- - A Distributed Issue Tracker</li>
109
-<li><a href="http://www.distract.wellquite.org/">DisTract</a>
110
- - Another distributed issue tracker based on
111
- <a href="http://www.monotone.ca/">monotone</a>.
112
-<li><a href="http://www.monotone.ca/">Monotone</a> - distributed
113
- SCM in a single-file executable with a single-file SQLite
114
- database repository.</li>
115
-</ul>
116
-
117
-</body>
118
-</html>
--- a/www/index.html
+++ b/www/index.html
@@ -1,118 +0,0 @@
1 <html>
2 <head>
3 <title>Fossil SCM Homepage</title>
4 </head>
5 <body bgcolor="white">
6 <h1>Fossil - A Software Configuration Management System</h1>
7
8 <p>
9 This is a preliminary homepage for a new software configuration
10 management system called "Fossil".
11 The system is
12 <a href="http://www.fossil-scm.org/fossil/timeline">self-hosting</a> on
13 <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">two separate servers</a>.
14 You can download the lastest sources
15 compile it yourself using the instructions below.
16 Or you can grab
17 <a href="http://www.fossil-scm.org/download.html">precompiled binaries</a>.
18 </p>
19
20 <p>Design Goals For Fossil:</p>
21
22 <ul>
23 <li>Supports disconnected, distributed development (like
24 <a href="http://kerneltrap.org/node/4982">git</a>,
25 <a href="http://www.monotone.ca/">monotone</a>,
26 <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or
27 <a href="http://www.bitkeeper.com/">bitkeeper</a>)
28 or client/server operation (like
29 <a href="http://www.nongnu.org/cvs/">CVS</a> or
30 <a href="http://subversion.tigris.org/">subversion</a>)
31 or both at the same time</li>
32 <li>Integrated bug tracking and wiki, along the lines of
33 <a href="http://www.cvstrac.org/">CVSTrac</a> and
34 <a href="http://www.edgewall.com/trac/">Trac</a>.</li>
35 <li>Built-in web interface that supports deep archaeological digs through
36 historical source code.</li>
37 <li>All network communication via
38 <a href="http://en.wikipedia.org/wiki/HTTP">HTTP</a>
39 (so that everything works from behind restrictive firewalls).</li>
40 <li>Everything included in a single self-contained executable -
41 trivial to install</li>
42 <li>Server runs as <a href="http://www.w3.org/CGI/">CGI</a>, using
43 <a href="http://en.wikipedia.org/wiki/inetd">inetd</a> or
44 <a href="http://www.xinetd.org/">xinetd</a> or using its own built-in,
45 standalone web server.</li>
46 <li>An entire project contained in single disk file (which also
47 happens to be an <a href="http://www.sqlite.org/">SQLite</a> database.)</li>
48 <li>Trivial to setup and administer</li>
49 <li>Files and versions are identified by their
50 <a href="http://en.wikipedia.org/wiki/SHA-1">SHA1</a> signature.</a>
51 Any unique prefix is sufficient to identify a file
52 or version - usually the first 4 or 5 characters suffice.</li>
53 <li>The file format is trival and requires nothing more complex
54 than a text editor and the "sha1sum" command-line utility to decode.</li>
55 <li>Automatic <a href="selfcheck.html">self-check</a>
56 on repository changes makes it exceedingly
57 unlikely that data will ever be lost because of a software bug.</li>
58 </ul>
59
60 <p>Objectives Of Fossil:</p>
61
62 <ul>
63 <li>Fossil should be ridiculously easy to
64 <a href="build.html">install</a> and
65 <a href="quickstart.html">operate</a>.</li>
66 <li>With fossil, it should be possible (and
67 <a href="quickstart.html#serversetup">easy</a>) to set up a project
68 on an inexpensive shared-hosting ISP
69 (example: <a href="http://www.he.net/hosting.html">Hurricane Electric</a>)
70 that provides nothing more than web space and CGI capability.
71 Here is <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">a demo</a>.</li>
72 <li>Fossil should provide in-depth historical and status information about the
73 project through a web interface</li>
74 <li>The integration of <a href="http://wiki.org/wiki.cgi?WhatIsWiki">Wiki</a>
75 and the ability to safely support anonymous check-in are features sometimes
76 described as
77 <a href="http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html">Web 2.0</a>.
78 Fossil attempts to better capture "collective intelligence" and
79 "the wisdom of crowds" by opening up write access to the masses.</li>
80 </ul>
81
82 <p>Other Links:</p>
83
84 <ul>
85 <li>The <a href="concepts.html">concepts</b> behind fossil</li>
86 <li><a href="build.html">Building And Installing</a></li>
87 <li><a href="quickstart.html">Quick Start</a> guide to using fossil
88 <li><a href="pop.html">Principles Of Operation</a></li>
89 <li>The <a href="selfcheck.html">automatic self-check</a> mechanism
90 helps insure project integrity.</li>
91 <li>The <a href="fileformat.html">file format</a> used by every content
92 file stored in the repository.</li>
93 <li>The <a href="delta_format.html">format of deltas</a> used to
94 efficiently store changes between file revisions.</li>
95 <li>The <a href="delta_encoder_algorithm.html">encoder algorithm</a> used to
96 efficiently generate deltas.</li>
97 <li>The <a href="sync.html">synchronization protocol</a>.
98 <li>There is a <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users">
99 mailing list</a> available for discussing fossil issues.</li>
100 <li>The <a href="http://www.fossil-scm.org/fossil/wiki">self-hosting
101 fossil wiki</a>.
102 </ul>
103
104 <p>Competing Projects:</p>
105
106 <ul>
107 <li><a href="http://www.ditrack.org/">DITrace</a>
108 - A Distributed Issue Tracker</li>
109 <li><a href="http://www.distract.wellquite.org/">DisTract</a>
110 - Another distributed issue tracker based on
111 <a href="http://www.monotone.ca/">monotone</a>.
112 <li><a href="http://www.monotone.ca/">Monotone</a> - distributed
113 SCM in a single-file executable with a single-file SQLite
114 database repository.</li>
115 </ul>
116
117 </body>
118 </html>
--- a/www/index.html
+++ b/www/index.html
@@ -1,118 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/index.wiki
+44 -19
--- www/index.wiki
+++ www/index.wiki
@@ -1,27 +1,32 @@
1
-<title>Fossil SCM Homepage</title>
1
+<h1>Fossil - A Software Configuration Management System</h1>
22
3
+<p>
34
 This is a preliminary homepage for a new software configuration
45
 management system called "Fossil".
56
 The system is
6
-<a href="http://fossil-scm.hwaci.com/fossil/timeline">self-hosting</a> on
7
+<a href="http://www.fossil-scm.org/fossil/timeline">self-hosting</a> on
78
 <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">two separate servers</a>.
89
 You can download the lastest sources
910
 compile it yourself using the instructions below.
11
+Or you can grab
12
+<a href="http://www.fossil-scm.org/download.html">precompiled binaries</a>.
13
+</p>
1014
11
-<h2>Design Goals For Fossil:</h1>
15
+<p>Design Goals For Fossil:</p>
1216
1317
 <ul>
1418
 <li>Supports disconnected, distributed development (like
1519
 <a href="http://kerneltrap.org/node/4982">git</a>,
16
-<a href="http://www.venge.net/monotone/">monotone</a>,
20
+<a href="http://www.monotone.ca/">monotone</a>,
1721
 <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or
1822
 <a href="http://www.bitkeeper.com/">bitkeeper</a>)
1923
 or client/server operation (like
2024
 <a href="http://www.nongnu.org/cvs/">CVS</a> or
21
-<a href="http://subversion.tigris.org/">subversion</a>)
22
-or both at the same time</li>
25
+<a href="http://subversion.tigris.org/">subversion</a>),
26
+or operations on local repositories,
27
+or all three at the same time</li>
2328
 <li>Integrated bug tracking and wiki, along the lines of
2429
 <a href="http://www.cvstrac.org/">CVSTrac</a> and
2530
 <a href="http://www.edgewall.com/trac/">Trac</a>.</li>
2631
 <li>Built-in web interface that supports deep archaeological digs through
2732
 historical source code.</li>
@@ -41,23 +46,23 @@
4146
 <a href="http://en.wikipedia.org/wiki/SHA-1">SHA1</a> signature.</a>
4247
 Any unique prefix is sufficient to identify a file
4348
 or version - usually the first 4 or 5 characters suffice.</li>
4449
 <li>The file format is trival and requires nothing more complex
4550
 than a text editor and the "sha1sum" command-line utility to decode.</li>
46
-<li>Automatic <a href="selfcheck.html">self-check</a>
51
+<li>Automatic <a href="selfcheck.wiki">self-check</a>
4752
 on repository changes makes it exceedingly
4853
 unlikely that data will ever be lost because of a software bug.</li>
4954
 </ul>
5055
51
-<h2>Objectives Of Fossil:</h2>
56
+<p>Objectives Of Fossil:</p>
5257
5358
 <ul>
5459
 <li>Fossil should be ridiculously easy to
55
-<a href="build.html">install</a> and
56
-<a href="quickstart.html">operate</a>.</li>
60
+<a href="build.wiki">install</a> and
61
+<a href="quickstart.wiki">operate</a>.</li>
5762
 <li>With fossil, it should be possible (and
58
-<a href="quickstart.html#serversetup">easy</a>) to set up a project
63
+<a href="quickstart.wiki#serversetup">easy</a>) to set up a project
5964
 on an inexpensive shared-hosting ISP
6065
 (example: <a href="http://www.he.net/hosting.html">Hurricane Electric</a>)
6166
 that provides nothing more than web space and CGI capability.
6267
 Here is <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">a demo</a>.</li>
6368
 <li>Fossil should provide in-depth historical and status information about the
@@ -71,18 +76,38 @@
7176
 </ul>
7277
7378
 <p>Other Links:</p>
7479
7580
 <ul>
76
-<li>The <a href="concepts.html">concepts</b> behind fossil</li>
77
-<li><a href="build.html">Building And Installing</a></li>
78
-<li><a href="quickstart.html">Quick Start</a> guide to using fossil
79
-<li><a href="pop.html">Principals Of Operation</a></li>
80
-<li>The <a href="selfcheck.html">automatic self-check</a> mechanism
81
+<li>The <a href="concepts.wiki">concepts</b> behind fossil</li>
82
+<li><a href="build.wiki">Building And Installing</a></li>
83
+<li><a href="quickstart.wiki">Quick Start</a> guide to using fossil
84
+<li><a href="pop.wiki">Principles Of Operation</a></li>
85
+<li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism
8186
 helps insure project integrity.</li>
82
-<li>The <a href="fileformat.html">file format</a> used by every content
87
+<li>The <a href="fileformat.wiki">file format</a> used by every content
8388
 file stored in the repository.</li>
84
-<li>The <a href="delta_format.html">format of deltas</a> used to
89
+<li>The <a href="delta_format.wiki">format of deltas</a> used to
8590
 efficiently store changes between file revisions.</li>
86
-<li>The <a href="delta_encoder_algorithm.html">encoder algorithm</a> used to
91
+<li>The <a href="delta_encoder_algorithm.wiki">encoder algorithm</a> used to
8792
 efficiently generate deltas.</li>
93
+<li>The <a href="sync.wiki">synchronization protocol</a>.</li>
94
+<li>There is a <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users">
95
+ mailing list</a> available for discussing fossil issues.</li>
96
+<li>The <a href="http://www.fossil-scm.org/fossil/wiki">self-hosting
97
+ fossil wiki</a>, capable of hosting static pages and community-editable wiki
98
+ content.</li>
99
+</ul>
100
+
101
+<p>Competing Projects:</p>
102
+
103
+<ul>
104
+<li><a href="http://www.ditrack.org/">DITrace</a>
105
+ - A Distributed Issue Tracker</li>
106
+<li><a href="http://www.distract.wellquite.org/">DisTract</a>
107
+ - Another distributed issue tracker based on
108
+ <a href="http://www.monotone.ca/">monotone</a>.</li>
109
+<li><a href="http://www.monotone.ca/">Monotone</a> - distributed
110
+ SCM in a single-file executable with a single-file SQLite
111
+ database repository.</li>
88112
 </ul>
113
+
89114
90115
DELETED www/pop.html
91116
ADDED www/pop.wiki
92117
DELETED www/quickstart.html
93118
ADDED www/quickstart.wiki
94119
DELETED www/selfcheck.html
95120
ADDED www/selfcheck.wiki
96121
DELETED www/sync.html
97122
ADDED www/sync.wiki
--- www/index.wiki
+++ www/index.wiki
@@ -1,27 +1,32 @@
1 <title>Fossil SCM Homepage</title>
2
 
3 This is a preliminary homepage for a new software configuration
4 management system called "Fossil".
5 The system is
6 <a href="http://fossil-scm.hwaci.com/fossil/timeline">self-hosting</a> on
7 <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">two separate servers</a>.
8 You can download the lastest sources
9 compile it yourself using the instructions below.
 
 
 
10
11 <h2>Design Goals For Fossil:</h1>
12
13 <ul>
14 <li>Supports disconnected, distributed development (like
15 <a href="http://kerneltrap.org/node/4982">git</a>,
16 <a href="http://www.venge.net/monotone/">monotone</a>,
17 <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or
18 <a href="http://www.bitkeeper.com/">bitkeeper</a>)
19 or client/server operation (like
20 <a href="http://www.nongnu.org/cvs/">CVS</a> or
21 <a href="http://subversion.tigris.org/">subversion</a>)
22 or both at the same time</li>
 
23 <li>Integrated bug tracking and wiki, along the lines of
24 <a href="http://www.cvstrac.org/">CVSTrac</a> and
25 <a href="http://www.edgewall.com/trac/">Trac</a>.</li>
26 <li>Built-in web interface that supports deep archaeological digs through
27 historical source code.</li>
@@ -41,23 +46,23 @@
41 <a href="http://en.wikipedia.org/wiki/SHA-1">SHA1</a> signature.</a>
42 Any unique prefix is sufficient to identify a file
43 or version - usually the first 4 or 5 characters suffice.</li>
44 <li>The file format is trival and requires nothing more complex
45 than a text editor and the "sha1sum" command-line utility to decode.</li>
46 <li>Automatic <a href="selfcheck.html">self-check</a>
47 on repository changes makes it exceedingly
48 unlikely that data will ever be lost because of a software bug.</li>
49 </ul>
50
51 <h2>Objectives Of Fossil:</h2>
52
53 <ul>
54 <li>Fossil should be ridiculously easy to
55 <a href="build.html">install</a> and
56 <a href="quickstart.html">operate</a>.</li>
57 <li>With fossil, it should be possible (and
58 <a href="quickstart.html#serversetup">easy</a>) to set up a project
59 on an inexpensive shared-hosting ISP
60 (example: <a href="http://www.he.net/hosting.html">Hurricane Electric</a>)
61 that provides nothing more than web space and CGI capability.
62 Here is <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">a demo</a>.</li>
63 <li>Fossil should provide in-depth historical and status information about the
@@ -71,18 +76,38 @@
71 </ul>
72
73 <p>Other Links:</p>
74
75 <ul>
76 <li>The <a href="concepts.html">concepts</b> behind fossil</li>
77 <li><a href="build.html">Building And Installing</a></li>
78 <li><a href="quickstart.html">Quick Start</a> guide to using fossil
79 <li><a href="pop.html">Principals Of Operation</a></li>
80 <li>The <a href="selfcheck.html">automatic self-check</a> mechanism
81 helps insure project integrity.</li>
82 <li>The <a href="fileformat.html">file format</a> used by every content
83 file stored in the repository.</li>
84 <li>The <a href="delta_format.html">format of deltas</a> used to
85 efficiently store changes between file revisions.</li>
86 <li>The <a href="delta_encoder_algorithm.html">encoder algorithm</a> used to
87 efficiently generate deltas.</li>
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
88 </ul>
 
89
90 ELETED www/pop.html
91 DDED www/pop.wiki
92 ELETED www/quickstart.html
93 DDED www/quickstart.wiki
94 ELETED www/selfcheck.html
95 DDED www/selfcheck.wiki
96 ELETED www/sync.html
97 DDED www/sync.wiki
--- www/index.wiki
+++ www/index.wiki
@@ -1,27 +1,32 @@
1 <h1>Fossil - A Software Configuration Management System</h1>
2
3 <p>
4 This is a preliminary homepage for a new software configuration
5 management system called "Fossil".
6 The system is
7 <a href="http://www.fossil-scm.org/fossil/timeline">self-hosting</a> on
8 <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">two separate servers</a>.
9 You can download the lastest sources
10 compile it yourself using the instructions below.
11 Or you can grab
12 <a href="http://www.fossil-scm.org/download.html">precompiled binaries</a>.
13 </p>
14
15 <p>Design Goals For Fossil:</p>
16
17 <ul>
18 <li>Supports disconnected, distributed development (like
19 <a href="http://kerneltrap.org/node/4982">git</a>,
20 <a href="http://www.monotone.ca/">monotone</a>,
21 <a href="http://www.selenic.com/mercurial/wiki/index.cgi">mercurial</a>, or
22 <a href="http://www.bitkeeper.com/">bitkeeper</a>)
23 or client/server operation (like
24 <a href="http://www.nongnu.org/cvs/">CVS</a> or
25 <a href="http://subversion.tigris.org/">subversion</a>),
26 or operations on local repositories,
27 or all three at the same time</li>
28 <li>Integrated bug tracking and wiki, along the lines of
29 <a href="http://www.cvstrac.org/">CVSTrac</a> and
30 <a href="http://www.edgewall.com/trac/">Trac</a>.</li>
31 <li>Built-in web interface that supports deep archaeological digs through
32 historical source code.</li>
@@ -41,23 +46,23 @@
46 <a href="http://en.wikipedia.org/wiki/SHA-1">SHA1</a> signature.</a>
47 Any unique prefix is sufficient to identify a file
48 or version - usually the first 4 or 5 characters suffice.</li>
49 <li>The file format is trival and requires nothing more complex
50 than a text editor and the "sha1sum" command-line utility to decode.</li>
51 <li>Automatic <a href="selfcheck.wiki">self-check</a>
52 on repository changes makes it exceedingly
53 unlikely that data will ever be lost because of a software bug.</li>
54 </ul>
55
56 <p>Objectives Of Fossil:</p>
57
58 <ul>
59 <li>Fossil should be ridiculously easy to
60 <a href="build.wiki">install</a> and
61 <a href="quickstart.wiki">operate</a>.</li>
62 <li>With fossil, it should be possible (and
63 <a href="quickstart.wiki#serversetup">easy</a>) to set up a project
64 on an inexpensive shared-hosting ISP
65 (example: <a href="http://www.he.net/hosting.html">Hurricane Electric</a>)
66 that provides nothing more than web space and CGI capability.
67 Here is <a href="http://www.hwaci.com/cgi-bin/fossil/timeline">a demo</a>.</li>
68 <li>Fossil should provide in-depth historical and status information about the
@@ -71,18 +76,38 @@
76 </ul>
77
78 <p>Other Links:</p>
79
80 <ul>
81 <li>The <a href="concepts.wiki">concepts</b> behind fossil</li>
82 <li><a href="build.wiki">Building And Installing</a></li>
83 <li><a href="quickstart.wiki">Quick Start</a> guide to using fossil
84 <li><a href="pop.wiki">Principles Of Operation</a></li>
85 <li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism
86 helps insure project integrity.</li>
87 <li>The <a href="fileformat.wiki">file format</a> used by every content
88 file stored in the repository.</li>
89 <li>The <a href="delta_format.wiki">format of deltas</a> used to
90 efficiently store changes between file revisions.</li>
91 <li>The <a href="delta_encoder_algorithm.wiki">encoder algorithm</a> used to
92 efficiently generate deltas.</li>
93 <li>The <a href="sync.wiki">synchronization protocol</a>.</li>
94 <li>There is a <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users">
95 mailing list</a> available for discussing fossil issues.</li>
96 <li>The <a href="http://www.fossil-scm.org/fossil/wiki">self-hosting
97 fossil wiki</a>, capable of hosting static pages and community-editable wiki
98 content.</li>
99 </ul>
100
101 <p>Competing Projects:</p>
102
103 <ul>
104 <li><a href="http://www.ditrack.org/">DITrace</a>
105 - A Distributed Issue Tracker</li>
106 <li><a href="http://www.distract.wellquite.org/">DisTract</a>
107 - Another distributed issue tracker based on
108 <a href="http://www.monotone.ca/">monotone</a>.</li>
109 <li><a href="http://www.monotone.ca/">Monotone</a> - distributed
110 SCM in a single-file executable with a single-file SQLite
111 database repository.</li>
112 </ul>
113
114
115 ELETED www/pop.html
116 DDED www/pop.wiki
117 ELETED www/quickstart.html
118 DDED www/quickstart.wiki
119 ELETED www/selfcheck.html
120 DDED www/selfcheck.wiki
121 ELETED www/sync.html
122 DDED www/sync.wiki
D www/pop.html
-84
--- a/www/pop.html
+++ b/www/pop.html
@@ -1,84 +0,0 @@
1
-<html>
2
-<head>
3
-<title>Fossil - Principles of Operation</title>
4
-</head>
5
-<body bgcolor="white">
6
-<p>[ <a href="index.html">Index</a> ]</p>
7
-<hr>
8
-<h1>Principles Of Operation</h1>
9
-
10
-<p>
11
-This page attempts to define the foundational principals upon
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>
25
-
26
-<li><p>Each repository has both global and local state. The
27
-global state is common to all repositories (or at least
28
-has the potential to be shared in common when the
29
-repositories are fully synchronized). The local state
30
-for each repository is private to that repository.
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
-the content of a baseline without the need for any
81
-special tools or software.</p></li>
82
-
83
-</body>
84
-</html>
--- a/www/pop.html
+++ b/www/pop.html
@@ -1,84 +0,0 @@
1 <html>
2 <head>
3 <title>Fossil - Principles of Operation</title>
4 </head>
5 <body bgcolor="white">
6 <p>[ <a href="index.html">Index</a> ]</p>
7 <hr>
8 <h1>Principles Of Operation</h1>
9
10 <p>
11 This page attempts to define the foundational principals upon
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>
25
26 <li><p>Each repository has both global and local state. The
27 global state is common to all repositories (or at least
28 has the potential to be shared in common when the
29 repositories are fully synchronized). The local state
30 for each repository is private to that repository.
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 the content of a baseline without the need for any
81 special tools or software.</p></li>
82
83 </body>
84 </html>
--- a/www/pop.html
+++ b/www/pop.html
@@ -1,84 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/pop.wiki
+44
--- a/www/pop.wiki
+++ b/www/pop.wiki
@@ -0,0 +1,44 @@
1
+<h1>Principles Of Operation</h1nciples Of Operation</title>
2
+
3
+<p>
4
+This page attempts to define the foundational principals upon
5
+which Fossil is built.
6
+</p>
7
+
8
+<ul>
9
+<li><p>ich Fossil is built.
10
+
11
+ *ctively "artare saved. The trail.</p></li>
12
+
13
+<li><p>A project resides in one orepository is administered of the others.</p></li>
14
+
15
+<li><p> of the others.
16
+
17
+ * and local state. The
18
+ glsitories (or at least
19
+ repositories are fully synchfor each repository is pThe glo bal state represents tThe local state identifieaccess policies f</p></li>
20
+
21
+<li><p>The global state of a repository is an unordered
22
+itory is an unordered
23
+ rtifact is named by a
24
+lowercase hexadecimal.
25
+In many contexts, the name can be
26
+exts, the name can be
27
+ abbrive- or six-character
28
+ </p></li>
29
+
30
+<li><p>dentify a file.
31
+
32
+ * Because artifacts are named by a cryptogc hash, all artifacts
33
+ are immut of an artifact also
34
+ baseline/li>
35
+
36
+<li><p>er">Principles Of Operation<title>Princ<h1 align="center"></p></li>
37
+
38
+<li><p></p></li> baseline1 hash encoded in repositories are fully synchronized). The local state
39
+ for repository is private to that repository.
40
+ The glohtmlstate rep The global state represents the artifacts.</p></li>
41
+
42
+<li><p> access policiestheir SHA1 unordered
43
+ collebaselinenordered
44
+ collectioshared.</p><
--- a/www/pop.wiki
+++ b/www/pop.wiki
@@ -0,0 +1,44 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--- a/www/pop.wiki
+++ b/www/pop.wiki
@@ -0,0 +1,44 @@
1 <h1>Principles Of Operation</h1nciples Of Operation</title>
2
3 <p>
4 This page attempts to define the foundational principals upon
5 which Fossil is built.
6 </p>
7
8 <ul>
9 <li><p>ich Fossil is built.
10
11 *ctively "artare saved. The trail.</p></li>
12
13 <li><p>A project resides in one orepository is administered of the others.</p></li>
14
15 <li><p> of the others.
16
17 * and local state. The
18 glsitories (or at least
19 repositories are fully synchfor each repository is pThe glo bal state represents tThe local state identifieaccess policies f</p></li>
20
21 <li><p>The global state of a repository is an unordered
22 itory is an unordered
23 rtifact is named by a
24 lowercase hexadecimal.
25 In many contexts, the name can be
26 exts, the name can be
27 abbrive- or six-character
28 </p></li>
29
30 <li><p>dentify a file.
31
32 * Because artifacts are named by a cryptogc hash, all artifacts
33 are immut of an artifact also
34 baseline/li>
35
36 <li><p>er">Principles Of Operation<title>Princ<h1 align="center"></p></li>
37
38 <li><p></p></li> baseline1 hash encoded in repositories are fully synchronized). The local state
39 for repository is private to that repository.
40 The glohtmlstate rep The global state represents the artifacts.</p></li>
41
42 <li><p> access policiestheir SHA1 unordered
43 collebaselinenordered
44 collectioshared.</p><
D www/quickstart.html
-279
--- a/www/quickstart.html
+++ b/www/quickstart.html
@@ -1,279 +0,0 @@
1
-<html>
2
-<title>Fossil - Quick Start</title>
3
-<body bgcolor="white">
4
-<p>[ <a href="index.html">Index</a> ]</p>
5
-<hr>
6
-<h1 align="center">Fossil Quick Start</h1>
7
-
8
-<p>This is a guide to get you started using fossil quickly
9
-and painlessly.</p>
10
-
11
-<h2>Installing</h2><blockquote>
12
-
13
- <p>Fossil is a single self-contained C program. You need to
14
- either download a <a href="download.html">precompiled binary</a>
15
- or <a href="build.html">build it yourself</a> from sources.
16
- Install fossil by putting the fossil binary
17
- someplace on your PATH environment variable.</p>
18
-
19
- </blockquote>
20
- <h2>Cloning A Existing Repository</h2>
21
- <blockquote>
22
-
23
- <p>Use this command:</p>
24
-
25
- <blockquote>
26
- <b>fossil clone</b> <i>URL repository-filename</i>
27
- </blockquote>
28
-
29
- <p>The <i>URL</i> above is the http URL for the fossil repository
30
- you want to clone. You can call the new repository anything you
31
- want - there are no naming restrictions. As an example, you can
32
- clone the fossil repository this way:</p>
33
-
34
- <blockquote>
35
- <b>fossil clone http://www.fossil-scm.org/fossil myclone.fsl</b>
36
- </blockquote>
37
-
38
- <p>Note: If you are behind a restrictive firewall, you might need
39
- to <a href="#proxy">specify an HTTP proxy</a> to use.</p>
40
-
41
-</blockquote><h2>Starting A New Project</h2><blockquote>
42
-
43
- <p>To start a new project with fossil, create a new empty repository
44
- this way:</p>
45
-
46
- <blockquote>
47
- <b>fossil new </b><i> repository-filename</i>
48
- </blockquote>
49
-
50
-</blockquote><h2>Configuring Your Local Repository</h2><blockquote>
51
-
52
- <p>When you create a new repository, either by cloning an existing
53
- project or create a new project of your own, you usually want to do some
54
- local configuration. This is accomplished using a webbrowser. First
55
- start a fossil webserver like this:</p>
56
-
57
- <blockquote>
58
- <b>fossil server </b><i> repository-filename</i>
59
- </blockquote>
60
-
61
- <p>This creates a mini-webserver listening on port 8080. You can
62
- specify a different port using the <b>-port</b> option on the command-line.
63
- After the server is running, point your webbrowser at
64
- http://localhost:8080/ and start configuring.</p>
65
-
66
- <p>By default, fossil does not require a login for HTTP connections
67
- coming in from the IP loopback address 127.0.0.1. You can, and perhaps
68
- should, change this after you create a few users.</p>
69
-
70
- <p>When you are finished configuring, just press Control-C or use
71
- the <b>kill</b> command to shut down the mini-server.</p>
72
-
73
-</blockquote><h2>Checking Out A Local Tree</h2><blockquote>
74
-
75
- <p>To work on a project in fossil, you need to check out a local
76
- copy of the source tree. Create the directory you want to be
77
- the root of your tree and cd into that directory. Then
78
- to this:</p>
79
-
80
- <blockquote>
81
- <b>fossil open </b><i> repository-filename</i>
82
- </blockquote>
83
-
84
- <p>This leaves you with the original (empty) version of the tree
85
- checked out. To get to the latest version, also do this:</p>
86
-
87
- <blockquote>
88
- <b>fossil update</b>
89
- </blockquote>
90
-
91
- <p>From anywhere underneath the root of your local tree, you
92
- can type commands like the following to find out the status of
93
- your local tree:</p>
94
-
95
- <blockquote>
96
- <b>fossil info</b><br>
97
- <b>fossil status</b><br>
98
- <b>fossil changes</b><br>
99
- <b>fossil timeline</b><br>
100
- <b>fossil leaves</b><br>
101
- <b>fossil ls</b><br>
102
- <b>fossil branches</b><br>
103
- </blockquote>
104
-
105
-</blockquote><h2>Making Changes</h2><blockquote>
106
-
107
- <p>To add new files to your project, or remove old files, use these
108
- commands:</p>
109
-
110
- <blockquote>
111
- <b>fossil add</b> <i>file...</i><br>
112
- <b>fossil rm</b> <i>file...</i>
113
- </blockquote>
114
-
115
- <p>You can also edit files freely. Once you are ready to commit
116
- your changes, type:</p>
117
-
118
- <blockquote>
119
- <b>fossil commit</b>
120
- </blockquote>
121
-
122
- <p>You will be prompted for check-in comments using whatever editor
123
- is specified by your VISUAL or EDITOR environment variable. If you
124
- have GPG installed, you may be prompted for your GPG passphrase so
125
- that the check-in can be signed with your GPG signature. After
126
- this your changes will be checked in.</p>
127
-
128
-</blockquote><h2>Sharing Changes</h2><blockquote>
129
-
130
- <p>The changes you <b>commit</b> are only on your local repository.
131
- To share those changes with other repositories, do:</p>
132
-
133
- <blockquote>
134
- <b>fossil push</b> <i>URL</i>
135
- </blockquote>
136
-
137
- <p>Where <i>URL</i> is the http: URL of the server repository you
138
- want to share your changes with. If you omit the <i>URL</i> argument,
139
- fossil will use whatever server you most recently synced with.</p>
140
-
141
- <p>The <b>push</b> command only sends your changes to others. To
142
- Receive changes from others, use <b>pull</b>. Or go both ways at
143
- once using <b>sync</b>:</p>
144
-
145
- <blockquote>
146
- <b>fossil pull</b> <i>URL</i><br>
147
- <b>fossil sync</b> <i>URL</i>
148
- </blockquote>
149
-
150
- <p>When you pull in changes from others, they go into your repository,
151
- not into your checked-out local tree. To get the changes into your
152
- local tree, use <b>update</b>:</p>
153
-
154
- <blockquote>
155
- <b>fossil update</b> <i>UUID</i>
156
- </blockquote>
157
-
158
- <p>The <i>UUID</i> is some unique abbreviation to the 40-character
159
- version ID. If you omit the <i>UUID</i> fossil moves you to the
160
- leaf version of the branch your are currently on. If your branch
161
- has multiple leaves, you get an error - you'll have to specify the
162
- leaf you want using a <i>UUID</i> argument.</p>
163
-
164
-</blockquote><h2>Branching And Merging</h2><blockquote>
165
-
166
- <p>You can create branches by doing multiple commits off of the
167
- same base version. To merge to branches back together, first
168
- <b>update</b> to the leaf of one branch. Then do a <b>merge</b>
169
- of the leaf of the other branch:</p>
170
-
171
- <blockquote>
172
- <b>fossil merge</b> <i>UUID</i>
173
- </blockquote>
174
-
175
- <p>Test to make sure your merge didn't mess up the code, then
176
- <b>commit</b> and possibly also <b>push</b> your changes. Remember
177
- that nobody else can see your changes until you <b>commit</b> and
178
- if other are using a different repository you will also need to
179
- <b>push</b>.</p>
180
-
181
-<a name="serversetup">
182
-</blockquote><h2>Setting Up A Server</h2><blockquote>
183
-
184
- <p>The easiest way to set up a server is:</p>
185
-
186
- <blockquote>
187
- <b>fossil server</b> <i>repository-filename</i>
188
- </blockquote>
189
-
190
- <p>You can omit the <i>repository-filename</i> if you are within
191
- a checked-out local tree. This server uses port 8080 by default
192
- but you can specify a different port using the <b>-port</b> command.</p>
193
-
194
- <p>Command-line servers like this are useful when two people want
195
- to share a repository on temporary or ad-hoc basis. For a more
196
- permanent installation, you should use either the CGI server or the
197
- inetd server. To use the CGI server, create a CGI script that
198
- looks something like this:</p>
199
-
200
- <blockquote><b>
201
- #!/usr/local/bin/fossil<br>
202
- repository: /home/proj1/repos1.fsl
203
- </b></blockquote>
204
-
205
- <p>Adjust the paths in this CGI script to match your installation.
206
- Now point clients at the CGI script. That's all there is to it!</p>
207
-
208
- <p>You can also run fossil off of inetd or xinetd. For an inetd
209
- installation, make an entry in /etc/inetd.conf that looks something
210
- like this:</p>
211
-
212
- <blockquote><b>
213
- 80 stream tcp nowait.1000 root /usr/bin/fossil \<br>
214
- /usr/bin/fossil http /home/proj1/repos1.fsl
215
- </b></blockquote>
216
-
217
- <p>Adjust the paths to suit your installation, of course. Notice that
218
- fossil runs as root. This is not required - you can run it as an
219
- unprivileged user. But it is more secure to run fossil as root.
220
- When you do run fossil as root, it automatically puts itself in a
221
- chroot jail in the same directory as the repository, then drops
222
- root privileges prior to reading any information from the request.</p>
223
-
224
-</blockquote><a name="proxy"></a><h2>HTTP Proxies</h2><blockquote>
225
-
226
- <p>If you are behind a restrictive firewall that requires you to use
227
- an HTTP proxy to reach the internet, then you can configure the proxy
228
- in three different ways. You can tell fossil about your proxy using
229
- a command-line option on commands that use the network,
230
- <b>sync</b>, <b>clone</b>, <b>push</b>, and <b>pull</b>.</p>
231
-
232
- <blockquote>
233
- <b>fossil clone </b><i>URL</i> <b>--proxy</b> <i>Proxy-URL</i>
234
- </blockquote>
235
-
236
- <p>It is annoying to have to type in the proxy URL every time you
237
- sync your project, though, so you can make the proxy configuration
238
- persistent using the <b>setting</b> command:</p>
239
-
240
- <blockquote>
241
- <b>fossil setting proxy </b><i>Proxy-URL</i>
242
- </blockquote>
243
-
244
- <p>Or, you can set the "<b>http_proxy</b>" environment variable:</p>
245
-
246
- <blockquote>
247
- <b>export http_proxy=</b><i>Proxy-URL</i>
248
- </blockquote>
249
-
250
- <p>To stop using the proxy, do:</p>
251
-
252
- <blockquote>
253
- <b>fossil setting proxy off</b>
254
- </blockquote>
255
-
256
- <p>Or unset the environment variable. The fossil setting for the
257
- HTTP proxy takes precedence over the environment variable and the
258
- command-line option overrides both. If you have an persistent
259
- proxy setting that you want to override for a one-time sync, that
260
- is easily done on the command-line. For example, to sync with
261
- a co-workers repository on your LAN, you might type:</p>
262
-
263
- <blockquote>
264
- <b>fossil sync http://192.168.1.36:8080/ --proxy off</b>
265
- </blockquote>
266
-
267
-</blockquote><h2>More Hints</h2><blockquote>
268
-
269
- <p>Try these commands:</p>
270
-
271
- <blockquote><b>
272
- fossil help<br>
273
- fossil test-commands
274
- </b></blockquote>
275
-
276
- <p>Explore and have fun!</p>
277
-
278
-
279
-</blockquote></body></html>
--- a/www/quickstart.html
+++ b/www/quickstart.html
@@ -1,279 +0,0 @@
1 <html>
2 <title>Fossil - Quick Start</title>
3 <body bgcolor="white">
4 <p>[ <a href="index.html">Index</a> ]</p>
5 <hr>
6 <h1 align="center">Fossil Quick Start</h1>
7
8 <p>This is a guide to get you started using fossil quickly
9 and painlessly.</p>
10
11 <h2>Installing</h2><blockquote>
12
13 <p>Fossil is a single self-contained C program. You need to
14 either download a <a href="download.html">precompiled binary</a>
15 or <a href="build.html">build it yourself</a> from sources.
16 Install fossil by putting the fossil binary
17 someplace on your PATH environment variable.</p>
18
19 </blockquote>
20 <h2>Cloning A Existing Repository</h2>
21 <blockquote>
22
23 <p>Use this command:</p>
24
25 <blockquote>
26 <b>fossil clone</b> <i>URL repository-filename</i>
27 </blockquote>
28
29 <p>The <i>URL</i> above is the http URL for the fossil repository
30 you want to clone. You can call the new repository anything you
31 want - there are no naming restrictions. As an example, you can
32 clone the fossil repository this way:</p>
33
34 <blockquote>
35 <b>fossil clone http://www.fossil-scm.org/fossil myclone.fsl</b>
36 </blockquote>
37
38 <p>Note: If you are behind a restrictive firewall, you might need
39 to <a href="#proxy">specify an HTTP proxy</a> to use.</p>
40
41 </blockquote><h2>Starting A New Project</h2><blockquote>
42
43 <p>To start a new project with fossil, create a new empty repository
44 this way:</p>
45
46 <blockquote>
47 <b>fossil new </b><i> repository-filename</i>
48 </blockquote>
49
50 </blockquote><h2>Configuring Your Local Repository</h2><blockquote>
51
52 <p>When you create a new repository, either by cloning an existing
53 project or create a new project of your own, you usually want to do some
54 local configuration. This is accomplished using a webbrowser. First
55 start a fossil webserver like this:</p>
56
57 <blockquote>
58 <b>fossil server </b><i> repository-filename</i>
59 </blockquote>
60
61 <p>This creates a mini-webserver listening on port 8080. You can
62 specify a different port using the <b>-port</b> option on the command-line.
63 After the server is running, point your webbrowser at
64 http://localhost:8080/ and start configuring.</p>
65
66 <p>By default, fossil does not require a login for HTTP connections
67 coming in from the IP loopback address 127.0.0.1. You can, and perhaps
68 should, change this after you create a few users.</p>
69
70 <p>When you are finished configuring, just press Control-C or use
71 the <b>kill</b> command to shut down the mini-server.</p>
72
73 </blockquote><h2>Checking Out A Local Tree</h2><blockquote>
74
75 <p>To work on a project in fossil, you need to check out a local
76 copy of the source tree. Create the directory you want to be
77 the root of your tree and cd into that directory. Then
78 to this:</p>
79
80 <blockquote>
81 <b>fossil open </b><i> repository-filename</i>
82 </blockquote>
83
84 <p>This leaves you with the original (empty) version of the tree
85 checked out. To get to the latest version, also do this:</p>
86
87 <blockquote>
88 <b>fossil update</b>
89 </blockquote>
90
91 <p>From anywhere underneath the root of your local tree, you
92 can type commands like the following to find out the status of
93 your local tree:</p>
94
95 <blockquote>
96 <b>fossil info</b><br>
97 <b>fossil status</b><br>
98 <b>fossil changes</b><br>
99 <b>fossil timeline</b><br>
100 <b>fossil leaves</b><br>
101 <b>fossil ls</b><br>
102 <b>fossil branches</b><br>
103 </blockquote>
104
105 </blockquote><h2>Making Changes</h2><blockquote>
106
107 <p>To add new files to your project, or remove old files, use these
108 commands:</p>
109
110 <blockquote>
111 <b>fossil add</b> <i>file...</i><br>
112 <b>fossil rm</b> <i>file...</i>
113 </blockquote>
114
115 <p>You can also edit files freely. Once you are ready to commit
116 your changes, type:</p>
117
118 <blockquote>
119 <b>fossil commit</b>
120 </blockquote>
121
122 <p>You will be prompted for check-in comments using whatever editor
123 is specified by your VISUAL or EDITOR environment variable. If you
124 have GPG installed, you may be prompted for your GPG passphrase so
125 that the check-in can be signed with your GPG signature. After
126 this your changes will be checked in.</p>
127
128 </blockquote><h2>Sharing Changes</h2><blockquote>
129
130 <p>The changes you <b>commit</b> are only on your local repository.
131 To share those changes with other repositories, do:</p>
132
133 <blockquote>
134 <b>fossil push</b> <i>URL</i>
135 </blockquote>
136
137 <p>Where <i>URL</i> is the http: URL of the server repository you
138 want to share your changes with. If you omit the <i>URL</i> argument,
139 fossil will use whatever server you most recently synced with.</p>
140
141 <p>The <b>push</b> command only sends your changes to others. To
142 Receive changes from others, use <b>pull</b>. Or go both ways at
143 once using <b>sync</b>:</p>
144
145 <blockquote>
146 <b>fossil pull</b> <i>URL</i><br>
147 <b>fossil sync</b> <i>URL</i>
148 </blockquote>
149
150 <p>When you pull in changes from others, they go into your repository,
151 not into your checked-out local tree. To get the changes into your
152 local tree, use <b>update</b>:</p>
153
154 <blockquote>
155 <b>fossil update</b> <i>UUID</i>
156 </blockquote>
157
158 <p>The <i>UUID</i> is some unique abbreviation to the 40-character
159 version ID. If you omit the <i>UUID</i> fossil moves you to the
160 leaf version of the branch your are currently on. If your branch
161 has multiple leaves, you get an error - you'll have to specify the
162 leaf you want using a <i>UUID</i> argument.</p>
163
164 </blockquote><h2>Branching And Merging</h2><blockquote>
165
166 <p>You can create branches by doing multiple commits off of the
167 same base version. To merge to branches back together, first
168 <b>update</b> to the leaf of one branch. Then do a <b>merge</b>
169 of the leaf of the other branch:</p>
170
171 <blockquote>
172 <b>fossil merge</b> <i>UUID</i>
173 </blockquote>
174
175 <p>Test to make sure your merge didn't mess up the code, then
176 <b>commit</b> and possibly also <b>push</b> your changes. Remember
177 that nobody else can see your changes until you <b>commit</b> and
178 if other are using a different repository you will also need to
179 <b>push</b>.</p>
180
181 <a name="serversetup">
182 </blockquote><h2>Setting Up A Server</h2><blockquote>
183
184 <p>The easiest way to set up a server is:</p>
185
186 <blockquote>
187 <b>fossil server</b> <i>repository-filename</i>
188 </blockquote>
189
190 <p>You can omit the <i>repository-filename</i> if you are within
191 a checked-out local tree. This server uses port 8080 by default
192 but you can specify a different port using the <b>-port</b> command.</p>
193
194 <p>Command-line servers like this are useful when two people want
195 to share a repository on temporary or ad-hoc basis. For a more
196 permanent installation, you should use either the CGI server or the
197 inetd server. To use the CGI server, create a CGI script that
198 looks something like this:</p>
199
200 <blockquote><b>
201 #!/usr/local/bin/fossil<br>
202 repository: /home/proj1/repos1.fsl
203 </b></blockquote>
204
205 <p>Adjust the paths in this CGI script to match your installation.
206 Now point clients at the CGI script. That's all there is to it!</p>
207
208 <p>You can also run fossil off of inetd or xinetd. For an inetd
209 installation, make an entry in /etc/inetd.conf that looks something
210 like this:</p>
211
212 <blockquote><b>
213 80 stream tcp nowait.1000 root /usr/bin/fossil \<br>
214 /usr/bin/fossil http /home/proj1/repos1.fsl
215 </b></blockquote>
216
217 <p>Adjust the paths to suit your installation, of course. Notice that
218 fossil runs as root. This is not required - you can run it as an
219 unprivileged user. But it is more secure to run fossil as root.
220 When you do run fossil as root, it automatically puts itself in a
221 chroot jail in the same directory as the repository, then drops
222 root privileges prior to reading any information from the request.</p>
223
224 </blockquote><a name="proxy"></a><h2>HTTP Proxies</h2><blockquote>
225
226 <p>If you are behind a restrictive firewall that requires you to use
227 an HTTP proxy to reach the internet, then you can configure the proxy
228 in three different ways. You can tell fossil about your proxy using
229 a command-line option on commands that use the network,
230 <b>sync</b>, <b>clone</b>, <b>push</b>, and <b>pull</b>.</p>
231
232 <blockquote>
233 <b>fossil clone </b><i>URL</i> <b>--proxy</b> <i>Proxy-URL</i>
234 </blockquote>
235
236 <p>It is annoying to have to type in the proxy URL every time you
237 sync your project, though, so you can make the proxy configuration
238 persistent using the <b>setting</b> command:</p>
239
240 <blockquote>
241 <b>fossil setting proxy </b><i>Proxy-URL</i>
242 </blockquote>
243
244 <p>Or, you can set the "<b>http_proxy</b>" environment variable:</p>
245
246 <blockquote>
247 <b>export http_proxy=</b><i>Proxy-URL</i>
248 </blockquote>
249
250 <p>To stop using the proxy, do:</p>
251
252 <blockquote>
253 <b>fossil setting proxy off</b>
254 </blockquote>
255
256 <p>Or unset the environment variable. The fossil setting for the
257 HTTP proxy takes precedence over the environment variable and the
258 command-line option overrides both. If you have an persistent
259 proxy setting that you want to override for a one-time sync, that
260 is easily done on the command-line. For example, to sync with
261 a co-workers repository on your LAN, you might type:</p>
262
263 <blockquote>
264 <b>fossil sync http://192.168.1.36:8080/ --proxy off</b>
265 </blockquote>
266
267 </blockquote><h2>More Hints</h2><blockquote>
268
269 <p>Try these commands:</p>
270
271 <blockquote><b>
272 fossil help<br>
273 fossil test-commands
274 </b></blockquote>
275
276 <p>Explore and have fun!</p>
277
278
279 </blockquote></body></html>
--- a/www/quickstart.html
+++ b/www/quickstart.html
@@ -1,279 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/quickstart.wiki
+140
--- a/www/quickstart.wiki
+++ b/www/quickstart.wiki
@@ -0,0 +1,140 @@
1
+2 timelinePATH 1 2nowiki 2V,D:<bPATH 1 2nowiki 2 J@24V,D:<br>
2
+ 15@24o,q:<br>
3
+ e [=======<br>
4
+ G@2 nicate.c<br>
5
+ @@ -1,10 +1,11 <ul>
6
+ @@ -<:<br>t<br<a href="download.wiki">FIXME ssil commit </,A:<ED README.md<br configuration).
7
+ </ul>
8
+
9
+ br>
10
+</tt></b>
11
+</blonew|fossil newX:blo ckquote>
12
+<b>fossil ui </b><i> Q@2sE,9:blockquot6n@2sf,9</p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ @3FR@bk,S timelinePh2>Cloning A9</p>:blockquo tW<a nar>
13
+ e wiki 2 tinePATH 1 2nowiki 2V,D:<bPATH 1 2nowiki 2 J@24V,D:<br>
14
+ 15@24o,q:<br>
15
+ e [=======<br>
16
+ G@2 nicate.c<br>
17
+ @@ -1,10 +1,11 <ul>
18
+ @@ -<:<br>t<br>
19
+</tt>/tt></b>
20
+</blockquot30@29p,c:<blockquote>
21
+<b>
22
+fossil commit </,A:<ED README.md<br configuration).
23
+ </ul>
24
+
25
+ br>
26
+</tt></b>
27
+</blonew|fossil newX:blo ckquote>
28
+<b>fossil ui <slCloning onlyon).
29
+ </ul>
30
+
31
+ the source tree (as a single </,A:<ED README.md<br configuration).
32
+H /p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ toe>
33
+<b>
34
+fossil commitopenyoutk@4kL,start the web brows080/. Click on the
35
+ "Admin" link on the menu bar to start configuring your repository</tt></b>
36
+</blonewhecked out tree in place to work from.
37
+ The resultingG,h23hr;ifrom a repository Setup a new Fossil
38
+defablo,te>
39
+<b><fot2s@3GE,F:
40
+only changes"> @@ -<:<br>a webbrowser. First
41
+ start a>
42
+fossil commit </,A:<ED README.md<br configuration).
43
+ </ul>
44
+
45
+ br>
46
+server listeningoption on the command-line.
47
+ Aftcreates a mini-ine.
48
+ Aftcreates startsmmand-line.
49
+ After the server is running, fossil will then attempt to launch ckquote>
50
+<b>fossil ui </b><> Q@serverE,9:blockquot6n@2sf,9</p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ @3FR@bk,S7@4DA,9:block </blwill give y/blockquote> youtk@4kL,start the web browser
51
+ yourself and point it at http://localhost:8080point your webbrowser at
52
+ http://localhost:8080/ and start configuringcate.c<br>
53
+ @@ -1,10 +1,11 <ul>
54
+ @@ -<:<br>t<br>
55
+</tt>/tt></b>
56
+</blockquot30@29p,c:<blockquote>
57
+<b>
58
+fossil commit </,A:<ED README.md<br configuration).
59
+ </ul>
60
+
61
+ br>
62
+</tt></b>
63
+</blonew|fossil newX:blo ckquote>
64
+<b>fossil ui <slCloning onlyon).
65
+ </ul>
66
+
67
+ the source tree (as a single </,A:<ED README.md<br configuration).
68
+H /p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ toe>
69
+<b>
70
+fossil commitopenyoutk@4kL,start the web brows080/. Click on the
71
+ "Admin" link on the menu bar to start configuring your repository</tt></b>
72
+</blonewhecked out tree in place to work from.
73
+ The resultingG,h23hr;ifrom a repository Setup a new Fossil
74
+defablo,te>
75
+<b><fot2s@3GE,F:
76
+only changoriginal (empty)er. First
77
+ To get to mpt to launch ckquote>
78
+<b>fossil ui </b><> Q@2sE,9:blockquot6n@2sf,9</p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ @3FR@bk,S7@4DA,9:block </blwill give y/blockquote> youtk@4kL,start the web browser
79
+ yourself and point it at http://localhost:8080/. Click on the
80
+ "Admin" link on the menu bar to start configuring your repository</tt></b>
81
+</blonewhecked out tree in place to work from.
82
+ The resultingG,h23hr;ifrom a repository Setup a new Fossil
83
+defablo,te>
84
+<b><fot2s@3GE,F:
85
+only changes">Mak, or remove old files, useYou can also ed are readnew"sthat repository file atbothoff ofes</b><br listesbaselineUUID/p>:blockquo tW@2zU,
86
+ <p>The <i>UUversion ID. If you omit the <i>UUUUnowiki 2 timelinePATH 1 2nowiki 2V,D:<bPATH 1 2nowiki 2 J@24V,D:<br>
87
+ 15@24o,q:<br>
88
+ e [=======<br>
89
+ G@2 nicate.c<br>
90
+ @@ -1,10 +1,11 <ul>
91
+ @@ -<:<br>t<br>
92
+</tt>/tt></b>
93
+</blockquot30@29p,c:<blockquote>
94
+<b>
95
+fossil commit </,A:<ED README.md<br configuration).
96
+H /p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ toe>
97
+<b>
98
+fossil commitopenyoutk@4kL,start the web brows080/. Click on the
99
+ "Admin" link on the menu bar to start configuring your repository</tt></b>
100
+</blonewhecked out tree in place to work from.
101
+ The resultingG,h23hr;ifrom a repository Setup a new Fossil
102
+defablo,te>
103
+<b><fot2s@3GE,F:
104
+only changes">Mak, or remove old files, useYou can also ed are readnew"sthat repository file atbothoff ofes</b><br listesbaseline.
105
+ Nowto work from.
106
+ sspdate2nowiki 2 timelinePmelinePATH :<ED README.md<br configuration).
107
+ </ul>
108
+
109
+ br>
110
+server listeningoption on the command-line.
111
+ Aftcreates a mini-ine.
112
+ Aftcreates startsmmand-line.
113
+ After the server is running, fossil will then attempt to launch ckquote>
114
+<b>fossil ui </b><> Q@2sE,9:blockquot6n@2sf,9</p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ @3FR@bk,S7@4DA,9:block </blwill give y/blockquote> youtk@4kL,start the web browser
115
+ yourself and point it at http://localhost:8080/. Click on the
116
+ "Admin" link on the menu bar to start configuring your repository</tt></b>
117
+</blonewhecked out tree in place to work from.
118
+ The resultingG,h23hr;ifrom a repository Setup a new Fossil
119
+defablo,te>
120
+<b><fot2s@3GE,F:
121
+only changes">Mak, or remove old files, useYou can also ed are readnew"sthat repository file atbothoff ofes</b><br listesbaselineUUID/p>:blockquo tW@2zU,
122
+ <p>The <i>UUversion ID. If you omit the <i>UUUUnowiki 2 timelinePATH 1 2nowiki 2V,D:<bPATH 1 2nowiki 2 J@24V,D:<br>
123
+ 15@24o,q:<br>
124
+ e [=======<br>
125
+ G@2 nicate.c<br>
126
+ @@ -1,10 +1,11 <ul>
127
+ @@ -<:<br>t<br>
128
+</tt>/tt></b>
129
+</blockquot30@29p,c:<blockquote>
130
+<b>
131
+fossil commit </,A:<ED README.md<br configuration).
132
+H /p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ toe>
133
+<b>
134
+fossil commitopenyoutk@4kL,start the web brows080/. Click on the
135
+ "Admin" link on the menu bar to start configuring your repository</tt></b>
136
+</blonewhecked out tree in place to work from.
137
+ The resultingG,h23hr;ifrom a repository Setup a new Fossil
138
+defablo,te>
139
+<b><fot2s@3GE,F:
140
+only change
--- a/www/quickstart.wiki
+++ b/www/quickstart.wiki
@@ -0,0 +1,140 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--- a/www/quickstart.wiki
+++ b/www/quickstart.wiki
@@ -0,0 +1,140 @@
1 2 timelinePATH 1 2nowiki 2V,D:<bPATH 1 2nowiki 2 J@24V,D:<br>
2 15@24o,q:<br>
3 e [=======<br>
4 G@2 nicate.c<br>
5 @@ -1,10 +1,11 <ul>
6 @@ -<:<br>t<br<a href="download.wiki">FIXME ssil commit </,A:<ED README.md<br configuration).
7 </ul>
8
9 br>
10 </tt></b>
11 </blonew|fossil newX:blo ckquote>
12 <b>fossil ui </b><i> Q@2sE,9:blockquot6n@2sf,9</p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ @3FR@bk,S timelinePh2>Cloning A9</p>:blockquo tW<a nar>
13 e wiki 2 tinePATH 1 2nowiki 2V,D:<bPATH 1 2nowiki 2 J@24V,D:<br>
14 15@24o,q:<br>
15 e [=======<br>
16 G@2 nicate.c<br>
17 @@ -1,10 +1,11 <ul>
18 @@ -<:<br>t<br>
19 </tt>/tt></b>
20 </blockquot30@29p,c:<blockquote>
21 <b>
22 fossil commit </,A:<ED README.md<br configuration).
23 </ul>
24
25 br>
26 </tt></b>
27 </blonew|fossil newX:blo ckquote>
28 <b>fossil ui <slCloning onlyon).
29 </ul>
30
31 the source tree (as a single </,A:<ED README.md<br configuration).
32 H /p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ toe>
33 <b>
34 fossil commitopenyoutk@4kL,start the web brows080/. Click on the
35 "Admin" link on the menu bar to start configuring your repository</tt></b>
36 </blonewhecked out tree in place to work from.
37 The resultingG,h23hr;ifrom a repository Setup a new Fossil
38 defablo,te>
39 <b><fot2s@3GE,F:
40 only changes"> @@ -<:<br>a webbrowser. First
41 start a>
42 fossil commit </,A:<ED README.md<br configuration).
43 </ul>
44
45 br>
46 server listeningoption on the command-line.
47 Aftcreates a mini-ine.
48 Aftcreates startsmmand-line.
49 After the server is running, fossil will then attempt to launch ckquote>
50 <b>fossil ui </b><> Q@serverE,9:blockquot6n@2sf,9</p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ @3FR@bk,S7@4DA,9:block </blwill give y/blockquote> youtk@4kL,start the web browser
51 yourself and point it at http://localhost:8080point your webbrowser at
52 http://localhost:8080/ and start configuringcate.c<br>
53 @@ -1,10 +1,11 <ul>
54 @@ -<:<br>t<br>
55 </tt>/tt></b>
56 </blockquot30@29p,c:<blockquote>
57 <b>
58 fossil commit </,A:<ED README.md<br configuration).
59 </ul>
60
61 br>
62 </tt></b>
63 </blonew|fossil newX:blo ckquote>
64 <b>fossil ui <slCloning onlyon).
65 </ul>
66
67 the source tree (as a single </,A:<ED README.md<br configuration).
68 H /p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ toe>
69 <b>
70 fossil commitopenyoutk@4kL,start the web brows080/. Click on the
71 "Admin" link on the menu bar to start configuring your repository</tt></b>
72 </blonewhecked out tree in place to work from.
73 The resultingG,h23hr;ifrom a repository Setup a new Fossil
74 defablo,te>
75 <b><fot2s@3GE,F:
76 only changoriginal (empty)er. First
77 To get to mpt to launch ckquote>
78 <b>fossil ui </b><> Q@2sE,9:blockquot6n@2sf,9</p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ @3FR@bk,S7@4DA,9:block </blwill give y/blockquote> youtk@4kL,start the web browser
79 yourself and point it at http://localhost:8080/. Click on the
80 "Admin" link on the menu bar to start configuring your repository</tt></b>
81 </blonewhecked out tree in place to work from.
82 The resultingG,h23hr;ifrom a repository Setup a new Fossil
83 defablo,te>
84 <b><fot2s@3GE,F:
85 only changes">Mak, or remove old files, useYou can also ed are readnew"sthat repository file atbothoff ofes</b><br listesbaselineUUID/p>:blockquo tW@2zU,
86 <p>The <i>UUversion ID. If you omit the <i>UUUUnowiki 2 timelinePATH 1 2nowiki 2V,D:<bPATH 1 2nowiki 2 J@24V,D:<br>
87 15@24o,q:<br>
88 e [=======<br>
89 G@2 nicate.c<br>
90 @@ -1,10 +1,11 <ul>
91 @@ -<:<br>t<br>
92 </tt>/tt></b>
93 </blockquot30@29p,c:<blockquote>
94 <b>
95 fossil commit </,A:<ED README.md<br configuration).
96 H /p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ toe>
97 <b>
98 fossil commitopenyoutk@4kL,start the web brows080/. Click on the
99 "Admin" link on the menu bar to start configuring your repository</tt></b>
100 </blonewhecked out tree in place to work from.
101 The resultingG,h23hr;ifrom a repository Setup a new Fossil
102 defablo,te>
103 <b><fot2s@3GE,F:
104 only changes">Mak, or remove old files, useYou can also ed are readnew"sthat repository file atbothoff ofes</b><br listesbaseline.
105 Nowto work from.
106 sspdate2nowiki 2 timelinePmelinePATH :<ED README.md<br configuration).
107 </ul>
108
109 br>
110 server listeningoption on the command-line.
111 Aftcreates a mini-ine.
112 Aftcreates startsmmand-line.
113 After the server is running, fossil will then attempt to launch ckquote>
114 <b>fossil ui </b><> Q@2sE,9:blockquot6n@2sf,9</p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ @3FR@bk,S7@4DA,9:block </blwill give y/blockquote> youtk@4kL,start the web browser
115 yourself and point it at http://localhost:8080/. Click on the
116 "Admin" link on the menu bar to start configuring your repository</tt></b>
117 </blonewhecked out tree in place to work from.
118 The resultingG,h23hr;ifrom a repository Setup a new Fossil
119 defablo,te>
120 <b><fot2s@3GE,F:
121 only changes">Mak, or remove old files, useYou can also ed are readnew"sthat repository file atbothoff ofes</b><br listesbaselineUUID/p>:blockquo tW@2zU,
122 <p>The <i>UUversion ID. If you omit the <i>UUUUnowiki 2 timelinePATH 1 2nowiki 2V,D:<bPATH 1 2nowiki 2 J@24V,D:<br>
123 15@24o,q:<br>
124 e [=======<br>
125 G@2 nicate.c<br>
126 @@ -1,10 +1,11 <ul>
127 @@ -<:<br>t<br>
128 </tt>/tt></b>
129 </blockquot30@29p,c:<blockquote>
130 <b>
131 fossil commit </,A:<ED README.md<br configuration).
132 H /p>:blockquo tW@2zU,A<p>To7v,9:blockquot5y@ toe>
133 <b>
134 fossil commitopenyoutk@4kL,start the web brows080/. Click on the
135 "Admin" link on the menu bar to start configuring your repository</tt></b>
136 </blonewhecked out tree in place to work from.
137 The resultingG,h23hr;ifrom a repository Setup a new Fossil
138 defablo,te>
139 <b><fot2s@3GE,F:
140 only change
D www/selfcheck.html
-99
--- a/www/selfcheck.html
+++ b/www/selfcheck.html
@@ -1,99 +0,0 @@
1
-<html>
2
-<head>
3
-<title>Fossil Repository Integrity Self-Checks</title>
4
-</head>
5
-<body bgcolor="white">
6
-<p>[ <a href="index.html">Index</a> ]</p>
7
-<hr>
8
-<h1 align="center">
9
-Fossil Repository Integrity Self-Checks
10
-</h1>
11
-
12
-<p>
13
-Even though fossil is a relatively new project and still contains
14
-many bugs, it is designed with features to give it a high level
15
-of integrity so that you can have confidence that you will not
16
-lose your files. This note describes the defensive measures that
17
-fossil uses to help prevent file loss due to bugs.
18
-</p>
19
-
20
-<p><i>Follow-up as of 2007-11-24:</i>
21
-Fossil has been hosting itself and several other projects for
22
-months now. Many bugs have been encountered. But, thanks in large
23
-part to the defensive measures described here, no data has been
24
-lost. The integrity checks are doing their job well.</p>
25
-
26
-<h2>Atomic Check-ins With Rollback</h2>
27
-
28
-<p>
29
-The fossil repository is an
30
-<a href="http://www.sqlite.org/">SQLite version 3</a> database file.
31
-SQLite is very mature and stable and has been in wide-spread use for many
32
-years, so we have little worries that it might cause repository
33
-corruption. SQLite
34
-databases do not corrupt even if a program or system crash or power
35
-failure occurs in the middle of the update. If some kind of crash
36
-does occur in the middle of a change, then all the changes are rolled
37
-back the next time that the database is accessed.
38
-</p>
39
-
40
-<p>
41
-A check-in operation in fossil makes many changes to the repository
42
-database. But all these changes happen within a single transaction.
43
-If something goes wrong in the middle of the commit, then the transaction
44
-is rolled back and the database is unchanged.
45
-</p>
46
-
47
-<h2>Verification Of Delta Encodings Prior To Transaction Commit</h2>
48
-
49
-<p>
50
-The content files that comprise the global state of a fossil respository
51
-are stored in the repository as a tree. The leaves of the tree are
52
-stored as zlib-compressed BLOBs. Interior nodes are deltas from their
53
-decendants. A lot of encoding is going on. There is
54
-zlib-compression which is relatively well-tested but still might
55
-cause corruption if used improperly. And there is the relatively
56
-new delta-encoding mechanism designed expressly for fossil. We want
57
-to make sure that bugs in these encoding mechanisms do not lead to
58
-loss of data.
59
-</p>
60
-
61
-<p>
62
-To increase our confidence that everything in the repository is
63
-recoverable, fossil makes sure it can extract an exact replicate
64
-of every content file that it changes just prior to transaction
65
-commit. So during the course of check-in (or other repository
66
-operation) many different files
67
-in the repository might be modified. Some files are simply
68
-compressed. Other files are delta encoded and then compressed.
69
-While all this is going on, fossil makes a record of every file
70
-that is encoded and the SHA1 hash of the original content of that
71
-file. Then just before transaction commit, fossil re-extracts
72
-the original content of all files that were written, computes
73
-the SHA1 checksum again, and verifies that the checksums match.
74
-If anything does not match up, an error
75
-message is printed and the transaction rolls back.
76
-</p>
77
-
78
-<p>
79
-So, in other words, fossil always checks to make sure it can
80
-re-extract a file before it commits a change to that file.
81
-Hence bugs in fossil are unlikely to corrupt the repository in
82
-a way that prevents us from extracting historical versions of
83
-files.
84
-</p>
85
-
86
-<h2>Checksum Over All Files In A Baseline</h2>
87
-
88
-<p>
89
-Manifest artifacts that define a baseline have two fields (the
90
-R-card and Z-card) that record MD5 hashs of the manifest itself
91
-and of all other files in the manifest. Prior to any check-in
92
-commit, these checksums are verified to ensure that the baseline
93
-checked in agrees exactly with what is on disk. Similarly,
94
-the repository checksum is verified after a checkout to make
95
-sure that the entire repository was checked out correctly.
96
-Note that these added checks use a different hash (MD5 instead
97
-of SHA1) in order to avoid common-mode failures in the hash
98
-algorithm implementation.
99
-</p>
--- a/www/selfcheck.html
+++ b/www/selfcheck.html
@@ -1,99 +0,0 @@
1 <html>
2 <head>
3 <title>Fossil Repository Integrity Self-Checks</title>
4 </head>
5 <body bgcolor="white">
6 <p>[ <a href="index.html">Index</a> ]</p>
7 <hr>
8 <h1 align="center">
9 Fossil Repository Integrity Self-Checks
10 </h1>
11
12 <p>
13 Even though fossil is a relatively new project and still contains
14 many bugs, it is designed with features to give it a high level
15 of integrity so that you can have confidence that you will not
16 lose your files. This note describes the defensive measures that
17 fossil uses to help prevent file loss due to bugs.
18 </p>
19
20 <p><i>Follow-up as of 2007-11-24:</i>
21 Fossil has been hosting itself and several other projects for
22 months now. Many bugs have been encountered. But, thanks in large
23 part to the defensive measures described here, no data has been
24 lost. The integrity checks are doing their job well.</p>
25
26 <h2>Atomic Check-ins With Rollback</h2>
27
28 <p>
29 The fossil repository is an
30 <a href="http://www.sqlite.org/">SQLite version 3</a> database file.
31 SQLite is very mature and stable and has been in wide-spread use for many
32 years, so we have little worries that it might cause repository
33 corruption. SQLite
34 databases do not corrupt even if a program or system crash or power
35 failure occurs in the middle of the update. If some kind of crash
36 does occur in the middle of a change, then all the changes are rolled
37 back the next time that the database is accessed.
38 </p>
39
40 <p>
41 A check-in operation in fossil makes many changes to the repository
42 database. But all these changes happen within a single transaction.
43 If something goes wrong in the middle of the commit, then the transaction
44 is rolled back and the database is unchanged.
45 </p>
46
47 <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2>
48
49 <p>
50 The content files that comprise the global state of a fossil respository
51 are stored in the repository as a tree. The leaves of the tree are
52 stored as zlib-compressed BLOBs. Interior nodes are deltas from their
53 decendants. A lot of encoding is going on. There is
54 zlib-compression which is relatively well-tested but still might
55 cause corruption if used improperly. And there is the relatively
56 new delta-encoding mechanism designed expressly for fossil. We want
57 to make sure that bugs in these encoding mechanisms do not lead to
58 loss of data.
59 </p>
60
61 <p>
62 To increase our confidence that everything in the repository is
63 recoverable, fossil makes sure it can extract an exact replicate
64 of every content file that it changes just prior to transaction
65 commit. So during the course of check-in (or other repository
66 operation) many different files
67 in the repository might be modified. Some files are simply
68 compressed. Other files are delta encoded and then compressed.
69 While all this is going on, fossil makes a record of every file
70 that is encoded and the SHA1 hash of the original content of that
71 file. Then just before transaction commit, fossil re-extracts
72 the original content of all files that were written, computes
73 the SHA1 checksum again, and verifies that the checksums match.
74 If anything does not match up, an error
75 message is printed and the transaction rolls back.
76 </p>
77
78 <p>
79 So, in other words, fossil always checks to make sure it can
80 re-extract a file before it commits a change to that file.
81 Hence bugs in fossil are unlikely to corrupt the repository in
82 a way that prevents us from extracting historical versions of
83 files.
84 </p>
85
86 <h2>Checksum Over All Files In A Baseline</h2>
87
88 <p>
89 Manifest artifacts that define a baseline have two fields (the
90 R-card and Z-card) that record MD5 hashs of the manifest itself
91 and of all other files in the manifest. Prior to any check-in
92 commit, these checksums are verified to ensure that the baseline
93 checked in agrees exactly with what is on disk. Similarly,
94 the repository checksum is verified after a checkout to make
95 sure that the entire repository was checked out correctly.
96 Note that these added checks use a different hash (MD5 instead
97 of SHA1) in order to avoid common-mode failures in the hash
98 algorithm implementation.
99 </p>
--- a/www/selfcheck.html
+++ b/www/selfcheck.html
@@ -1,99 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/selfcheck.wiki
+34
--- a/www/selfcheck.wiki
+++ b/www/selfcheck.wiki
@@ -0,0 +1,34 @@
1
+<h1 align="center">
2
+ecks</title>
3
+</h1>
4
+
5
+<p>
6
+Even though fossil is a relatively new project and still contains
7
+many bugs, it>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-s>Fign="center">Fossil Reposith1ntegrity Self-Checks</title>
8
+
9
+Fossil is designed with fffff<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
10
+
11
+Fossil is designednd.
12
+that is encoded and the SHA1comseveralencoded and the SHA1computes
13
+the SHA1 checksum againchecksums matchsitory Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
14
+
15
+Fossil is designed with fffff<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
16
+
17
+Fossil is designed with tffffff"fast enough"tControcontrocontrounder a second.
18
+<title> version 3</a> database file. e>Fossil Repository Inte<h1 alighave little worries that it mighth fffff<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
19
+
20
+Fossil is designed with tffffff"fast enough"tControcontrocontrounder a second.
21
+that is encoded and the SHA1computes
22
+the SHA1 checksum againchecksums matchsitory Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
23
+
24
+Fossil is designed with fffff<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
25
+
26
+Fossil is designed with tffffff"fast enough"tControcontrocontrounder a second.
27
+<title>Fossil Reposito <title>Fossil Ryou will not
28
+lose Baselinees. ed with ffffbaselinethfile>Fossil Reposith1nt</i>
29
+<i>Reiterated on 2008-05-16 and again on 2008-10-04:</i>x@61,5:month3Z@71,3:<p>7u@AZ,9:</p>
30
+
31
+<p>42@IS,4:</p>18@MT,3:<p>8_@N_,9:</p>
32
+
33
+<p>ry Inte<h1 align="center">Fossil Reposibaselinessil is designed with fffff<title>Fossil Repository Inte<h1 <title>Fossil Rete<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Ses>Fossil Reposith1ntegrity <p>l is designed with tffffff"fast enough"tControcontrocontrounder a second.
34
+<title>Fossil Reposito <title>Fossil R</p>
--- a/www/selfcheck.wiki
+++ b/www/selfcheck.wiki
@@ -0,0 +1,34 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--- a/www/selfcheck.wiki
+++ b/www/selfcheck.wiki
@@ -0,0 +1,34 @@
1 <h1 align="center">
2 ecks</title>
3 </h1>
4
5 <p>
6 Even though fossil is a relatively new project and still contains
7 many bugs, it>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-s>Fign="center">Fossil Reposith1ntegrity Self-Checks</title>
8
9 Fossil is designed with fffff<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
10
11 Fossil is designednd.
12 that is encoded and the SHA1comseveralencoded and the SHA1computes
13 the SHA1 checksum againchecksums matchsitory Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
14
15 Fossil is designed with fffff<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
16
17 Fossil is designed with tffffff"fast enough"tControcontrocontrounder a second.
18 <title> version 3</a> database file. e>Fossil Repository Inte<h1 alighave little worries that it mighth fffff<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
19
20 Fossil is designed with tffffff"fast enough"tControcontrocontrounder a second.
21 that is encoded and the SHA1computes
22 the SHA1 checksum againchecksums matchsitory Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
23
24 Fossil is designed with fffff<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Self-Checks</title>
25
26 Fossil is designed with tffffff"fast enough"tControcontrocontrounder a second.
27 <title>Fossil Reposito <title>Fossil Ryou will not
28 lose Baselinees. ed with ffffbaselinethfile>Fossil Reposith1nt</i>
29 <i>Reiterated on 2008-05-16 and again on 2008-10-04:</i>x@61,5:month3Z@71,3:<p>7u@AZ,9:</p>
30
31 <p>42@IS,4:</p>18@MT,3:<p>8_@N_,9:</p>
32
33 <p>ry Inte<h1 align="center">Fossil Reposibaselinessil is designed with fffff<title>Fossil Repository Inte<h1 <title>Fossil Rete<title>Fossil Repository Inte<h1 align="center">Fossil Reposith1ntegrity Ses>Fossil Reposith1ntegrity <p>l is designed with tffffff"fast enough"tControcontrocontrounder a second.
34 <title>Fossil Reposito <title>Fossil R</p>
D www/sync.html
-468
--- a/www/sync.html
+++ b/www/sync.html
@@ -1,468 +0,0 @@
1
-<html>
2
-<head>
3
-<title>The Fossil Sync Protocol</title>
4
-</head>
5
-<body bgcolor="white">
6
-<p>[ <a href="index.html">Index</a> ]</p>
7
-<hr>
8
-<h1 align="center">The Fossil Sync Protocol</h1>
9
-
10
-<p>Fossil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
11
-for transferring information from one repository to another. The
12
-command is run on the client repository. A URL for the server repository
13
-is specified as part of the command. This document describes what happens
14
-behind the scenes in order to synchronize the information on the two
15
-repositories.</p>
16
-
17
-<h2>1.0 Transport</h2>
18
-
19
-<p>All communication between client and server is via HTTP requests.
20
-The server is listening for incoming HTTP requests. The client
21
-issues one or more HTTP requests and receives replies for each
22
-request.</p>
23
-
24
-<p>The server might be running as an independent server
25
-using the <b>server</b> command, or it might be launched from
26
-inetd or xinetd using the <b>http</b> command. Or the server might
27
-be launched from CGI. The details of how the server is configured
28
-to "listen" for incoming HTTP requests is immaterial. The important
29
-point is that the server is listening for requests and the client
30
-is the issuer of the requests.</p>
31
-
32
-<p>A single push, pull, or sync might involve multiple HTTP requests.
33
-The client maintains state between all requests. But on the server
34
-side, each request is independent. The server does not preserve
35
-any information about the client from one request to the next.</p>
36
-
37
-<h3>1.1 Server Identification</h3>
38
-
39
-<p>The server is identified by a URL argument that accompanies the
40
-push, pull, or sync command on the client. (As a convenience to
41
-users, the URL can be omitted on the client command and the same URL
42
-from the most recent push, pull, or sync will be reused. This saves
43
-typing in the common case where the client does multiple syncs to
44
-the same server.)</p>
45
-
46
-<p>The client modifies the URL by appending the method name "<b>/xfer</b>"
47
-to the end. For example, if the URL specified on the client command
48
-line is</p>
49
-
50
-<blockquote>
51
-http://fossil-scm.hwaci.com/fossil
52
-</blockquote>
53
-
54
-<p>Then the URL that is really used to do the synchronization will
55
-be:</p>
56
-
57
-<blockquote>
58
-http://fossil-scm.hwaci.com/fossil/xfer
59
-</blockquote>
60
-
61
-<h3>1.2 HTTP Request Format</h3>
62
-
63
-<p>The client always sends a POST request to the server. The
64
-general format of the POST request is as follows:</p>
65
-
66
-<blockquote><pre>
67
-POST /fossil/xfer HTTP/1.0
68
-Host: fossil-scm.hwaci.com:80
69
-Content-Type: application/x-fossil
70
-Content-Length: 4216
71
-
72
-<i>content...</i>
73
-</pre></blockquote>
74
-
75
-<p>In the example above, the pathname given after the POST keyword
76
-on the first line is a copy of the URL pathname. The Host: parameter
77
-is also taken from the URL. The content type is always either
78
-"application/x-fossil" or "application/x-fossil-debug". The "x-fossil"
79
-content type is the default. The only difference is that "x-fossil"
80
-content is compressed using zlib whereas "x-fossil-debug" is sent
81
-uncompressed.</p>
82
-
83
-<p>A typical reply from the server might look something like this:</p>
84
-
85
-<blockquote><pre>
86
-HTTP/1.0 200 OK
87
-Date: Mon, 10 Sep 2007 12:21:01 GMT
88
-Connection: close
89
-Cache-control: private
90
-Content-Type: application/x-fossil; charset=US-ASCII
91
-Content-Length: 265
92
-
93
-<i>content...</i>
94
-</pre></blockquote>
95
-
96
-<p>The content type of the reply is always the same as the content type
97
-of the request.</p>
98
-
99
-<h2>2.0 Fossil Synchronization Content</h2>
100
-
101
-<p>A synchronization request between a client and server consists of
102
-one or more HTTP requests as described in the previous section. This
103
-section details the "x-fossil" content type.</p>
104
-
105
-<h3>2.1 Line-oriented Format</h3>
106
-
107
-<p>The x-fossil content type consists of zero or more "cards". Cards
108
-are separate by the newline character ("\n"). Leading and trailing
109
-whitespace on a card is ignored. Blank cards are ignored.</p>
110
-
111
-<p>Each card is divided into zero or more space separated tokens.
112
-The first token on each card is the operator. Subsequent tokens
113
-are arguments. The set of operators understood by servers is slightly
114
-different from the operators understood by clients, though the two
115
-are very similar.</p>
116
-
117
-<h3>2.2 Login Cards</h3>
118
-
119
-<p>Every message from client to server begins with one or more login
120
-cards. Each login card has the following format:</p>
121
-
122
-<blockquote>
123
-<b>login</b> <i>userid nonce signature</i>
124
-</blockquote>
125
-
126
-<p>The userid is the name of the user that is requesting service
127
-from the server. The nonce is the SHA1 hash of the remainder of
128
-the message - all text that follows the newline character that
129
-terminates the login card. The signature is the SHA1 hash of
130
-the concatenation of the nonce and the users password.</p>
131
-
132
-<p>For each login card, the server looks up the user and verifies
133
-that the nonce matches the SHA1 hash of the remainder of the
134
-message. It then checks the signature hash to make sure the
135
-signature matches. If everything
136
-checks out, then the client is granted all privileges of the
137
-specified user.</p>
138
-
139
-<p>Privileges are cumulative. There can be multiple successful
140
-login cards. The session privileges are the bit-wise OR of the
141
-privileges of each individual login.</p>
142
-
143
-<h3>2.3 File Cards</h3>
144
-
145
-<p>Repository content records or files are transferred using
146
-a "file" card. File cards come in two different formats depending
147
-on whether the file is sent directly or as a delta from some
148
-other file.</p>
149
-
150
-<blockquote>
151
-<b>file</b> <i>uuid size</i> <b>\n</b> <i>content</i><br>
152
-<b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
153
-</blockquote>
154
-
155
-<p>File cards are different from all other cards in that they
156
-followed by in-line "payload" data. The content of the file
157
-or the file delta consists of the first <i>size</i> bytes of the
158
-x-fossil content that immediately follow the newline that
159
-terminates the file card. No other cards have this characteristic.
160
-</p>
161
-
162
-<p>The first argument of a file card is the UUID of the file that
163
-is being transferred. The UUID is the lower-case hexadecimal
164
-representation of the SHA1 hash of the entire file content.
165
-The last argument of the file card is the number of bytes of
166
-payload that immediately follow the file card. If the file
167
-card has only two arguments, that means the payload is the
168
-complete content of the file. If the file card has three
169
-arguments, then the payload is a delta and second argument is
170
-the UUID of another file that is the source of the delta.</p>
171
-
172
-<p>File cards are sent in both directions: client to server and
173
-server to client. A delta might be sent before the source of
174
-the delta, so both client and server should remember deltas
175
-and be able to apply them when their source arrives.</p>
176
-
177
-<h3>2.4 Push and Pull Cards</h3>
178
-
179
-<p>Among of the first cards in a client-to-server message are
180
-the push and pull cards. The push card tell the server that
181
-the client is pushing content. The pull card tell the server
182
-that the client wants to pull content. In the event of a sync,
183
-both cards are sent. The format is as follows:</p>
184
-
185
-<blockquote>
186
-<b>push</b> <i>servercode projectcode</i><br>
187
-<b>pull</b> <i>servercode projectcode</i>
188
-</blockquote>
189
-
190
-<p>The <i>servercode</i> argument is the repository ID for the
191
-client. The server will only allow the transaction to proceed
192
-if the servercode is different from its own servercode. This
193
-prevents a sync-loop. The <i>projectcode</i> is the identifier
194
-of the software project that the client repository contains.
195
-The projectcode for the client and server must match in order
196
-for the transaction to proceed.</p>
197
-
198
-<p>The server will also send a push card back to the client
199
-during a clone. This is how the client determines what project
200
-code to put in the new repository it is constructing.</p>
201
-
202
-<h3>2.5 Clone Cards</h3>
203
-
204
-<p>A clone card works like a pull card in that it is sent from
205
-client to server in order to tell the server that the client
206
-wants to pull content. But unlike the pull card, the clone
207
-card has no arguments.</p>
208
-
209
-<blockquote>
210
-<b>clone</b>
211
-</blockquote>
212
-
213
-<p>In response to a clone message, the server also sends the client
214
-a push message so that the client can discover the projectcode for
215
-this project.</p>
216
-
217
-<h3>2.6 Igot Cards</h3>
218
-
219
-<p>An igot card can be sent from either client to server or from
220
-server to client in order to indicate that the sender holds a copy
221
-of a particular file. The format is:</p>
222
-
223
-<blockquote>
224
-<b>igot</b> <i>uuid</i>
225
-</blockquote>
226
-
227
-<p>The argument of the igot card is the UUID of the file that
228
-the sender possesses.
229
-The receiver of an igot card will typically check to see if
230
-it also holds the same file and if not it will request the file
231
-using a gimme card in either the reply or in the next message.</p>
232
-
233
-<h3>2.7 Gimme Cards</h3>
234
-
235
-<p>A gimme card is sent from either client to server or from server
236
-to client. The gimme card asks the receiver to send a particular
237
-file back to the sender. The format of a gimme card is this:</p>
238
-
239
-<blockquote>
240
-<b>gimme</b> <i>uuid</i>
241
-</blockquote>
242
-
243
-<p>The argument to the gimme card is the UUID of the file that
244
-the sender wants. The receiver will typically respond to a
245
-gimme card by sending a file card in its reply or in the next
246
-message.</p>
247
-
248
-<h3>2.8 Cookie Cards</h3>
249
-
250
-<p>A cookie card can be used by a server to record a small amount
251
-of state information on a client. The server sends a cookie to the
252
-client. The client sends the same cookie back to the server on
253
-its next request. The cookie card has a single argument which
254
-is its payload.</p>
255
-
256
-<blockquote>
257
-<b>cookie</b> <i>payload</i>
258
-</blockquote>
259
-
260
-<p>The client is not required to return the cookie to the server on
261
-its next request. Or the client might send a cookie from a different
262
-server on the next request. So the server must not depend on the
263
-cookie and the server must structure the cookie payload in such
264
-a way that it can tell if the cookie it sees is its own cookie or
265
-a cookie from another server. (Typically the server will embed
266
-its servercode as part of the cookie.)</p>
267
-
268
-<h3>2.9 Error Cards</h3>
269
-
270
-<p>If the server discovers anything wrong with a request, it generates
271
-an error card in its reply. When the client sees the error card,
272
-it displays an error message to the user and aborts the sync
273
-operation. An error card looks like this:</p>
274
-
275
-<blockquote>
276
-<b>error</b> <i>error-message</i>
277
-</blockquote>
278
-
279
-<p>The error message is English text that is encoded in order to
280
-be a single token.
281
-A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
282
-newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
283
-(ASCII 0x5C) is represented as two backslashes "\\". Apart from
284
-space and newline, no other whitespace characters nor any
285
-unprintable characters are allowed in
286
-the error message.</p>
287
-
288
-<h3>2.10 Unknown Cards</h3>
289
-
290
-<p>If either the client or the server sees a card that is not
291
-described above, then it generates an error and aborts.</p>
292
-
293
-<h2>3.0 Phantoms And Clusters</h2>
294
-
295
-<p>When a repository knows that a file exists and knows the UUID of
296
-that file, but it does not know the file content, then it stores that
297
-file as a "phantom". A repository will typically create a phantom when
298
-it receives an igot card for a file that it does not hold or when it
299
-receives a file card that references a delta source that it does not
300
-hold. When a server is generating its reply or when a client is
301
-generating a new request, it will usually send gimme cards for every
302
-phantom that it holds.</p>
303
-
304
-<p>A cluster is a special file that tells of the existence of other
305
-files. Any file in the repository that follows the syntactic rules
306
-of a cluster is considered a cluster.</p>
307
-
308
-<p>A cluster is a line oriented file. Each line of a cluster
309
-is a card. The cards are separated by the newline ("\n") character.
310
-Each card consists of a single character card type, a space, and a
311
-single argument. No extra whitespace and no trailing or leading
312
-whitespace is allowed. All cards in the cluster must occur in
313
-strict lexicographical order.</p>
314
-
315
-<p>A cluster consists of one or more "M" cards followed by a single
316
-"Z" card. Each M card holds an argument which is a UUID for a file
317
-in the repository. The Z card has a single argument which is the
318
-lower-case hexadecimal representation of the MD5 checksum of all
319
-preceding M cards up to and included the newline character that
320
-occurred just before the Z that starts the Z card.</p>
321
-
322
-<p>Any file that does not match the specifications of a cluster
323
-exactly is not a cluster. There must be no extra whitespace in
324
-the file. There must be one or more M cards. There must be a
325
-single Z card with a correct MD5 checksum. And all cards must
326
-be in strict lexicographical order.</p>
327
-
328
-<h3>3.1 The Unclustered Table</h3>
329
-
330
-<p>Every repository maintains a table named "<b>unclustered</b>"
331
-which records the identity of every file and phantom it holds that is not
332
-mentioned in a cluster. The entries in the unclustered table can
333
-be thought of as leaves on a tree of files. Some of the unclustered
334
-files will be clusters. Those clusters may contain other clusters,
335
-which might contain still more clusters, and so forth. Beginning
336
-with the files in the unclustered table, one can follow the chain
337
-of clusters to find every file in the repository.</p>
338
-
339
-<h2>4.0 Synchronization Strategies</h2>
340
-
341
-<h3>4.1 Pull</h3>
342
-
343
-<p>A typical pull operation proceeds as shown below. Details
344
-of the actual implementation may very slightly but the gist of
345
-a pull is captured in the following steps:</p>
346
-
347
-<ol>
348
-<li>The client sends login and pull cards.
349
-<li>The client sends a cookie card if it has previously received a cookie.
350
-<li>The client sends gimme cards for every phantom that it holds.
351
-<hr>
352
-<li>The server checks the login password and rejects the session if
353
-the user does not have permission to pull.
354
-<li>If the number entries in the unclustered table on the server is
355
-greater than 100, then the server constructs a new cluster file to
356
-cover all those unclustered entries.
357
-<li>The server sends file cards for every gimme card it received
358
-from the client.
359
-<li>The server sends ihave cards for every file in its unclustered
360
-table that is not a phantom.
361
-<hr>
362
-<li>The client adds the content of file cards to its repository.
363
-<li>The client creates a phantom for every ihave card in the server reply
364
-that mentions a file that the client does not possess.
365
-<li>The client creates a phantom for the delta source of file cards when
366
-the delta source is a file that the client does not possess.
367
-</ol>
368
-
369
-<p>These ten steps represent a single HTTP round-trip request.
370
-The first three steps are the processing that occurs on the client
371
-to generate the request. The middle four steps are processing
372
-that occurs on the server to interpret the request and generate a
373
-reply. And the last three steps are the processing that the
374
-client does to interpret the reply.</p>
375
-
376
-<p>During a pull, the client will keep sending HTTP requests
377
-until it holds all files that exist on the server.</p>
378
-
379
-<p>Note that the server tries
380
-to limit the size of its reply message to something reasonable
381
-(usually about 1MB) so that it might stop sending file cards as
382
-described in step (6) if the reply becomes too large.</p>
383
-
384
-<p>Step (5) is the only way in which new clusters can be created.
385
-By only creating clusters on the server, we hope to minimize the
386
-amount of overlap between clusters in the common configuration where
387
-there is a single server and many clients. The same synchronization
388
-protocol will continue to work even if there are multiple servers
389
-or if servers and clients sometimes change roles. The only negative
390
-effects of these unusual arrangements is that more than the minimum
391
-number of clusters might be generated.</p>
392
-
393
-<h3>4.2 Push</h3>
394
-
395
-<p>A typical push operation proceeds roughly as shown below. As
396
-with a pull, the actual implementation may vary slightly.</p>
397
-
398
-<ol>
399
-<li>The client sends login and push cards.
400
-<li>The client sends file cards for any files that it holds that have
401
-never before been pushed - files that come from local check-ins.
402
-<li>If this is the second or later cycle in a push, then the
403
-client sends file cards for any gimme cards that the server sent
404
-in the previous cycle.
405
-<li>The client sends igot cards for every file in its unclustered table
406
-that is not a phantom.
407
-<hr>
408
-<li>The server checks the login and push cards and issues an error if
409
-anything is amiss.
410
-<li>The server accepts file cards from the client and adds those files
411
-to its repository.
412
-<li>The server creates phantoms for igot cards that mention files it
413
-does not possess or for file cards that mention delta source files that
414
-it does not possess.
415
-<li>The server issues gimme cards for all phantoms.
416
-<hr>
417
-<li>The client remembers the gimme cards from the server so that it
418
-can generate file cards in reply on the next cycle.
419
-</ol>
420
-
421
-<p>As with a pull, the steps of a push operation repeat until the
422
-server knows all files that exist on the client. Also, as with
423
-pull, the client attempts to keep the size of the request from
424
-growing too large by suppressing file cards once the
425
-size of the request reaches 1MB.</p>
426
-
427
-<h3>4.3 Sync</h3>
428
-
429
-<p>A sync is just a pull and a push that happen at the same time.
430
-The first three steps of a pull are combined with the first five steps
431
-of a push. Steps (4) through (7) of a pull are combined with steps
432
-(5) through (8) of a push. And steps (8) through (10) of a pull
433
-are combined with step (9) of a push.</p>
434
-
435
-<h2>5.0 Summary</h2>
436
-
437
-<p>Here are the key points of the synchronization protocol:</p>
438
-
439
-<ol>
440
-<li>The client sends one or more PUSH HTTP requests to the server.
441
- The request and reply content type is "application/x-fossil".
442
-<li>HTTP request content is compressed using zlib.
443
-<li>The content of request and reply consists of cards with one
444
- card per line.
445
-<li>Card formats are:
446
- <ul>
447
- <li> <b>login</b> <i>userid nonce signature</i>
448
- <li> <b>push</b> <i>servercode projectcode</i>
449
- <li> <b>pull</b> <i>servercode projectcode</i>
450
- <li> <b>clone</b>
451
- <li> <b>file</b> <i>uuid size</i> <b>\n</b> <i>content</i>
452
- <li> <b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
453
- <li> <b>igot</b> <i>uuid</i>
454
- <li> <b>gimme</b> <i>uuid</i>
455
- <li> <b>cookie</b> <i>cookie-text</i>
456
- <li> <b>error</b> <i>error-message</i>
457
- </ul>
458
-<li>Phantoms are files that a repository knows exist but does not possess.
459
-<li>Clusters are files that contain the UUIDs of other files.
460
-<li>Clusters are created automatically on the server during a pull.
461
-<li>Repositories keep track of all files that are not named in any
462
-cluster and send igot messages for those files.
463
-<li>Repositories keep track of all the phantoms they hold and send
464
-gimme messages for those files.
465
-</ol>
466
-
467
-</body>
468
-</html>
--- a/www/sync.html
+++ b/www/sync.html
@@ -1,468 +0,0 @@
1 <html>
2 <head>
3 <title>The Fossil Sync Protocol</title>
4 </head>
5 <body bgcolor="white">
6 <p>[ <a href="index.html">Index</a> ]</p>
7 <hr>
8 <h1 align="center">The Fossil Sync Protocol</h1>
9
10 <p>Fossil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
11 for transferring information from one repository to another. The
12 command is run on the client repository. A URL for the server repository
13 is specified as part of the command. This document describes what happens
14 behind the scenes in order to synchronize the information on the two
15 repositories.</p>
16
17 <h2>1.0 Transport</h2>
18
19 <p>All communication between client and server is via HTTP requests.
20 The server is listening for incoming HTTP requests. The client
21 issues one or more HTTP requests and receives replies for each
22 request.</p>
23
24 <p>The server might be running as an independent server
25 using the <b>server</b> command, or it might be launched from
26 inetd or xinetd using the <b>http</b> command. Or the server might
27 be launched from CGI. The details of how the server is configured
28 to "listen" for incoming HTTP requests is immaterial. The important
29 point is that the server is listening for requests and the client
30 is the issuer of the requests.</p>
31
32 <p>A single push, pull, or sync might involve multiple HTTP requests.
33 The client maintains state between all requests. But on the server
34 side, each request is independent. The server does not preserve
35 any information about the client from one request to the next.</p>
36
37 <h3>1.1 Server Identification</h3>
38
39 <p>The server is identified by a URL argument that accompanies the
40 push, pull, or sync command on the client. (As a convenience to
41 users, the URL can be omitted on the client command and the same URL
42 from the most recent push, pull, or sync will be reused. This saves
43 typing in the common case where the client does multiple syncs to
44 the same server.)</p>
45
46 <p>The client modifies the URL by appending the method name "<b>/xfer</b>"
47 to the end. For example, if the URL specified on the client command
48 line is</p>
49
50 <blockquote>
51 http://fossil-scm.hwaci.com/fossil
52 </blockquote>
53
54 <p>Then the URL that is really used to do the synchronization will
55 be:</p>
56
57 <blockquote>
58 http://fossil-scm.hwaci.com/fossil/xfer
59 </blockquote>
60
61 <h3>1.2 HTTP Request Format</h3>
62
63 <p>The client always sends a POST request to the server. The
64 general format of the POST request is as follows:</p>
65
66 <blockquote><pre>
67 POST /fossil/xfer HTTP/1.0
68 Host: fossil-scm.hwaci.com:80
69 Content-Type: application/x-fossil
70 Content-Length: 4216
71
72 <i>content...</i>
73 </pre></blockquote>
74
75 <p>In the example above, the pathname given after the POST keyword
76 on the first line is a copy of the URL pathname. The Host: parameter
77 is also taken from the URL. The content type is always either
78 "application/x-fossil" or "application/x-fossil-debug". The "x-fossil"
79 content type is the default. The only difference is that "x-fossil"
80 content is compressed using zlib whereas "x-fossil-debug" is sent
81 uncompressed.</p>
82
83 <p>A typical reply from the server might look something like this:</p>
84
85 <blockquote><pre>
86 HTTP/1.0 200 OK
87 Date: Mon, 10 Sep 2007 12:21:01 GMT
88 Connection: close
89 Cache-control: private
90 Content-Type: application/x-fossil; charset=US-ASCII
91 Content-Length: 265
92
93 <i>content...</i>
94 </pre></blockquote>
95
96 <p>The content type of the reply is always the same as the content type
97 of the request.</p>
98
99 <h2>2.0 Fossil Synchronization Content</h2>
100
101 <p>A synchronization request between a client and server consists of
102 one or more HTTP requests as described in the previous section. This
103 section details the "x-fossil" content type.</p>
104
105 <h3>2.1 Line-oriented Format</h3>
106
107 <p>The x-fossil content type consists of zero or more "cards". Cards
108 are separate by the newline character ("\n"). Leading and trailing
109 whitespace on a card is ignored. Blank cards are ignored.</p>
110
111 <p>Each card is divided into zero or more space separated tokens.
112 The first token on each card is the operator. Subsequent tokens
113 are arguments. The set of operators understood by servers is slightly
114 different from the operators understood by clients, though the two
115 are very similar.</p>
116
117 <h3>2.2 Login Cards</h3>
118
119 <p>Every message from client to server begins with one or more login
120 cards. Each login card has the following format:</p>
121
122 <blockquote>
123 <b>login</b> <i>userid nonce signature</i>
124 </blockquote>
125
126 <p>The userid is the name of the user that is requesting service
127 from the server. The nonce is the SHA1 hash of the remainder of
128 the message - all text that follows the newline character that
129 terminates the login card. The signature is the SHA1 hash of
130 the concatenation of the nonce and the users password.</p>
131
132 <p>For each login card, the server looks up the user and verifies
133 that the nonce matches the SHA1 hash of the remainder of the
134 message. It then checks the signature hash to make sure the
135 signature matches. If everything
136 checks out, then the client is granted all privileges of the
137 specified user.</p>
138
139 <p>Privileges are cumulative. There can be multiple successful
140 login cards. The session privileges are the bit-wise OR of the
141 privileges of each individual login.</p>
142
143 <h3>2.3 File Cards</h3>
144
145 <p>Repository content records or files are transferred using
146 a "file" card. File cards come in two different formats depending
147 on whether the file is sent directly or as a delta from some
148 other file.</p>
149
150 <blockquote>
151 <b>file</b> <i>uuid size</i> <b>\n</b> <i>content</i><br>
152 <b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
153 </blockquote>
154
155 <p>File cards are different from all other cards in that they
156 followed by in-line "payload" data. The content of the file
157 or the file delta consists of the first <i>size</i> bytes of the
158 x-fossil content that immediately follow the newline that
159 terminates the file card. No other cards have this characteristic.
160 </p>
161
162 <p>The first argument of a file card is the UUID of the file that
163 is being transferred. The UUID is the lower-case hexadecimal
164 representation of the SHA1 hash of the entire file content.
165 The last argument of the file card is the number of bytes of
166 payload that immediately follow the file card. If the file
167 card has only two arguments, that means the payload is the
168 complete content of the file. If the file card has three
169 arguments, then the payload is a delta and second argument is
170 the UUID of another file that is the source of the delta.</p>
171
172 <p>File cards are sent in both directions: client to server and
173 server to client. A delta might be sent before the source of
174 the delta, so both client and server should remember deltas
175 and be able to apply them when their source arrives.</p>
176
177 <h3>2.4 Push and Pull Cards</h3>
178
179 <p>Among of the first cards in a client-to-server message are
180 the push and pull cards. The push card tell the server that
181 the client is pushing content. The pull card tell the server
182 that the client wants to pull content. In the event of a sync,
183 both cards are sent. The format is as follows:</p>
184
185 <blockquote>
186 <b>push</b> <i>servercode projectcode</i><br>
187 <b>pull</b> <i>servercode projectcode</i>
188 </blockquote>
189
190 <p>The <i>servercode</i> argument is the repository ID for the
191 client. The server will only allow the transaction to proceed
192 if the servercode is different from its own servercode. This
193 prevents a sync-loop. The <i>projectcode</i> is the identifier
194 of the software project that the client repository contains.
195 The projectcode for the client and server must match in order
196 for the transaction to proceed.</p>
197
198 <p>The server will also send a push card back to the client
199 during a clone. This is how the client determines what project
200 code to put in the new repository it is constructing.</p>
201
202 <h3>2.5 Clone Cards</h3>
203
204 <p>A clone card works like a pull card in that it is sent from
205 client to server in order to tell the server that the client
206 wants to pull content. But unlike the pull card, the clone
207 card has no arguments.</p>
208
209 <blockquote>
210 <b>clone</b>
211 </blockquote>
212
213 <p>In response to a clone message, the server also sends the client
214 a push message so that the client can discover the projectcode for
215 this project.</p>
216
217 <h3>2.6 Igot Cards</h3>
218
219 <p>An igot card can be sent from either client to server or from
220 server to client in order to indicate that the sender holds a copy
221 of a particular file. The format is:</p>
222
223 <blockquote>
224 <b>igot</b> <i>uuid</i>
225 </blockquote>
226
227 <p>The argument of the igot card is the UUID of the file that
228 the sender possesses.
229 The receiver of an igot card will typically check to see if
230 it also holds the same file and if not it will request the file
231 using a gimme card in either the reply or in the next message.</p>
232
233 <h3>2.7 Gimme Cards</h3>
234
235 <p>A gimme card is sent from either client to server or from server
236 to client. The gimme card asks the receiver to send a particular
237 file back to the sender. The format of a gimme card is this:</p>
238
239 <blockquote>
240 <b>gimme</b> <i>uuid</i>
241 </blockquote>
242
243 <p>The argument to the gimme card is the UUID of the file that
244 the sender wants. The receiver will typically respond to a
245 gimme card by sending a file card in its reply or in the next
246 message.</p>
247
248 <h3>2.8 Cookie Cards</h3>
249
250 <p>A cookie card can be used by a server to record a small amount
251 of state information on a client. The server sends a cookie to the
252 client. The client sends the same cookie back to the server on
253 its next request. The cookie card has a single argument which
254 is its payload.</p>
255
256 <blockquote>
257 <b>cookie</b> <i>payload</i>
258 </blockquote>
259
260 <p>The client is not required to return the cookie to the server on
261 its next request. Or the client might send a cookie from a different
262 server on the next request. So the server must not depend on the
263 cookie and the server must structure the cookie payload in such
264 a way that it can tell if the cookie it sees is its own cookie or
265 a cookie from another server. (Typically the server will embed
266 its servercode as part of the cookie.)</p>
267
268 <h3>2.9 Error Cards</h3>
269
270 <p>If the server discovers anything wrong with a request, it generates
271 an error card in its reply. When the client sees the error card,
272 it displays an error message to the user and aborts the sync
273 operation. An error card looks like this:</p>
274
275 <blockquote>
276 <b>error</b> <i>error-message</i>
277 </blockquote>
278
279 <p>The error message is English text that is encoded in order to
280 be a single token.
281 A space (ASCII 0x20) is represented as "\s" (ASCII 0x5C, 0x73). A
282 newline (ASCII 0x0a) is "\n" (ASCII 0x6C, x6E). A backslash
283 (ASCII 0x5C) is represented as two backslashes "\\". Apart from
284 space and newline, no other whitespace characters nor any
285 unprintable characters are allowed in
286 the error message.</p>
287
288 <h3>2.10 Unknown Cards</h3>
289
290 <p>If either the client or the server sees a card that is not
291 described above, then it generates an error and aborts.</p>
292
293 <h2>3.0 Phantoms And Clusters</h2>
294
295 <p>When a repository knows that a file exists and knows the UUID of
296 that file, but it does not know the file content, then it stores that
297 file as a "phantom". A repository will typically create a phantom when
298 it receives an igot card for a file that it does not hold or when it
299 receives a file card that references a delta source that it does not
300 hold. When a server is generating its reply or when a client is
301 generating a new request, it will usually send gimme cards for every
302 phantom that it holds.</p>
303
304 <p>A cluster is a special file that tells of the existence of other
305 files. Any file in the repository that follows the syntactic rules
306 of a cluster is considered a cluster.</p>
307
308 <p>A cluster is a line oriented file. Each line of a cluster
309 is a card. The cards are separated by the newline ("\n") character.
310 Each card consists of a single character card type, a space, and a
311 single argument. No extra whitespace and no trailing or leading
312 whitespace is allowed. All cards in the cluster must occur in
313 strict lexicographical order.</p>
314
315 <p>A cluster consists of one or more "M" cards followed by a single
316 "Z" card. Each M card holds an argument which is a UUID for a file
317 in the repository. The Z card has a single argument which is the
318 lower-case hexadecimal representation of the MD5 checksum of all
319 preceding M cards up to and included the newline character that
320 occurred just before the Z that starts the Z card.</p>
321
322 <p>Any file that does not match the specifications of a cluster
323 exactly is not a cluster. There must be no extra whitespace in
324 the file. There must be one or more M cards. There must be a
325 single Z card with a correct MD5 checksum. And all cards must
326 be in strict lexicographical order.</p>
327
328 <h3>3.1 The Unclustered Table</h3>
329
330 <p>Every repository maintains a table named "<b>unclustered</b>"
331 which records the identity of every file and phantom it holds that is not
332 mentioned in a cluster. The entries in the unclustered table can
333 be thought of as leaves on a tree of files. Some of the unclustered
334 files will be clusters. Those clusters may contain other clusters,
335 which might contain still more clusters, and so forth. Beginning
336 with the files in the unclustered table, one can follow the chain
337 of clusters to find every file in the repository.</p>
338
339 <h2>4.0 Synchronization Strategies</h2>
340
341 <h3>4.1 Pull</h3>
342
343 <p>A typical pull operation proceeds as shown below. Details
344 of the actual implementation may very slightly but the gist of
345 a pull is captured in the following steps:</p>
346
347 <ol>
348 <li>The client sends login and pull cards.
349 <li>The client sends a cookie card if it has previously received a cookie.
350 <li>The client sends gimme cards for every phantom that it holds.
351 <hr>
352 <li>The server checks the login password and rejects the session if
353 the user does not have permission to pull.
354 <li>If the number entries in the unclustered table on the server is
355 greater than 100, then the server constructs a new cluster file to
356 cover all those unclustered entries.
357 <li>The server sends file cards for every gimme card it received
358 from the client.
359 <li>The server sends ihave cards for every file in its unclustered
360 table that is not a phantom.
361 <hr>
362 <li>The client adds the content of file cards to its repository.
363 <li>The client creates a phantom for every ihave card in the server reply
364 that mentions a file that the client does not possess.
365 <li>The client creates a phantom for the delta source of file cards when
366 the delta source is a file that the client does not possess.
367 </ol>
368
369 <p>These ten steps represent a single HTTP round-trip request.
370 The first three steps are the processing that occurs on the client
371 to generate the request. The middle four steps are processing
372 that occurs on the server to interpret the request and generate a
373 reply. And the last three steps are the processing that the
374 client does to interpret the reply.</p>
375
376 <p>During a pull, the client will keep sending HTTP requests
377 until it holds all files that exist on the server.</p>
378
379 <p>Note that the server tries
380 to limit the size of its reply message to something reasonable
381 (usually about 1MB) so that it might stop sending file cards as
382 described in step (6) if the reply becomes too large.</p>
383
384 <p>Step (5) is the only way in which new clusters can be created.
385 By only creating clusters on the server, we hope to minimize the
386 amount of overlap between clusters in the common configuration where
387 there is a single server and many clients. The same synchronization
388 protocol will continue to work even if there are multiple servers
389 or if servers and clients sometimes change roles. The only negative
390 effects of these unusual arrangements is that more than the minimum
391 number of clusters might be generated.</p>
392
393 <h3>4.2 Push</h3>
394
395 <p>A typical push operation proceeds roughly as shown below. As
396 with a pull, the actual implementation may vary slightly.</p>
397
398 <ol>
399 <li>The client sends login and push cards.
400 <li>The client sends file cards for any files that it holds that have
401 never before been pushed - files that come from local check-ins.
402 <li>If this is the second or later cycle in a push, then the
403 client sends file cards for any gimme cards that the server sent
404 in the previous cycle.
405 <li>The client sends igot cards for every file in its unclustered table
406 that is not a phantom.
407 <hr>
408 <li>The server checks the login and push cards and issues an error if
409 anything is amiss.
410 <li>The server accepts file cards from the client and adds those files
411 to its repository.
412 <li>The server creates phantoms for igot cards that mention files it
413 does not possess or for file cards that mention delta source files that
414 it does not possess.
415 <li>The server issues gimme cards for all phantoms.
416 <hr>
417 <li>The client remembers the gimme cards from the server so that it
418 can generate file cards in reply on the next cycle.
419 </ol>
420
421 <p>As with a pull, the steps of a push operation repeat until the
422 server knows all files that exist on the client. Also, as with
423 pull, the client attempts to keep the size of the request from
424 growing too large by suppressing file cards once the
425 size of the request reaches 1MB.</p>
426
427 <h3>4.3 Sync</h3>
428
429 <p>A sync is just a pull and a push that happen at the same time.
430 The first three steps of a pull are combined with the first five steps
431 of a push. Steps (4) through (7) of a pull are combined with steps
432 (5) through (8) of a push. And steps (8) through (10) of a pull
433 are combined with step (9) of a push.</p>
434
435 <h2>5.0 Summary</h2>
436
437 <p>Here are the key points of the synchronization protocol:</p>
438
439 <ol>
440 <li>The client sends one or more PUSH HTTP requests to the server.
441 The request and reply content type is "application/x-fossil".
442 <li>HTTP request content is compressed using zlib.
443 <li>The content of request and reply consists of cards with one
444 card per line.
445 <li>Card formats are:
446 <ul>
447 <li> <b>login</b> <i>userid nonce signature</i>
448 <li> <b>push</b> <i>servercode projectcode</i>
449 <li> <b>pull</b> <i>servercode projectcode</i>
450 <li> <b>clone</b>
451 <li> <b>file</b> <i>uuid size</i> <b>\n</b> <i>content</i>
452 <li> <b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
453 <li> <b>igot</b> <i>uuid</i>
454 <li> <b>gimme</b> <i>uuid</i>
455 <li> <b>cookie</b> <i>cookie-text</i>
456 <li> <b>error</b> <i>error-message</i>
457 </ul>
458 <li>Phantoms are files that a repository knows exist but does not possess.
459 <li>Clusters are files that contain the UUIDs of other files.
460 <li>Clusters are created automatically on the server during a pull.
461 <li>Repositories keep track of all files that are not named in any
462 cluster and send igot messages for those files.
463 <li>Repositories keep track of all the phantoms they hold and send
464 gimme messages for those files.
465 </ol>
466
467 </body>
468 </html>
--- a/www/sync.html
+++ b/www/sync.html
@@ -1,468 +0,0 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
M www/sync.wiki
+39
--- a/www/sync.wiki
+++ b/www/sync.wiki
@@ -0,0 +1,39 @@
1
+<h1 align="center"Replicateignoreclean Replich1cateignoreclean Replicatesil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
2
+for transferring></a>
3
+<h3be large.identified by a cryptograp The
4
+command is run on the clie that the unde<clean Replicated Fossil supports coports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
5
+for transferring></a>
6
+<h3be large.identified by a cryptograp The
7
+com>file</b> <i>uuuuid delta-uufile
8
+or the fileUUID of the fileUUentire file contents commands <b>push</b>, <b>pull</b>, and <b>sync</b>
9
+for transferring></a>
10
+<h3be large.identified by a cryptograp The
11
+command is run on the clie that the unde<clean Replicated Fossil supports coports comma<h1 UUID of another filefileuuiigot card is the UUID of the filefilefilefileuuiUUID of the filefileUUID of
12
+that filefilefilefil1 align="center"Re<h1 align="center"Replicateignoreclean Replich1cateignoreclean Replicatesil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
13
+for transferring></a>
14
+<h3be large.identified by a cryptograp The
15
+command is run on the clie that the unde<clean Replicated Fossil supportfilefiles. Any filea line oriented fileUUID for a file
16
+filefilefilefilefiles will befilfilefilefile file filefilefilefilefilefilefilefilefileuuuuid delta-uuuuidgimme</b> <i>uuidfiles thatfiles that confilefilesfiles.
17
+<1<h1 align="center"Replicateignoreclean Replich1cateignoreclean Replicatesil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
18
+for transferring></a>
19
+<h3be large.identified by a cryptograp The
20
+command is run on the clie that the unde<clean Replicated Fossil supports coports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
21
+for transferring></a>
22
+<h3be large.identified by a cryptograp The
23
+command is run on the client reincebecauserun on the clie that the unde<clean Replicated Fossil supports coports command<h1 align="center"Replicateignoreclean Replich1cateignoreclean nd <b>sync</b>
24
+for transferring></a>
25
+<h3be large.identified by a cryptograp The
26
+command is run on the clie that the unde<clean Replicated Fossil s nsferred using
27
+a "file" card. filefile.
28
+<b>file</b> <i>uuuuid delta-uufile
29
+or the fileUUID of the fileUUentire file contents commands <b>push</b>, <b>pull</b>, and <b>sync</b>
30
+for transferring></a>
31
+<h3be large.identified by a cryptograp The
32
+command is run on the clie that the unde<clean Replicated Fossil supports coports comma<h1 UUID of another filefileuuiigot card is the UUID of the filefilefilefileuuiUUID of the filefileUUID of
33
+that filefilefilefil1 align="center"Re<h1 align="center"Replicateignoreclean Replich1cateignoreclean Replicatesil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
34
+for transferring></a>
35
+<h3be large.identified by a cryptograp The
36
+command is run on the clie that the unde<clean Replicated Fossil supportfilefiles. Any filea line oriented fileUUID for a file
37
+filefilefilefilefiles will befilfilefilefile file filefilefilefilefilefilefilefilefileuuuuid delta-uuuuidgimme</b> <i>uuidfiles thatfiles that confilefilesfiles.
38
+</ol>
39
+222222222223344445
--- a/www/sync.wiki
+++ b/www/sync.wiki
@@ -0,0 +1,39 @@
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--- a/www/sync.wiki
+++ b/www/sync.wiki
@@ -0,0 +1,39 @@
1 <h1 align="center"Replicateignoreclean Replich1cateignoreclean Replicatesil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
2 for transferring></a>
3 <h3be large.identified by a cryptograp The
4 command is run on the clie that the unde<clean Replicated Fossil supports coports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
5 for transferring></a>
6 <h3be large.identified by a cryptograp The
7 com>file</b> <i>uuuuid delta-uufile
8 or the fileUUID of the fileUUentire file contents commands <b>push</b>, <b>pull</b>, and <b>sync</b>
9 for transferring></a>
10 <h3be large.identified by a cryptograp The
11 command is run on the clie that the unde<clean Replicated Fossil supports coports comma<h1 UUID of another filefileuuiigot card is the UUID of the filefilefilefileuuiUUID of the filefileUUID of
12 that filefilefilefil1 align="center"Re<h1 align="center"Replicateignoreclean Replich1cateignoreclean Replicatesil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
13 for transferring></a>
14 <h3be large.identified by a cryptograp The
15 command is run on the clie that the unde<clean Replicated Fossil supportfilefiles. Any filea line oriented fileUUID for a file
16 filefilefilefilefiles will befilfilefilefile file filefilefilefilefilefilefilefilefileuuuuid delta-uuuuidgimme</b> <i>uuidfiles thatfiles that confilefilesfiles.
17 <1<h1 align="center"Replicateignoreclean Replich1cateignoreclean Replicatesil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
18 for transferring></a>
19 <h3be large.identified by a cryptograp The
20 command is run on the clie that the unde<clean Replicated Fossil supports coports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
21 for transferring></a>
22 <h3be large.identified by a cryptograp The
23 command is run on the client reincebecauserun on the clie that the unde<clean Replicated Fossil supports coports command<h1 align="center"Replicateignoreclean Replich1cateignoreclean nd <b>sync</b>
24 for transferring></a>
25 <h3be large.identified by a cryptograp The
26 command is run on the clie that the unde<clean Replicated Fossil s nsferred using
27 a "file" card. filefile.
28 <b>file</b> <i>uuuuid delta-uufile
29 or the fileUUID of the fileUUentire file contents commands <b>push</b>, <b>pull</b>, and <b>sync</b>
30 for transferring></a>
31 <h3be large.identified by a cryptograp The
32 command is run on the clie that the unde<clean Replicated Fossil supports coports comma<h1 UUID of another filefileuuiigot card is the UUID of the filefilefilefileuuiUUID of the filefileUUID of
33 that filefilefilefil1 align="center"Re<h1 align="center"Replicateignoreclean Replich1cateignoreclean Replicatesil supports commands <b>push</b>, <b>pull</b>, and <b>sync</b>
34 for transferring></a>
35 <h3be large.identified by a cryptograp The
36 command is run on the clie that the unde<clean Replicated Fossil supportfilefiles. Any filea line oriented fileUUID for a file
37 filefilefilefilefiles will befilfilefilefile file filefilefilefilefilefilefilefilefileuuuuid delta-uuuuidgimme</b> <i>uuidfiles thatfiles that confilefilesfiles.
38 </ol>
39 222222222223344445

Keyboard Shortcuts

Open search /
Next entry (timeline) j
Previous entry (timeline) k
Open focused entry Enter
Show this help ?
Toggle theme Top nav button