Fossil SCM

Change all mentions of UUID in the documentation and help screens into either "artifact ID" or "baseline ID" or "ticket ID" as appropriate. UUID has a widely recognized meaning that is different from its meaning in fossil.

drh 2008-10-24 13:27 trunk

Commit e8c4f69c50ecbe4388aa28e489050e7ca6be2ed8

Parent 8bdea95c5863833…

12 files changed +3 -3 +10 -10 +3 -3 +28 -25 +3 -3 +6 -6 +6 -6 +15 -15 +2 -2 +7 -7 +6 -5 +60 -58

~ src/descendants.c ~ src/info.c ~ src/name.c ~ src/tag.c ~ src/timeline.c ~ src/wiki.c ~ www/bugtheory.wiki ~ www/concepts.wiki ~ www/embeddeddoc.wiki ~ www/fileformat.wiki ~ www/quickstart.wiki ~ www/sync.wiki

M src/descendants.c

+3 -3

		--- src/descendants.c
		+++ src/descendants.c
		@@ -130,14 +130,14 @@
130	130	}
131	131
132	132	/*
133	133	** COMMAND: descendants
134	134	**
135		-** Usage: %fossil descendants ?UUID?
	135	+** Usage: %fossil descendants ?BASELINE-ID?
136	136	**
137		-** Find all leaf descendants of the current version or of the
138		-** specified version.
	137	+** Find all leaf descendants of the baseline specified or if the argument
	138	+** is omitted, of the baseline currently checked out.
139	139	*/
140	140	void descendants_cmd(void){
141	141	Stmt q;
142	142	int base;
143	143
144	144

	--- src/descendants.c
	+++ src/descendants.c
	@@ -130,14 +130,14 @@
130	}
131
132	/*
133	** COMMAND: descendants
134	**
135	** Usage: %fossil descendants ?UUID?
136	**
137	** Find all leaf descendants of the current version or of the
138	** specified version.
139	*/
140	void descendants_cmd(void){
141	Stmt q;
142	int base;
143
144

	--- src/descendants.c
	+++ src/descendants.c
	@@ -130,14 +130,14 @@
130	}
131
132	/*
133	** COMMAND: descendants
134	**
135	** Usage: %fossil descendants ?BASELINE-ID?
136	**
137	** Find all leaf descendants of the baseline specified or if the argument
138	** is omitted, of the baseline currently checked out.
139	*/
140	void descendants_cmd(void){
141	Stmt q;
142	int base;
143
144

M src/info.c

+10 -10

		--- src/info.c
		+++ src/info.c
		@@ -72,22 +72,22 @@
72	72
73	73
74	74	/*
75	75	** COMMAND: info
76	76	**
77		-** Usage: %fossil info ?UUID\|FILENAME?
	77	+** Usage: %fossil info ?ARTIFACT-ID\|FILENAME?
78	78	**
79	79	** With no arguments, provide information about the current tree.
80		-** If an argument is given, provide information about the record
	80	+** If an argument is specified, provide information about the object
81	81	** in the respository of the current tree that the argument refers
82	82	** to. Or if the argument is the name of a repository, show
83	83	** information about that repository.
84	84	*/
85	85	void info_cmd(void){
86	86	i64 fsize;
87	87	if( g.argc!=2 && g.argc!=3 ){
88		- usage("?FILENAME\|UUID?");
	88	+ usage("?FILENAME\|ARTIFACT-ID?");
89	89	}
90	90	if( g.argc==3 && (fsize = file_size(g.argv[2]))>0 && (fsize&0x1ff)==0 ){
91	91	db_open_config();
92	92	db_record_repository_filename(g.argv[2]);
93	93	db_open_repository(g.argv[2]);
		@@ -303,11 +303,11 @@
303	303	}
304	304
305	305
306	306	/*
307	307	** WEBPAGE: vinfo
308		-** URL: /vinfo?name=RID\|UUID
	308	+** URL: /vinfo?name=RID\|ARTIFACTID
309	309	**
310	310	** Return information about a baseline
311	311	*/
312	312	void vinfo_page(void){
313	313	Stmt q;
		@@ -795,13 +795,13 @@
795	795	style_footer();
796	796	}
797	797
798	798	/*
799	799	** WEBPAGE: artifact
800		-** URL: /artifact?name=UUID
	800	+** URL: /artifact?name=ARTIFACTID
801	801	**
802		-** Show the complete content of a file identified by UUID
	802	+** Show the complete content of a file identified by ARTIFACTID
803	803	** as preformatted text.
804	804	*/
805	805	void artifact_page(void){
806	806	int rid;
807	807	Blob content;
		@@ -834,11 +834,11 @@
834	834	style_footer();
835	835	}
836	836
837	837	/*
838	838	** WEBPAGE: tinfo
839		-** URL: /tinfo?name=UUID
	839	+** URL: /tinfo?name=ARTIFACTID
840	840	**
841	841	** Show the details of a ticket change control artifact.
842	842	*/
843	843	void tinfo_page(void){
844	844	int rid;
		@@ -888,16 +888,16 @@
888	888	}
889	889
890	890
891	891	/*
892	892	** WEBPAGE: info
893		-** URL: info/UUID
	893	+** URL: info/ARTIFACTID
894	894	**
895		-** The argument is a UUID which might be a baseline or a file or
	895	+** The argument is a artifact ID which might be a baseline or a file or
896	896	** a ticket changes or a wiki editor or something else.
897	897	**
898		-** Figure out what the UUID is and jump to it.
	898	+** Figure out what the artifact ID is and jump to it.
899	899	*/
900	900	void info_page(void){
901	901	const char *zName;
902	902	Blob uuid;
903	903	int rid, nName;
904	904

	--- src/info.c
	+++ src/info.c
	@@ -72,22 +72,22 @@
72
73
74	/*
75	** COMMAND: info
76	**
77	** Usage: %fossil info ?UUID\|FILENAME?
78	**
79	** With no arguments, provide information about the current tree.
80	** If an argument is given, provide information about the record
81	** in the respository of the current tree that the argument refers
82	** to. Or if the argument is the name of a repository, show
83	** information about that repository.
84	*/
85	void info_cmd(void){
86	i64 fsize;
87	if( g.argc!=2 && g.argc!=3 ){
88	usage("?FILENAME\|UUID?");
89	}
90	if( g.argc==3 && (fsize = file_size(g.argv[2]))>0 && (fsize&0x1ff)==0 ){
91	db_open_config();
92	db_record_repository_filename(g.argv[2]);
93	db_open_repository(g.argv[2]);
	@@ -303,11 +303,11 @@
303	}
304
305
306	/*
307	** WEBPAGE: vinfo
308	** URL: /vinfo?name=RID\|UUID
309	**
310	** Return information about a baseline
311	*/
312	void vinfo_page(void){
313	Stmt q;
	@@ -795,13 +795,13 @@
795	style_footer();
796	}
797
798	/*
799	** WEBPAGE: artifact
800	** URL: /artifact?name=UUID
801	**
802	** Show the complete content of a file identified by UUID
803	** as preformatted text.
804	*/
805	void artifact_page(void){
806	int rid;
807	Blob content;
	@@ -834,11 +834,11 @@
834	style_footer();
835	}
836
837	/*
838	** WEBPAGE: tinfo
839	** URL: /tinfo?name=UUID
840	**
841	** Show the details of a ticket change control artifact.
842	*/
843	void tinfo_page(void){
844	int rid;
	@@ -888,16 +888,16 @@
888	}
889
890
891	/*
892	** WEBPAGE: info
893	** URL: info/UUID
894	**
895	** The argument is a UUID which might be a baseline or a file or
896	** a ticket changes or a wiki editor or something else.
897	**
898	** Figure out what the UUID is and jump to it.
899	*/
900	void info_page(void){
901	const char *zName;
902	Blob uuid;
903	int rid, nName;
904

	--- src/info.c
	+++ src/info.c
	@@ -72,22 +72,22 @@
72
73
74	/*
75	** COMMAND: info
76	**
77	** Usage: %fossil info ?ARTIFACT-ID\|FILENAME?
78	**
79	** With no arguments, provide information about the current tree.
80	** If an argument is specified, provide information about the object
81	** in the respository of the current tree that the argument refers
82	** to. Or if the argument is the name of a repository, show
83	** information about that repository.
84	*/
85	void info_cmd(void){
86	i64 fsize;
87	if( g.argc!=2 && g.argc!=3 ){
88	usage("?FILENAME\|ARTIFACT-ID?");
89	}
90	if( g.argc==3 && (fsize = file_size(g.argv[2]))>0 && (fsize&0x1ff)==0 ){
91	db_open_config();
92	db_record_repository_filename(g.argv[2]);
93	db_open_repository(g.argv[2]);
	@@ -303,11 +303,11 @@
303	}
304
305
306	/*
307	** WEBPAGE: vinfo
308	** URL: /vinfo?name=RID\|ARTIFACTID
309	**
310	** Return information about a baseline
311	*/
312	void vinfo_page(void){
313	Stmt q;
	@@ -795,13 +795,13 @@
795	style_footer();
796	}
797
798	/*
799	** WEBPAGE: artifact
800	** URL: /artifact?name=ARTIFACTID
801	**
802	** Show the complete content of a file identified by ARTIFACTID
803	** as preformatted text.
804	*/
805	void artifact_page(void){
806	int rid;
807	Blob content;
	@@ -834,11 +834,11 @@
834	style_footer();
835	}
836
837	/*
838	** WEBPAGE: tinfo
839	** URL: /tinfo?name=ARTIFACTID
840	**
841	** Show the details of a ticket change control artifact.
842	*/
843	void tinfo_page(void){
844	int rid;
	@@ -888,16 +888,16 @@
888	}
889
890
891	/*
892	** WEBPAGE: info
893	** URL: info/ARTIFACTID
894	**
895	** The argument is a artifact ID which might be a baseline or a file or
896	** a ticket changes or a wiki editor or something else.
897	**
898	** Figure out what the artifact ID is and jump to it.
899	*/
900	void info_page(void){
901	const char *zName;
902	Blob uuid;
903	int rid, nName;
904

M src/name.c

+3 -3

		--- src/name.c
		+++ src/name.c
		@@ -144,15 +144,15 @@
144	144	int sym_tag_to_uuid(const char pName, Blob pUuid){
145	145	return tag_to_uuid(pName,pUuid,"sym-");
146	146	}
147	147
148	148	/*
149		-** COMMAND: test-name-to-uuid
	149	+** COMMAND: test-name-to-id
150	150	**
151		-** Convert a name to a full UUID.
	151	+** Convert a name to a full artifact ID.
152	152	*/
153		-void test_name_to_uuid(void){
	153	+void test_name_to_id(void){
154	154	int i;
155	155	Blob name;
156	156	db_must_be_within_tree();
157	157	for(i=2; i<g.argc; i++){
158	158	blob_init(&name, g.argv[i], -1);
159	159

	--- src/name.c
	+++ src/name.c
	@@ -144,15 +144,15 @@
144	int sym_tag_to_uuid(const char pName, Blob pUuid){
145	return tag_to_uuid(pName,pUuid,"sym-");
146	}
147
148	/*
149	** COMMAND: test-name-to-uuid
150	**
151	** Convert a name to a full UUID.
152	*/
153	void test_name_to_uuid(void){
154	int i;
155	Blob name;
156	db_must_be_within_tree();
157	for(i=2; i<g.argc; i++){
158	blob_init(&name, g.argv[i], -1);
159

	--- src/name.c
	+++ src/name.c
	@@ -144,15 +144,15 @@
144	int sym_tag_to_uuid(const char pName, Blob pUuid){
145	return tag_to_uuid(pName,pUuid,"sym-");
146	}
147
148	/*
149	** COMMAND: test-name-to-id
150	**
151	** Convert a name to a full artifact ID.
152	*/
153	void test_name_to_id(void){
154	int i;
155	Blob name;
156	db_must_be_within_tree();
157	for(i=2; i<g.argc; i++){
158	blob_init(&name, g.argv[i], -1);
159

M src/tag.c

+28 -25

		--- src/tag.c
		+++ src/tag.c
		@@ -211,11 +211,11 @@
211	211	}
212	212
213	213
214	214	/*
215	215	** COMMAND: test-tag
216		-** %fossil test-tag (+\|*\|-)TAGNAME UUID ?VALUE?
	216	+** %fossil test-tag (+\|*\|-)TAGNAME ARTIFACT-ID ?VALUE?
217	217	**
218	218	** Add a tag or anti-tag to the rebuildable tables of the local repository.
219	219	** No tag artifact is created so the new tag is erased the next
220	220	** time the repository is rebuilt. This routine is for testing
221	221	** use only.
		@@ -225,11 +225,11 @@
225	225	const char *zValue;
226	226	int rid;
227	227	int tagtype;
228	228	db_must_be_within_tree();
229	229	if( g.argc!=4 && g.argc!=5 ){
230		- usage("TAGNAME UUID ?VALUE?");
	230	+ usage("TAGNAME ARTIFACT-ID ?VALUE?");
231	231	}
232	232	zTag = g.argv[2];
233	233	switch( zTag[0] ){
234	234	case '+': tagtype = 1; break;
235	235	case '*': tagtype = 2; break;
		@@ -247,11 +247,11 @@
247	247	tag_insert(zTag, tagtype, zValue, -1, 0.0, rid);
248	248	db_end_transaction(0);
249	249	}
250	250
251	251	/*
252		-** Prepare an artifact that describes a fork from a certain UUID.
	252	+** Prepare an artifact that describes a fork from a certain baseline.
253	253	** Furthermore a propagating symbolic tag will be inserted and
254	254	** all other propagating symbolic tags will be cancelled.
255	255	**
256	256	** The changes are appended at the Blob pCtrl. However the manifest
257	257	** is not complete at that stage.
		@@ -332,12 +332,15 @@
332	332	}
333	333	rid = name_to_rid(blob_str(&uuid));
334	334	blob_zero(&ctrl);
335	335
336	336	if( validate16(zTagname, strlen(zTagname)) ){
337		- fossil_fatal("invalid tag name \"%s\" - might be confused with a UUID",
338		- zTagname);
	337	+ fossil_fatal(
	338	+ "invalid tag name \"%s\" - might be confused with"
	339	+ " a hexadecimal artifact ID",
	340	+ zTagname
	341	+ );
339	342	}
340	343	if( fork ){
341	344	tag_prepare_fork(&ctrl, zTagname, rid, preflen);
342	345	}else{
343	346	zDate = db_text(0, "SELECT datetime('now')");
		@@ -366,57 +369,57 @@
366	369	** COMMAND: tag
367	370	** Usage: %fossil tag SUBCOMMAND ...
368	371	**
369	372	** Run various subcommands to control tags and properties
370	373	**
371		-** %fossil tag add ?--raw? TAGNAME UUID ?VALUE?
	374	+** %fossil tag add ?--raw? TAGNAME BASELINE ?VALUE?
372	375	**
373		-** Add a new tag or property to UUID. The tag will
374		-** be usable instead of a UUID in commands such as
	376	+** Add a new tag or property to BASELINE. The tag will
	377	+** be usable instead of a BASELINE in commands such as
375	378	** update and merge.
376	379	**
377		-** %fossil tag branch ?--raw? ?--nofork? TAGNAME UUID ?VALUE?
	380	+** %fossil tag branch ?--raw? ?--nofork? TAGNAME BASELINE ?VALUE?
378	381	**
379	382	** A fork will be created so that the new checkin
380		-** is a sibling of UUID and identical to it except
	383	+** is a sibling of BASELINE and identical to it except
381	384	** for a generated comment. Then the new tag will
382	385	** be added to the new checkin and propagated to
383	386	** all direct children. Additionally all symbolic
384		-** tags of that checkin inherited from UUID will
	387	+** tags of that checkin inherited from BASELINE will
385	388	** be cancelled.
386	389	**
387	390	** However, if the option --nofork is given, no
388	391	** fork will be created and the tag/property will be
389		-** added to UUID directly. No tags will be canceled.
	392	+** added to BASELINE directly. No tags will be canceled.
390	393	**
391		-** %fossil tag cancel ?--raw? TAGNAME UUID
	394	+** %fossil tag cancel ?--raw? TAGNAME BASELINE
392	395	**
393		-** Remove the tag TAGNAME from UUID, and also remove
	396	+** Remove the tag TAGNAME from BASELINE, and also remove
394	397	** the propagation of the tag to any descendants.
395	398	**
396	399	** %fossil tag find ?--raw? TAGNAME
397	400	**
398	401	** List all baselines that use TAGNAME
399	402	**
400		-** %fossil tag list ?--raw? ?UUID?
	403	+** %fossil tag list ?--raw? ?BASELINE?
401	404	**
402		-** List all tags, or if UUID is supplied, list
403		-** all tags and their values for UUID.
	405	+** List all tags, or if BASELINE is supplied, list
	406	+** all tags and their values for BASELINE.
404	407	**
405	408	** The option --raw allows the manipulation of all types of
406	409	** tags used for various internal purposes in fossil. You
407	410	** should not use this option to make changes unless you are
408	411	** sure what you are doing.
409	412	**
410	413	** If you need to use a tagname that might be confused with
411		-** a UUID, you can explicitly disambiguate it by prefixing
412		-** it with "tag:". For instance:
	414	+** a hexadecimal baseline or artifact ID, you can explicitly
	415	+** disambiguate it by prefixing it with "tag:". For instance:
413	416	**
414	417	** fossil update decaf
415	418	**
416		-** will be taken as a UUID and fossil will probably complain
417		-** that no such revision was found. However
	419	+** will be taken as an artifact or baseline ID and fossil will
	420	+** probably complain that no such revision was found. However
418	421	**
419	422	** fossil update tag:decaf
420	423	**
421	424	** will assume that "decaf" is a tag/branch name.
422	425	**
		@@ -441,21 +444,21 @@
441	444	blob_set(&tagname, prefix);
442	445
443	446	if( strncmp(g.argv[2],"add",n)==0 ){
444	447	char *zValue;
445	448	if( g.argc!=5 && g.argc!=6 ){
446		- usage("add ?--raw? TAGNAME UUID ?VALUE?");
	449	+ usage("add ?--raw? TAGNAME BASELINE ?VALUE?");
447	450	}
448	451	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
449	452	zValue = g.argc==6 ? g.argv[5] : 0;
450	453	tag_add_artifact(blob_str(&tagname), g.argv[4], zValue, 1, 0, 0);
451	454	}else
452	455
453	456	if( strncmp(g.argv[2],"branch",n)==0 ){
454	457	char *zValue;
455	458	if( g.argc!=5 && g.argc!=6 ){
456		- usage("branch ?--raw? ?--nofork? TAGNAME UUID ?VALUE?");
	459	+ usage("branch ?--raw? ?--nofork? TAGNAME BASELINE ?VALUE?");
457	460	}
458	461	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
459	462	zValue = g.argc==6 ? g.argv[5] : 0;
460	463	tag_add_artifact(blob_str(&tagname), g.argv[4], zValue, 2, fork!=0,
461	464	preflen);
		@@ -465,11 +468,11 @@
465	468	}
466	469	}else
467	470
468	471	if( strncmp(g.argv[2],"cancel",n)==0 ){
469	472	if( g.argc!=5 ){
470		- usage("cancel ?--raw? TAGNAME UUID");
	473	+ usage("cancel ?--raw? TAGNAME BASELINE");
471	474	}
472	475	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
473	476	tag_add_artifact(blob_str(&tagname), g.argv[4], 0, 0, 0, 0);
474	477	}else
475	478
		@@ -529,11 +532,11 @@
529	532	}
530	533	}
531	534	}
532	535	db_finalize(&q);
533	536	}else{
534		- usage("tag list ?UUID?");
	537	+ usage("tag list ?BASELINE?");
535	538	}
536	539	}else
537	540	{
538	541	goto tag_cmd_usage;
539	542	}
540	543

	--- src/tag.c
	+++ src/tag.c
	@@ -211,11 +211,11 @@
211	}
212
213
214	/*
215	** COMMAND: test-tag
216	** %fossil test-tag (+\|*\|-)TAGNAME UUID ?VALUE?
217	**
218	** Add a tag or anti-tag to the rebuildable tables of the local repository.
219	** No tag artifact is created so the new tag is erased the next
220	** time the repository is rebuilt. This routine is for testing
221	** use only.
	@@ -225,11 +225,11 @@
225	const char *zValue;
226	int rid;
227	int tagtype;
228	db_must_be_within_tree();
229	if( g.argc!=4 && g.argc!=5 ){
230	usage("TAGNAME UUID ?VALUE?");
231	}
232	zTag = g.argv[2];
233	switch( zTag[0] ){
234	case '+': tagtype = 1; break;
235	case '*': tagtype = 2; break;
	@@ -247,11 +247,11 @@
247	tag_insert(zTag, tagtype, zValue, -1, 0.0, rid);
248	db_end_transaction(0);
249	}
250
251	/*
252	** Prepare an artifact that describes a fork from a certain UUID.
253	** Furthermore a propagating symbolic tag will be inserted and
254	** all other propagating symbolic tags will be cancelled.
255	**
256	** The changes are appended at the Blob pCtrl. However the manifest
257	** is not complete at that stage.
	@@ -332,12 +332,15 @@
332	}
333	rid = name_to_rid(blob_str(&uuid));
334	blob_zero(&ctrl);
335
336	if( validate16(zTagname, strlen(zTagname)) ){
337	fossil_fatal("invalid tag name \"%s\" - might be confused with a UUID",
338	zTagname);



339	}
340	if( fork ){
341	tag_prepare_fork(&ctrl, zTagname, rid, preflen);
342	}else{
343	zDate = db_text(0, "SELECT datetime('now')");
	@@ -366,57 +369,57 @@
366	** COMMAND: tag
367	** Usage: %fossil tag SUBCOMMAND ...
368	**
369	** Run various subcommands to control tags and properties
370	**
371	** %fossil tag add ?--raw? TAGNAME UUID ?VALUE?
372	**
373	** Add a new tag or property to UUID. The tag will
374	** be usable instead of a UUID in commands such as
375	** update and merge.
376	**
377	** %fossil tag branch ?--raw? ?--nofork? TAGNAME UUID ?VALUE?
378	**
379	** A fork will be created so that the new checkin
380	** is a sibling of UUID and identical to it except
381	** for a generated comment. Then the new tag will
382	** be added to the new checkin and propagated to
383	** all direct children. Additionally all symbolic
384	** tags of that checkin inherited from UUID will
385	** be cancelled.
386	**
387	** However, if the option --nofork is given, no
388	** fork will be created and the tag/property will be
389	** added to UUID directly. No tags will be canceled.
390	**
391	** %fossil tag cancel ?--raw? TAGNAME UUID
392	**
393	** Remove the tag TAGNAME from UUID, and also remove
394	** the propagation of the tag to any descendants.
395	**
396	** %fossil tag find ?--raw? TAGNAME
397	**
398	** List all baselines that use TAGNAME
399	**
400	** %fossil tag list ?--raw? ?UUID?
401	**
402	** List all tags, or if UUID is supplied, list
403	** all tags and their values for UUID.
404	**
405	** The option --raw allows the manipulation of all types of
406	** tags used for various internal purposes in fossil. You
407	** should not use this option to make changes unless you are
408	** sure what you are doing.
409	**
410	** If you need to use a tagname that might be confused with
411	** a UUID, you can explicitly disambiguate it by prefixing
412	** it with "tag:". For instance:
413	**
414	** fossil update decaf
415	**
416	** will be taken as a UUID and fossil will probably complain
417	** that no such revision was found. However
418	**
419	** fossil update tag:decaf
420	**
421	** will assume that "decaf" is a tag/branch name.
422	**
	@@ -441,21 +444,21 @@
441	blob_set(&tagname, prefix);
442
443	if( strncmp(g.argv[2],"add",n)==0 ){
444	char *zValue;
445	if( g.argc!=5 && g.argc!=6 ){
446	usage("add ?--raw? TAGNAME UUID ?VALUE?");
447	}
448	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
449	zValue = g.argc==6 ? g.argv[5] : 0;
450	tag_add_artifact(blob_str(&tagname), g.argv[4], zValue, 1, 0, 0);
451	}else
452
453	if( strncmp(g.argv[2],"branch",n)==0 ){
454	char *zValue;
455	if( g.argc!=5 && g.argc!=6 ){
456	usage("branch ?--raw? ?--nofork? TAGNAME UUID ?VALUE?");
457	}
458	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
459	zValue = g.argc==6 ? g.argv[5] : 0;
460	tag_add_artifact(blob_str(&tagname), g.argv[4], zValue, 2, fork!=0,
461	preflen);
	@@ -465,11 +468,11 @@
465	}
466	}else
467
468	if( strncmp(g.argv[2],"cancel",n)==0 ){
469	if( g.argc!=5 ){
470	usage("cancel ?--raw? TAGNAME UUID");
471	}
472	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
473	tag_add_artifact(blob_str(&tagname), g.argv[4], 0, 0, 0, 0);
474	}else
475
	@@ -529,11 +532,11 @@
529	}
530	}
531	}
532	db_finalize(&q);
533	}else{
534	usage("tag list ?UUID?");
535	}
536	}else
537	{
538	goto tag_cmd_usage;
539	}
540

	--- src/tag.c
	+++ src/tag.c
	@@ -211,11 +211,11 @@
211	}
212
213
214	/*
215	** COMMAND: test-tag
216	** %fossil test-tag (+\|*\|-)TAGNAME ARTIFACT-ID ?VALUE?
217	**
218	** Add a tag or anti-tag to the rebuildable tables of the local repository.
219	** No tag artifact is created so the new tag is erased the next
220	** time the repository is rebuilt. This routine is for testing
221	** use only.
	@@ -225,11 +225,11 @@
225	const char *zValue;
226	int rid;
227	int tagtype;
228	db_must_be_within_tree();
229	if( g.argc!=4 && g.argc!=5 ){
230	usage("TAGNAME ARTIFACT-ID ?VALUE?");
231	}
232	zTag = g.argv[2];
233	switch( zTag[0] ){
234	case '+': tagtype = 1; break;
235	case '*': tagtype = 2; break;
	@@ -247,11 +247,11 @@
247	tag_insert(zTag, tagtype, zValue, -1, 0.0, rid);
248	db_end_transaction(0);
249	}
250
251	/*
252	** Prepare an artifact that describes a fork from a certain baseline.
253	** Furthermore a propagating symbolic tag will be inserted and
254	** all other propagating symbolic tags will be cancelled.
255	**
256	** The changes are appended at the Blob pCtrl. However the manifest
257	** is not complete at that stage.
	@@ -332,12 +332,15 @@
332	}
333	rid = name_to_rid(blob_str(&uuid));
334	blob_zero(&ctrl);
335
336	if( validate16(zTagname, strlen(zTagname)) ){
337	fossil_fatal(
338	"invalid tag name \"%s\" - might be confused with"
339	" a hexadecimal artifact ID",
340	zTagname
341	);
342	}
343	if( fork ){
344	tag_prepare_fork(&ctrl, zTagname, rid, preflen);
345	}else{
346	zDate = db_text(0, "SELECT datetime('now')");
	@@ -366,57 +369,57 @@
369	** COMMAND: tag
370	** Usage: %fossil tag SUBCOMMAND ...
371	**
372	** Run various subcommands to control tags and properties
373	**
374	** %fossil tag add ?--raw? TAGNAME BASELINE ?VALUE?
375	**
376	** Add a new tag or property to BASELINE. The tag will
377	** be usable instead of a BASELINE in commands such as
378	** update and merge.
379	**
380	** %fossil tag branch ?--raw? ?--nofork? TAGNAME BASELINE ?VALUE?
381	**
382	** A fork will be created so that the new checkin
383	** is a sibling of BASELINE and identical to it except
384	** for a generated comment. Then the new tag will
385	** be added to the new checkin and propagated to
386	** all direct children. Additionally all symbolic
387	** tags of that checkin inherited from BASELINE will
388	** be cancelled.
389	**
390	** However, if the option --nofork is given, no
391	** fork will be created and the tag/property will be
392	** added to BASELINE directly. No tags will be canceled.
393	**
394	** %fossil tag cancel ?--raw? TAGNAME BASELINE
395	**
396	** Remove the tag TAGNAME from BASELINE, and also remove
397	** the propagation of the tag to any descendants.
398	**
399	** %fossil tag find ?--raw? TAGNAME
400	**
401	** List all baselines that use TAGNAME
402	**
403	** %fossil tag list ?--raw? ?BASELINE?
404	**
405	** List all tags, or if BASELINE is supplied, list
406	** all tags and their values for BASELINE.
407	**
408	** The option --raw allows the manipulation of all types of
409	** tags used for various internal purposes in fossil. You
410	** should not use this option to make changes unless you are
411	** sure what you are doing.
412	**
413	** If you need to use a tagname that might be confused with
414	** a hexadecimal baseline or artifact ID, you can explicitly
415	** disambiguate it by prefixing it with "tag:". For instance:
416	**
417	** fossil update decaf
418	**
419	** will be taken as an artifact or baseline ID and fossil will
420	** probably complain that no such revision was found. However
421	**
422	** fossil update tag:decaf
423	**
424	** will assume that "decaf" is a tag/branch name.
425	**
	@@ -441,21 +444,21 @@
444	blob_set(&tagname, prefix);
445
446	if( strncmp(g.argv[2],"add",n)==0 ){
447	char *zValue;
448	if( g.argc!=5 && g.argc!=6 ){
449	usage("add ?--raw? TAGNAME BASELINE ?VALUE?");
450	}
451	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
452	zValue = g.argc==6 ? g.argv[5] : 0;
453	tag_add_artifact(blob_str(&tagname), g.argv[4], zValue, 1, 0, 0);
454	}else
455
456	if( strncmp(g.argv[2],"branch",n)==0 ){
457	char *zValue;
458	if( g.argc!=5 && g.argc!=6 ){
459	usage("branch ?--raw? ?--nofork? TAGNAME BASELINE ?VALUE?");
460	}
461	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
462	zValue = g.argc==6 ? g.argv[5] : 0;
463	tag_add_artifact(blob_str(&tagname), g.argv[4], zValue, 2, fork!=0,
464	preflen);
	@@ -465,11 +468,11 @@
468	}
469	}else
470
471	if( strncmp(g.argv[2],"cancel",n)==0 ){
472	if( g.argc!=5 ){
473	usage("cancel ?--raw? TAGNAME BASELINE");
474	}
475	blob_append(&tagname, g.argv[3], strlen(g.argv[3]));
476	tag_add_artifact(blob_str(&tagname), g.argv[4], 0, 0, 0, 0);
477	}else
478
	@@ -529,11 +532,11 @@
532	}
533	}
534	}
535	db_finalize(&q);
536	}else{
537	usage("tag list ?BASELINE?");
538	}
539	}else
540	{
541	goto tag_cmd_usage;
542	}
543

M src/timeline.c

+3 -3

		--- src/timeline.c
		+++ src/timeline.c
		@@ -554,11 +554,11 @@
554	554	}
555	555
556	556	/*
557	557	** COMMAND: timeline
558	558	**
559		-** Usage: %fossil timeline ?WHEN? ?UUID\|DATETIME? ?-n\|--count N?
	559	+** Usage: %fossil timeline ?WHEN? ?BASELINE\|DATETIME? ?-n\|--count N?
560	560	**
561	561	** Print a summary of activity going backwards in date and time
562	562	** specified or from the current date and time if no arguments
563	563	** are given. Show as many as N (default 20) check-ins. The
564	564	** WHEN argument can be any unique abbreviation of one of these
		@@ -567,11 +567,11 @@
567	567	** before
568	568	** after
569	569	** descendants \| children
570	570	** ancestors \| parents
571	571	**
572		-** The UUID can be any unique prefix of 4 characters or more.
	572	+** The BASELINE can be any unique prefix of 4 characters or more.
573	573	** The DATETIME should be in the ISO8601 format. For
574	574	** examples: "2007-08-18 07:21:21". You can also say "current"
575	575	** for the current version or "now" for the current time.
576	576	*/
577	577	void timeline_cmd(void){
		@@ -604,11 +604,11 @@
604	604	}else if( strncmp(g.argv[2],"ancestors",k)==0 && k>1 ){
605	605	mode = 4;
606	606	}else if( strncmp(g.argv[2],"parents",k)==0 ){
607	607	mode = 4;
608	608	}else{
609		- usage("?WHEN? ?UUID\|DATETIME?");
	609	+ usage("?WHEN? ?BASELINE\|DATETIME?");
610	610	}
611	611	zOrigin = g.argv[3];
612	612	}else if( g.argc==3 ){
613	613	zOrigin = g.argv[2];
614	614	}else{
615	615

	--- src/timeline.c
	+++ src/timeline.c
	@@ -554,11 +554,11 @@
554	}
555
556	/*
557	** COMMAND: timeline
558	**
559	** Usage: %fossil timeline ?WHEN? ?UUID\|DATETIME? ?-n\|--count N?
560	**
561	** Print a summary of activity going backwards in date and time
562	** specified or from the current date and time if no arguments
563	** are given. Show as many as N (default 20) check-ins. The
564	** WHEN argument can be any unique abbreviation of one of these
	@@ -567,11 +567,11 @@
567	** before
568	** after
569	** descendants \| children
570	** ancestors \| parents
571	**
572	** The UUID can be any unique prefix of 4 characters or more.
573	** The DATETIME should be in the ISO8601 format. For
574	** examples: "2007-08-18 07:21:21". You can also say "current"
575	** for the current version or "now" for the current time.
576	*/
577	void timeline_cmd(void){
	@@ -604,11 +604,11 @@
604	}else if( strncmp(g.argv[2],"ancestors",k)==0 && k>1 ){
605	mode = 4;
606	}else if( strncmp(g.argv[2],"parents",k)==0 ){
607	mode = 4;
608	}else{
609	usage("?WHEN? ?UUID\|DATETIME?");
610	}
611	zOrigin = g.argv[3];
612	}else if( g.argc==3 ){
613	zOrigin = g.argv[2];
614	}else{
615

	--- src/timeline.c
	+++ src/timeline.c
	@@ -554,11 +554,11 @@
554	}
555
556	/*
557	** COMMAND: timeline
558	**
559	** Usage: %fossil timeline ?WHEN? ?BASELINE\|DATETIME? ?-n\|--count N?
560	**
561	** Print a summary of activity going backwards in date and time
562	** specified or from the current date and time if no arguments
563	** are given. Show as many as N (default 20) check-ins. The
564	** WHEN argument can be any unique abbreviation of one of these
	@@ -567,11 +567,11 @@
567	** before
568	** after
569	** descendants \| children
570	** ancestors \| parents
571	**
572	** The BASELINE can be any unique prefix of 4 characters or more.
573	** The DATETIME should be in the ISO8601 format. For
574	** examples: "2007-08-18 07:21:21". You can also say "current"
575	** for the current version or "now" for the current time.
576	*/
577	void timeline_cmd(void){
	@@ -604,11 +604,11 @@
604	}else if( strncmp(g.argv[2],"ancestors",k)==0 && k>1 ){
605	mode = 4;
606	}else if( strncmp(g.argv[2],"parents",k)==0 ){
607	mode = 4;
608	}else{
609	usage("?WHEN? ?BASELINE\|DATETIME?");
610	}
611	zOrigin = g.argv[3];
612	}else if( g.argc==3 ){
613	zOrigin = g.argv[2];
614	}else{
615

M src/wiki.c

+6 -6

		--- src/wiki.c
		+++ src/wiki.c
		@@ -114,11 +114,11 @@
114	114	** WEBPAGE: wiki
115	115	** URL: /wiki?name=PAGENAME
116	116	*/
117	117	void wiki_page(void){
118	118	char *zTag;
119		- int rid;
	119	+ int rid = 0;
120	120	int isSandbox;
121	121	Blob wiki;
122	122	Manifest m;
123	123	const char *zPageName;
124	124	char *zHtmlPageName;
		@@ -551,11 +551,11 @@
551	551	@ which is not a bullet or enumeration list item is rendered
552	552	@ indented. Only a single level of indentation is supported by wiki; use
553	553	@ HTML for deeper indentation.</p>
554	554	@ <li> <p><b>Hyperlinks</b>.
555	555	@ Text within square brackets ("[...]") becomes a hyperlink. The
556		- @ target can be a wiki page name, the UUID of a check-in or ticket,
	556	+ @ target can be a wiki page name, the artifact ID of a check-in or ticket,
557	557	@ the name of an image, or a URL. By default, the target is displayed
558	558	@ as the text of the hyperlink. But you can specify alternative text
559	559	@ after the target name separated by a "\|" character.</p>
560	560	@ <li> <p><b>HTML</b>.
561	561	@ The following standard HTML elements may be used:
		@@ -707,11 +707,11 @@
707	707	** Lists all wiki entries, one per line, ordered
708	708	** case-insentively by name.
709	709	**
710	710	** TODOs:
711	711	**
712		-** %fossil wiki export ?-u UUID? WikiName ?FILE?
	712	+** %fossil wiki export ?-u ARTIFACT? WikiName ?FILE?
713	713	**
714	714	** Outputs the selected version of WikiName.
715	715	**
716	716	** %fossil wiki delete ?-m MESSAGE? WikiName
717	717	**
		@@ -718,14 +718,14 @@
718	718	** The same as deleting a file entry, but i don't know if fossil
719	719	** supports a commit message for Wiki entries.
720	720	**
721	721	** %fossil wiki ?-u? ?-d? ?-s=[\|]? list
722	722	**
723		-** Lists the UUID and/or Date of last change along with each entry
724		-** name, delimited by the -s char.
	723	+** Lists the artifact ID and/or Date of last change along with
	724	+** each entry name, delimited by the -s char.
725	725	**
726		-** %fossil wiki diff ?UUID? ?-f infile[=stdin]? EntryName
	726	+** %fossil wiki diff ?ARTIFACT? ?-f infile[=stdin]? EntryName
727	727	**
728	728	** Diffs the local copy of a page with a given version (defaulting
729	729	** to the head version).
730	730	*/
731	731	void wiki_cmd(void){
732	732

	--- src/wiki.c
	+++ src/wiki.c
	@@ -114,11 +114,11 @@
114	** WEBPAGE: wiki
115	** URL: /wiki?name=PAGENAME
116	*/
117	void wiki_page(void){
118	char *zTag;
119	int rid;
120	int isSandbox;
121	Blob wiki;
122	Manifest m;
123	const char *zPageName;
124	char *zHtmlPageName;
	@@ -551,11 +551,11 @@
551	@ which is not a bullet or enumeration list item is rendered
552	@ indented. Only a single level of indentation is supported by wiki; use
553	@ HTML for deeper indentation.</p>
554	@ <li> <p><b>Hyperlinks</b>.
555	@ Text within square brackets ("[...]") becomes a hyperlink. The
556	@ target can be a wiki page name, the UUID of a check-in or ticket,
557	@ the name of an image, or a URL. By default, the target is displayed
558	@ as the text of the hyperlink. But you can specify alternative text
559	@ after the target name separated by a "\|" character.</p>
560	@ <li> <p><b>HTML</b>.
561	@ The following standard HTML elements may be used:
	@@ -707,11 +707,11 @@
707	** Lists all wiki entries, one per line, ordered
708	** case-insentively by name.
709	**
710	** TODOs:
711	**
712	** %fossil wiki export ?-u UUID? WikiName ?FILE?
713	**
714	** Outputs the selected version of WikiName.
715	**
716	** %fossil wiki delete ?-m MESSAGE? WikiName
717	**
	@@ -718,14 +718,14 @@
718	** The same as deleting a file entry, but i don't know if fossil
719	** supports a commit message for Wiki entries.
720	**
721	** %fossil wiki ?-u? ?-d? ?-s=[\|]? list
722	**
723	** Lists the UUID and/or Date of last change along with each entry
724	** name, delimited by the -s char.
725	**
726	** %fossil wiki diff ?UUID? ?-f infile[=stdin]? EntryName
727	**
728	** Diffs the local copy of a page with a given version (defaulting
729	** to the head version).
730	*/
731	void wiki_cmd(void){
732

	--- src/wiki.c
	+++ src/wiki.c
	@@ -114,11 +114,11 @@
114	** WEBPAGE: wiki
115	** URL: /wiki?name=PAGENAME
116	*/
117	void wiki_page(void){
118	char *zTag;
119	int rid = 0;
120	int isSandbox;
121	Blob wiki;
122	Manifest m;
123	const char *zPageName;
124	char *zHtmlPageName;
	@@ -551,11 +551,11 @@
551	@ which is not a bullet or enumeration list item is rendered
552	@ indented. Only a single level of indentation is supported by wiki; use
553	@ HTML for deeper indentation.</p>
554	@ <li> <p><b>Hyperlinks</b>.
555	@ Text within square brackets ("[...]") becomes a hyperlink. The
556	@ target can be a wiki page name, the artifact ID of a check-in or ticket,
557	@ the name of an image, or a URL. By default, the target is displayed
558	@ as the text of the hyperlink. But you can specify alternative text
559	@ after the target name separated by a "\|" character.</p>
560	@ <li> <p><b>HTML</b>.
561	@ The following standard HTML elements may be used:
	@@ -707,11 +707,11 @@
707	** Lists all wiki entries, one per line, ordered
708	** case-insentively by name.
709	**
710	** TODOs:
711	**
712	** %fossil wiki export ?-u ARTIFACT? WikiName ?FILE?
713	**
714	** Outputs the selected version of WikiName.
715	**
716	** %fossil wiki delete ?-m MESSAGE? WikiName
717	**
	@@ -718,14 +718,14 @@
718	** The same as deleting a file entry, but i don't know if fossil
719	** supports a commit message for Wiki entries.
720	**
721	** %fossil wiki ?-u? ?-d? ?-s=[\|]? list
722	**
723	** Lists the artifact ID and/or Date of last change along with
724	** each entry name, delimited by the -s char.
725	**
726	** %fossil wiki diff ?ARTIFACT? ?-f infile[=stdin]? EntryName
727	**
728	** Diffs the local copy of a page with a given version (defaulting
729	** to the head version).
730	*/
731	void wiki_cmd(void){
732

M www/bugtheory.wiki

+6 -6

		--- www/bugtheory.wiki
		+++ www/bugtheory.wiki
		@@ -42,31 +42,31 @@
42	42	<h2>Interpretation Of Ticket Change Artifacts</h2>
43	43
44	44	Every ticket change artifact contains (among other things)
45	45
46	46	* a timestamp,
47		- * a ticket UUID, and
	47	+ * a ticket ID, and
48	48	* one or more name/value pairs.
49	49
50	50	The current state of a ticket is found by replaying all ticket
51		-change artifacts with the same ticket UUID in timestamp order.
	51	+change artifacts with the same ticket ID in timestamp order.
52	52	For a given ticket, all values are initially NULL. As each
53	53	ticket change artifact is encountered, values are either replaced
54	54	or appended, according to a flag on the name/value pair. The current
55	55	values for the fields of a ticket are the values that remain at the
56	56	end of the replay process.
57	57
58	58	To create a new ticket, one inserts a ticket change
59		-artifact with a new UUID. The ticket UUID
	59	+artifact with a new ID. The ticket ID
60	60	is a random 40-character lower-case hexadecimal number. The "tktnew"
61		-page in the fossil web interface creates new ticket UUIDs
	61	+page in the fossil web interface creates new ticket IDs
62	62	using a good source of randomness to insure uniqueness.
63	63	The name/value pairs on the initial ticket change
64	64	artifact are the initial values for the fields in the ticket.
65	65
66	66	Amending a ticket means simply creating a new artifact with the
67		-same ticket UUID and with name/value pairs for those fields which
	67	+same ticket ID and with name/value pairs for those fields which
68	68	are changing. Fields of the ticket which are not being modified
69	69	should not appear as name/value pairs in the new artifact.
70	70
71	71	This approach to storing ticket state means that independently entered
72	72	changes are automatically merged together when artifacts are shared
		@@ -94,11 +94,11 @@
94	94	but the interpretation and display of that information is local state.
95	95	Hence, each repository is free to set up its own ticket display and
96	96	input formats and reporting rules according to its own particular needs.
97	97
98	98	Each repository defines its own TICKET table in its database. There is
99		-one row in the TICKET table for each unique ticket UUID. The
	99	+one row in the TICKET table for each unique ticket ID. The
100	100	names of columns in the TICKET table correspond to the names in
101	101	the name/value pairs of ticket change artifacts. When running the replay
102	102	algorithm, if a name/value pair is seen which has no corresponding column
103	103	in the TICKET table, then that name/value pair is ignored. Columns can
104	104	be added or removed from the TICKET table at any time. Whenever the
105	105

	--- www/bugtheory.wiki
	+++ www/bugtheory.wiki
	@@ -42,31 +42,31 @@
42	<h2>Interpretation Of Ticket Change Artifacts</h2>
43
44	Every ticket change artifact contains (among other things)
45
46	* a timestamp,
47	* a ticket UUID, and
48	* one or more name/value pairs.
49
50	The current state of a ticket is found by replaying all ticket
51	change artifacts with the same ticket UUID in timestamp order.
52	For a given ticket, all values are initially NULL. As each
53	ticket change artifact is encountered, values are either replaced
54	or appended, according to a flag on the name/value pair. The current
55	values for the fields of a ticket are the values that remain at the
56	end of the replay process.
57
58	To create a new ticket, one inserts a ticket change
59	artifact with a new UUID. The ticket UUID
60	is a random 40-character lower-case hexadecimal number. The "tktnew"
61	page in the fossil web interface creates new ticket UUIDs
62	using a good source of randomness to insure uniqueness.
63	The name/value pairs on the initial ticket change
64	artifact are the initial values for the fields in the ticket.
65
66	Amending a ticket means simply creating a new artifact with the
67	same ticket UUID and with name/value pairs for those fields which
68	are changing. Fields of the ticket which are not being modified
69	should not appear as name/value pairs in the new artifact.
70
71	This approach to storing ticket state means that independently entered
72	changes are automatically merged together when artifacts are shared
	@@ -94,11 +94,11 @@
94	but the interpretation and display of that information is local state.
95	Hence, each repository is free to set up its own ticket display and
96	input formats and reporting rules according to its own particular needs.
97
98	Each repository defines its own TICKET table in its database. There is
99	one row in the TICKET table for each unique ticket UUID. The
100	names of columns in the TICKET table correspond to the names in
101	the name/value pairs of ticket change artifacts. When running the replay
102	algorithm, if a name/value pair is seen which has no corresponding column
103	in the TICKET table, then that name/value pair is ignored. Columns can
104	be added or removed from the TICKET table at any time. Whenever the
105

	--- www/bugtheory.wiki
	+++ www/bugtheory.wiki
	@@ -42,31 +42,31 @@
42	<h2>Interpretation Of Ticket Change Artifacts</h2>
43
44	Every ticket change artifact contains (among other things)
45
46	* a timestamp,
47	* a ticket ID, and
48	* one or more name/value pairs.
49
50	The current state of a ticket is found by replaying all ticket
51	change artifacts with the same ticket ID in timestamp order.
52	For a given ticket, all values are initially NULL. As each
53	ticket change artifact is encountered, values are either replaced
54	or appended, according to a flag on the name/value pair. The current
55	values for the fields of a ticket are the values that remain at the
56	end of the replay process.
57
58	To create a new ticket, one inserts a ticket change
59	artifact with a new ID. The ticket ID
60	is a random 40-character lower-case hexadecimal number. The "tktnew"
61	page in the fossil web interface creates new ticket IDs
62	using a good source of randomness to insure uniqueness.
63	The name/value pairs on the initial ticket change
64	artifact are the initial values for the fields in the ticket.
65
66	Amending a ticket means simply creating a new artifact with the
67	same ticket ID and with name/value pairs for those fields which
68	are changing. Fields of the ticket which are not being modified
69	should not appear as name/value pairs in the new artifact.
70
71	This approach to storing ticket state means that independently entered
72	changes are automatically merged together when artifacts are shared
	@@ -94,11 +94,11 @@
94	but the interpretation and display of that information is local state.
95	Hence, each repository is free to set up its own ticket display and
96	input formats and reporting rules according to its own particular needs.
97
98	Each repository defines its own TICKET table in its database. There is
99	one row in the TICKET table for each unique ticket ID. The
100	names of columns in the TICKET table correspond to the names in
101	the name/value pairs of ticket change artifacts. When running the replay
102	algorithm, if a name/value pair is seen which has no corresponding column
103	in the TICKET table, then that name/value pair is ignored. Columns can
104	be added or removed from the TICKET table at any time. Whenever the
105

M www/concepts.wiki

+15 -15

		--- www/concepts.wiki
		+++ www/concepts.wiki
		@@ -83,19 +83,19 @@
83	83
84	84	<p>A particular version of a particular file is called an "artifact".
85	85	Each artifact has a universally unique name which is the
86	86	<a href="http://en.wikipedia.org/wiki/SHA">SHA1</a> hash of the content
87	87	of that file expressed as 40 characters of lower-case hexadecimal. Such
88		-a hash is referred to as the Universally Unique Identifier or UUID
	88	+a hash is referred to as the Artifact Identifier or Artifact ID
89	89	for the artifact. The SHA1 algorithm is created with the purpose of
90	90	providing a highly forgery-resistent identifier for a file. Given any
91		-file it is simple to find the UUID for that file. But given a
92		-UUID it is computationally intractable to generate a file that will
93		-have that UUID.</p>
	91	+file it is simple to find the artifact ID for that file. But given a
	92	+artifact ID it is computationally intractable to generate a file that will
	93	+have that Artifact ID.</p>
94	94
95	95
96		-<p>UUIDs look something like this:</p>
	96	+<p>Artifact IDs look something like this:</p>
97	97
98	98	<blockquote><b>
99	99	6089f0b563a9db0a6d90682fe47fd7161ff867c8<br>
100	100	59712614a1b3ccfd84078a37fa5b606e28434326<br>
101	101	19dbf73078be9779edd6a0156195e610f81c94f9<br>
		@@ -102,17 +102,17 @@
102	102	b4104959a67175f02d6b415480be22a239f1f077<br>
103	103	997c9d6ae03ad114b2b57f04e9eeef17dcb82788
104	104	</b></blockquote>
105	105
106	106	<p>When referring to an artifact using fossil, you can use a unique
107		-prefix of the UUID that is four characters or longer. This saves
108		-a lot of typing. When displaying UUIDs, fossil will usually only
	107	+prefix of the artifact ID that is four characters or longer. This saves
	108	+a lot of typing. When displaying artifact IDs, fossil will usually only
109	109	show the first 10 digits since that is normally enough to uniquely
110	110	identify a file.</p>
111	111
112	112	<p>Changing (or adding or removing) a single byte in a file results
113		-in a completely different UUID. And since the UUID is the name of
	113	+in a completely different artifact ID. And since the artifact ID is the name of
114	114	the artifact, making any change to a file results in a new artifact.
115	115	In this way, artifacts are immutable.</p>
116	116
117	117	<p>A repository is really just an unordered collection of
118	118	artifacts. New artifacts can be added to the repository, but
		@@ -124,16 +124,16 @@
124	124
125	125	<h3>2.2 Manifests</h3>
126	126
127	127	<p>At the root of a source tree is a special file called the
128	128	"manifest". The manifest is a listing of all other files in
129		-that source tree. The manifest contains the (complete) UUID
	129	+that source tree. The manifest contains the (complete) artifact ID
130	130	of the file and the name of the file as it appears on disk,
131		-and thus serves as a mapping from UUID to disk name. The UUID
132		-of the manifest is the UUID that identifies a baseline. When
133		-you look at a "timeline" of changes in fossil, the UUID associated
134		-with each check-in or commit is really just the UUID of the
	131	+and thus serves as a mapping from artifact ID to disk name. The artifact ID
	132	+of the manifest is the identifier for the entire baseline. When
	133	+you look at a "timeline" of changes in fossil, the ID associated
	134	+with each check-in or commit is really just the artifact ID of the
135	135	manifest for that baseline.</p>
136	136
137	137	<p>Fossil automatically generates a manifest whenever you "commit"
138	138	a new baseline. So this is not something that you, the developer,
139	139	need to worry with. The format of a manifest is intentionally
		@@ -157,15 +157,15 @@
157	157	in a hierarchy.</li>
158	158	<li>A <b>repository</b> keeps a record of historical baselines.</li>
159	159	<li>Repositories share their changes using <b>push</b>, <b>pull</b>,
160	160	<b>sync</b>, and <b>clone</b>.</li>
161	161	<li>A particular version of a particular file is an <b>artifact</b>
162		- that is identified by a <b>UUID</b>.</li>
	162	+ that is identified by an <b>artifact ID</b>.</li>
163	163	<li>Artifacts tracked by fossil are inherently immutable.</li>
164	164	<li>Fossil automatically generates a <b>manifest</b> file that identifies
165	165	every artifact in a baseline.</li>
166		-<li>The UUID of the manifest is the UUID of the baseline.</li>
	166	+<li>The artifact ID of the manifest is the identifier of the baseline.</li>
167	167	</ul>
168	168
169	169	<h2>3.0 Fossil - The Program</h2>
170	170
171	171	<p>Fossil is software. The implementation of fossil is in the form
172	172

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -83,19 +83,19 @@
83
84	<p>A particular version of a particular file is called an "artifact".
85	Each artifact has a universally unique name which is the
86	<a href="http://en.wikipedia.org/wiki/SHA">SHA1</a> hash of the content
87	of that file expressed as 40 characters of lower-case hexadecimal. Such
88	a hash is referred to as the Universally Unique Identifier or UUID
89	for the artifact. The SHA1 algorithm is created with the purpose of
90	providing a highly forgery-resistent identifier for a file. Given any
91	file it is simple to find the UUID for that file. But given a
92	UUID it is computationally intractable to generate a file that will
93	have that UUID.</p>
94
95
96	<p>UUIDs look something like this:</p>
97
98	<blockquote><b>
99	6089f0b563a9db0a6d90682fe47fd7161ff867c8<br>
100	59712614a1b3ccfd84078a37fa5b606e28434326<br>
101	19dbf73078be9779edd6a0156195e610f81c94f9<br>
	@@ -102,17 +102,17 @@
102	b4104959a67175f02d6b415480be22a239f1f077<br>
103	997c9d6ae03ad114b2b57f04e9eeef17dcb82788
104	</b></blockquote>
105
106	<p>When referring to an artifact using fossil, you can use a unique
107	prefix of the UUID that is four characters or longer. This saves
108	a lot of typing. When displaying UUIDs, fossil will usually only
109	show the first 10 digits since that is normally enough to uniquely
110	identify a file.</p>
111
112	<p>Changing (or adding or removing) a single byte in a file results
113	in a completely different UUID. And since the UUID is the name of
114	the artifact, making any change to a file results in a new artifact.
115	In this way, artifacts are immutable.</p>
116
117	<p>A repository is really just an unordered collection of
118	artifacts. New artifacts can be added to the repository, but
	@@ -124,16 +124,16 @@
124
125	<h3>2.2 Manifests</h3>
126
127	<p>At the root of a source tree is a special file called the
128	"manifest". The manifest is a listing of all other files in
129	that source tree. The manifest contains the (complete) UUID
130	of the file and the name of the file as it appears on disk,
131	and thus serves as a mapping from UUID to disk name. The UUID
132	of the manifest is the UUID that identifies a baseline. When
133	you look at a "timeline" of changes in fossil, the UUID associated
134	with each check-in or commit is really just the UUID of the
135	manifest for that baseline.</p>
136
137	<p>Fossil automatically generates a manifest whenever you "commit"
138	a new baseline. So this is not something that you, the developer,
139	need to worry with. The format of a manifest is intentionally
	@@ -157,15 +157,15 @@
157	in a hierarchy.</li>
158	<li>A <b>repository</b> keeps a record of historical baselines.</li>
159	<li>Repositories share their changes using <b>push</b>, <b>pull</b>,
160	<b>sync</b>, and <b>clone</b>.</li>
161	<li>A particular version of a particular file is an <b>artifact</b>
162	that is identified by a <b>UUID</b>.</li>
163	<li>Artifacts tracked by fossil are inherently immutable.</li>
164	<li>Fossil automatically generates a <b>manifest</b> file that identifies
165	every artifact in a baseline.</li>
166	<li>The UUID of the manifest is the UUID of the baseline.</li>
167	</ul>
168
169	<h2>3.0 Fossil - The Program</h2>
170
171	<p>Fossil is software. The implementation of fossil is in the form
172

	--- www/concepts.wiki
	+++ www/concepts.wiki
	@@ -83,19 +83,19 @@
83
84	<p>A particular version of a particular file is called an "artifact".
85	Each artifact has a universally unique name which is the
86	<a href="http://en.wikipedia.org/wiki/SHA">SHA1</a> hash of the content
87	of that file expressed as 40 characters of lower-case hexadecimal. Such
88	a hash is referred to as the Artifact Identifier or Artifact ID
89	for the artifact. The SHA1 algorithm is created with the purpose of
90	providing a highly forgery-resistent identifier for a file. Given any
91	file it is simple to find the artifact ID for that file. But given a
92	artifact ID it is computationally intractable to generate a file that will
93	have that Artifact ID.</p>
94
95
96	<p>Artifact IDs look something like this:</p>
97
98	<blockquote><b>
99	6089f0b563a9db0a6d90682fe47fd7161ff867c8<br>
100	59712614a1b3ccfd84078a37fa5b606e28434326<br>
101	19dbf73078be9779edd6a0156195e610f81c94f9<br>
	@@ -102,17 +102,17 @@
102	b4104959a67175f02d6b415480be22a239f1f077<br>
103	997c9d6ae03ad114b2b57f04e9eeef17dcb82788
104	</b></blockquote>
105
106	<p>When referring to an artifact using fossil, you can use a unique
107	prefix of the artifact ID that is four characters or longer. This saves
108	a lot of typing. When displaying artifact IDs, fossil will usually only
109	show the first 10 digits since that is normally enough to uniquely
110	identify a file.</p>
111
112	<p>Changing (or adding or removing) a single byte in a file results
113	in a completely different artifact ID. And since the artifact ID is the name of
114	the artifact, making any change to a file results in a new artifact.
115	In this way, artifacts are immutable.</p>
116
117	<p>A repository is really just an unordered collection of
118	artifacts. New artifacts can be added to the repository, but
	@@ -124,16 +124,16 @@
124
125	<h3>2.2 Manifests</h3>
126
127	<p>At the root of a source tree is a special file called the
128	"manifest". The manifest is a listing of all other files in
129	that source tree. The manifest contains the (complete) artifact ID
130	of the file and the name of the file as it appears on disk,
131	and thus serves as a mapping from artifact ID to disk name. The artifact ID
132	of the manifest is the identifier for the entire baseline. When
133	you look at a "timeline" of changes in fossil, the ID associated
134	with each check-in or commit is really just the artifact ID of the
135	manifest for that baseline.</p>
136
137	<p>Fossil automatically generates a manifest whenever you "commit"
138	a new baseline. So this is not something that you, the developer,
139	need to worry with. The format of a manifest is intentionally
	@@ -157,15 +157,15 @@
157	in a hierarchy.</li>
158	<li>A <b>repository</b> keeps a record of historical baselines.</li>
159	<li>Repositories share their changes using <b>push</b>, <b>pull</b>,
160	<b>sync</b>, and <b>clone</b>.</li>
161	<li>A particular version of a particular file is an <b>artifact</b>
162	that is identified by an <b>artifact ID</b>.</li>
163	<li>Artifacts tracked by fossil are inherently immutable.</li>
164	<li>Fossil automatically generates a <b>manifest</b> file that identifies
165	every artifact in a baseline.</li>
166	<li>The artifact ID of the manifest is the identifier of the baseline.</li>
167	</ul>
168
169	<h2>3.0 Fossil - The Program</h2>
170
171	<p>Fossil is software. The implementation of fossil is in the form
172

M www/embeddeddoc.wiki

+2 -2

		--- www/embeddeddoc.wiki
		+++ www/embeddeddoc.wiki
		@@ -41,12 +41,12 @@
41	41	<b>http://www.hwaci.com/cgi-bin/fossil</b>.
42	42	If you launch the web server using the "<b>fossil server</b>" command line,
43	43	then the <i><baseurl></i> is usually
44	44	<b>http://localhost:8080/</b>.
45	45
46		-The <i><version></i> is any unique UUID prefix of the baseline
47		-for the documentation you want to access.
	46	+The <i><version></i> is any unique prefix of the baseline ID for
	47	+the baseline containing the documentation you want to access.
48	48	Or <i><version></i> can be one of the keywords "<b>tip</b>" or
49	49	"<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently
50	50	checked-in baseline. This is useful if you want to see the very latest
51	51	version of the documentation. The "<b>ckout</b>" keywords means to
52	52	pull the documentation file from the local source tree on disk, not
53	53

	--- www/embeddeddoc.wiki
	+++ www/embeddeddoc.wiki
	@@ -41,12 +41,12 @@
41	<b>http://www.hwaci.com/cgi-bin/fossil</b>.
42	If you launch the web server using the "<b>fossil server</b>" command line,
43	then the <i><baseurl></i> is usually
44	<b>http://localhost:8080/</b>.
45
46	The <i><version></i> is any unique UUID prefix of the baseline
47	for the documentation you want to access.
48	Or <i><version></i> can be one of the keywords "<b>tip</b>" or
49	"<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently
50	checked-in baseline. This is useful if you want to see the very latest
51	version of the documentation. The "<b>ckout</b>" keywords means to
52	pull the documentation file from the local source tree on disk, not
53

	--- www/embeddeddoc.wiki
	+++ www/embeddeddoc.wiki
	@@ -41,12 +41,12 @@
41	<b>http://www.hwaci.com/cgi-bin/fossil</b>.
42	If you launch the web server using the "<b>fossil server</b>" command line,
43	then the <i><baseurl></i> is usually
44	<b>http://localhost:8080/</b>.
45
46	The <i><version></i> is any unique prefix of the baseline ID for
47	the baseline containing the documentation you want to access.
48	Or <i><version></i> can be one of the keywords "<b>tip</b>" or
49	"<b>ckout</b>". The "<b>tip</b>" keyword means to use the most recently
50	checked-in baseline. This is useful if you want to see the very latest
51	version of the documentation. The "<b>ckout</b>" keywords means to
52	pull the documentation file from the local source tree on disk, not
53

M www/fileformat.wiki

+7 -7

		--- www/fileformat.wiki
		+++ www/fileformat.wiki
		@@ -225,17 +225,17 @@
225	225	<p>
226	226	Allowed cards in the cluster are as follows:
227	227	</p>
228	228
229	229	<blockquote>
230		-<b>M</b> <i>uuid</i><br />
	230	+<b>M</b> <i>artifact-id</i><br />
231	231	<b>Z</b> <i>checksum</i>
232	232	</blockquote>
233	233
234	234	<p>
235	235	A cluster contains one or more "M" cards followed by a single "Z"
236		-line. Each M card has a single argument which is the UUID of
	236	+line. Each M card has a single argument which is the artifact ID of
237	237	another artifact in the repository. The Z card work exactly like
238	238	the Z card of a manifest. The argument to the Z card is the
239	239	lower-case hexadecimal representation of the MD5 checksum of all
240	240	prior cards in the cluster. Note that the Z card is required
241	241	on a cluster.
		@@ -258,11 +258,11 @@
258	258	Allowed cards in a control artifact are as follows:
259	259	</p>
260	260
261	261	<blockquote>
262	262	<b>D</b> <i>time-and-date-stamp</i><br />
263		-<b>T</b> (<b>+</b>\|<b>-</b>\|<b>*</b>)<i>tag-name uuid ?value?</i><br />
	263	+<b>T</b> (<b>+</b>\|<b>-</b>\|<b>*</b>)<i>tag-name artifact-id ?value?</i><br />
264	264	<b>Z</b> <i>checksum</i><br />
265	265	</blockquote>
266	266
267	267	<p>
268	268	A control artifact must have one D card and one Z card and
		@@ -273,11 +273,11 @@
273	273	<p>The D card and the Z card of a control artifact are the same
274	274	as in a manifest.</p>
275	275
276	276	<p>The T card represents a "tag" or property that is applied to
277	277	some other artifact. The T card has two or three values. The
278		-second argument is the 40 character lowercase UUID of the artifact
	278	+second argument is the 40 character lowercase artifact ID of the artifact
279	279	to which the tag is to be applied. The
280	280	first value is the tag name. The first character of the tag
281	281	is either "+", "-", or "*". A "+" means the tag should be added
282	282	to the artifact. The "-" means the tag should be removed.
283	283	The "*" character means the tag should be added to the artifact
		@@ -305,11 +305,11 @@
305	305	the following card types:</p>
306	306
307	307	<blockquote>
308	308	<b>D</b> <i>time-and-date-stamp</i><br />
309	309	<b>L</b> <i>wiki-title</i><br />
310		-<b>P</b> <i>parent-uuid</i>+<br />
	310	+<b>P</b> <i>parent-artifact-id</i>+<br />
311	311	<b>U</b> <i>user-name</i><br />
312	312	<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
313	313	<b>Z</b> <i>checksum</i>
314	314	</blockquote>
315	315
		@@ -332,11 +332,11 @@
332	332	The following cards are allowed on a ticket change artifact:</p>
333	333
334	334	<blockquote>
335	335	<b>D</b> <i>time-and-date-stamp</i><br />
336	336	<b>J</b> ?<b>+</b>?<i>name value</i><br />
337		-<b>K</b> <i>ticket-uuid</i><br />
	337	+<b>K</b> <i>ticket-id</i><br />
338	338	<b>U</b> <i>user-name</i><br />
339	339	<b>Z</b> <i>checksum</i>
340	340	</blockquote>
341	341
342	342	<p>
		@@ -344,11 +344,11 @@
344	344	in time when the change was entered. The U card is the login of the
345	345	programmer who entered this change. The Z card is the checksum over
346	346	the entire artifact.</p>
347	347
348	348	<p>
349		-Every ticket has a UUID. The ticket to which this change is applied
	349	+Every ticket has a unique ID. The ticket to which this change is applied
350	350	is specified by the K card. A ticket exists if it contains one or
351	351	more changes. The first "change" to a ticket is what brings the
352	352	ticket into existance.</p>
353	353
354	354	<p>
355	355

	--- www/fileformat.wiki
	+++ www/fileformat.wiki
	@@ -225,17 +225,17 @@
225	<p>
226	Allowed cards in the cluster are as follows:
227	</p>
228
229	<blockquote>
230	<b>M</b> <i>uuid</i><br />
231	<b>Z</b> <i>checksum</i>
232	</blockquote>
233
234	<p>
235	A cluster contains one or more "M" cards followed by a single "Z"
236	line. Each M card has a single argument which is the UUID of
237	another artifact in the repository. The Z card work exactly like
238	the Z card of a manifest. The argument to the Z card is the
239	lower-case hexadecimal representation of the MD5 checksum of all
240	prior cards in the cluster. Note that the Z card is required
241	on a cluster.
	@@ -258,11 +258,11 @@
258	Allowed cards in a control artifact are as follows:
259	</p>
260
261	<blockquote>
262	<b>D</b> <i>time-and-date-stamp</i><br />
263	<b>T</b> (<b>+</b>\|<b>-</b>\|<b>*</b>)<i>tag-name uuid ?value?</i><br />
264	<b>Z</b> <i>checksum</i><br />
265	</blockquote>
266
267	<p>
268	A control artifact must have one D card and one Z card and
	@@ -273,11 +273,11 @@
273	<p>The D card and the Z card of a control artifact are the same
274	as in a manifest.</p>
275
276	<p>The T card represents a "tag" or property that is applied to
277	some other artifact. The T card has two or three values. The
278	second argument is the 40 character lowercase UUID of the artifact
279	to which the tag is to be applied. The
280	first value is the tag name. The first character of the tag
281	is either "+", "-", or "*". A "+" means the tag should be added
282	to the artifact. The "-" means the tag should be removed.
283	The "*" character means the tag should be added to the artifact
	@@ -305,11 +305,11 @@
305	the following card types:</p>
306
307	<blockquote>
308	<b>D</b> <i>time-and-date-stamp</i><br />
309	<b>L</b> <i>wiki-title</i><br />
310	<b>P</b> <i>parent-uuid</i>+<br />
311	<b>U</b> <i>user-name</i><br />
312	<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
313	<b>Z</b> <i>checksum</i>
314	</blockquote>
315
	@@ -332,11 +332,11 @@
332	The following cards are allowed on a ticket change artifact:</p>
333
334	<blockquote>
335	<b>D</b> <i>time-and-date-stamp</i><br />
336	<b>J</b> ?<b>+</b>?<i>name value</i><br />
337	<b>K</b> <i>ticket-uuid</i><br />
338	<b>U</b> <i>user-name</i><br />
339	<b>Z</b> <i>checksum</i>
340	</blockquote>
341
342	<p>
	@@ -344,11 +344,11 @@
344	in time when the change was entered. The U card is the login of the
345	programmer who entered this change. The Z card is the checksum over
346	the entire artifact.</p>
347
348	<p>
349	Every ticket has a UUID. The ticket to which this change is applied
350	is specified by the K card. A ticket exists if it contains one or
351	more changes. The first "change" to a ticket is what brings the
352	ticket into existance.</p>
353
354	<p>
355

	--- www/fileformat.wiki
	+++ www/fileformat.wiki
	@@ -225,17 +225,17 @@
225	<p>
226	Allowed cards in the cluster are as follows:
227	</p>
228
229	<blockquote>
230	<b>M</b> <i>artifact-id</i><br />
231	<b>Z</b> <i>checksum</i>
232	</blockquote>
233
234	<p>
235	A cluster contains one or more "M" cards followed by a single "Z"
236	line. Each M card has a single argument which is the artifact ID of
237	another artifact in the repository. The Z card work exactly like
238	the Z card of a manifest. The argument to the Z card is the
239	lower-case hexadecimal representation of the MD5 checksum of all
240	prior cards in the cluster. Note that the Z card is required
241	on a cluster.
	@@ -258,11 +258,11 @@
258	Allowed cards in a control artifact are as follows:
259	</p>
260
261	<blockquote>
262	<b>D</b> <i>time-and-date-stamp</i><br />
263	<b>T</b> (<b>+</b>\|<b>-</b>\|<b>*</b>)<i>tag-name artifact-id ?value?</i><br />
264	<b>Z</b> <i>checksum</i><br />
265	</blockquote>
266
267	<p>
268	A control artifact must have one D card and one Z card and
	@@ -273,11 +273,11 @@
273	<p>The D card and the Z card of a control artifact are the same
274	as in a manifest.</p>
275
276	<p>The T card represents a "tag" or property that is applied to
277	some other artifact. The T card has two or three values. The
278	second argument is the 40 character lowercase artifact ID of the artifact
279	to which the tag is to be applied. The
280	first value is the tag name. The first character of the tag
281	is either "+", "-", or "*". A "+" means the tag should be added
282	to the artifact. The "-" means the tag should be removed.
283	The "*" character means the tag should be added to the artifact
	@@ -305,11 +305,11 @@
305	the following card types:</p>
306
307	<blockquote>
308	<b>D</b> <i>time-and-date-stamp</i><br />
309	<b>L</b> <i>wiki-title</i><br />
310	<b>P</b> <i>parent-artifact-id</i>+<br />
311	<b>U</b> <i>user-name</i><br />
312	<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
313	<b>Z</b> <i>checksum</i>
314	</blockquote>
315
	@@ -332,11 +332,11 @@
332	The following cards are allowed on a ticket change artifact:</p>
333
334	<blockquote>
335	<b>D</b> <i>time-and-date-stamp</i><br />
336	<b>J</b> ?<b>+</b>?<i>name value</i><br />
337	<b>K</b> <i>ticket-id</i><br />
338	<b>U</b> <i>user-name</i><br />
339	<b>Z</b> <i>checksum</i>
340	</blockquote>
341
342	<p>
	@@ -344,11 +344,11 @@
344	in time when the change was entered. The U card is the login of the
345	programmer who entered this change. The Z card is the checksum over
346	the entire artifact.</p>
347
348	<p>
349	Every ticket has a unique ID. The ticket to which this change is applied
350	is specified by the K card. A ticket exists if it contains one or
351	more changes. The first "change" to a ticket is what brings the
352	ticket into existance.</p>
353
354	<p>
355

M www/quickstart.wiki

+6 -5

		--- www/quickstart.wiki
		+++ www/quickstart.wiki
		@@ -159,28 +159,29 @@
159	159	<p>When you pull in changes from others, they go into your repository,
160	160	not into your checked-out local tree. To get the changes into your
161	161	local tree, use <b>update</b>:</p>
162	162
163	163	<blockquote>
164		- <b>fossil update</b> <i>UUID</i>
	164	+ <b>fossil update</b> <i>AID</i>
165	165	</blockquote>
166	166
167		- <p>The <i>UUID</i> is some unique abbreviation to the 40-character
168		- version ID. If you omit the <i>UUID</i> fossil moves you to the
	167	+ <p>The <i>AID</i> is some unique abbreviation to the 40-character
	168	+ artifact identifier (AID) for a particular baseline. If you omit
	169	+ the <i>AID</i> fossil moves you to the
169	170	leaf version of the branch your are currently on. If your branch
170	171	has multiple leaves, you get an error - you'll have to specify the
171		- leaf you want using a <i>UUID</i> argument.</p>
	172	+ leaf you want using a <i>AID</i> argument.</p>
172	173
173	174	</blockquote><h2>Branching And Merging</h2><blockquote>
174	175
175	176	<p>You can create branches by doing multiple commits off of the
176	177	same base version. To merge to branches back together, first
177	178	<b>update</b> to the leaf of one branch. Then do a <b>merge</b>
178	179	of the leaf of the other branch:</p>
179	180
180	181	<blockquote>
181		- <b>fossil merge</b> <i>UUID</i>
	182	+ <b>fossil merge</b> <i>AID</i>
182	183	</blockquote>
183	184
184	185	<p>Test to make sure your merge didn't mess up the code, then
185	186	<b>commit</b> and possibly also <b>push</b> your changes. Remember
186	187	that nobody else can see your changes until you <b>commit</b> and
187	188

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -159,28 +159,29 @@
159	<p>When you pull in changes from others, they go into your repository,
160	not into your checked-out local tree. To get the changes into your
161	local tree, use <b>update</b>:</p>
162
163	<blockquote>
164	<b>fossil update</b> <i>UUID</i>
165	</blockquote>
166
167	<p>The <i>UUID</i> is some unique abbreviation to the 40-character
168	version ID. If you omit the <i>UUID</i> fossil moves you to the

169	leaf version of the branch your are currently on. If your branch
170	has multiple leaves, you get an error - you'll have to specify the
171	leaf you want using a <i>UUID</i> argument.</p>
172
173	</blockquote><h2>Branching And Merging</h2><blockquote>
174
175	<p>You can create branches by doing multiple commits off of the
176	same base version. To merge to branches back together, first
177	<b>update</b> to the leaf of one branch. Then do a <b>merge</b>
178	of the leaf of the other branch:</p>
179
180	<blockquote>
181	<b>fossil merge</b> <i>UUID</i>
182	</blockquote>
183
184	<p>Test to make sure your merge didn't mess up the code, then
185	<b>commit</b> and possibly also <b>push</b> your changes. Remember
186	that nobody else can see your changes until you <b>commit</b> and
187

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -159,28 +159,29 @@
159	<p>When you pull in changes from others, they go into your repository,
160	not into your checked-out local tree. To get the changes into your
161	local tree, use <b>update</b>:</p>
162
163	<blockquote>
164	<b>fossil update</b> <i>AID</i>
165	</blockquote>
166
167	<p>The <i>AID</i> is some unique abbreviation to the 40-character
168	artifact identifier (AID) for a particular baseline. If you omit
169	the <i>AID</i> fossil moves you to the
170	leaf version of the branch your are currently on. If your branch
171	has multiple leaves, you get an error - you'll have to specify the
172	leaf you want using a <i>AID</i> argument.</p>
173
174	</blockquote><h2>Branching And Merging</h2><blockquote>
175
176	<p>You can create branches by doing multiple commits off of the
177	same base version. To merge to branches back together, first
178	<b>update</b> to the leaf of one branch. Then do a <b>merge</b>
179	of the leaf of the other branch:</p>
180
181	<blockquote>
182	<b>fossil merge</b> <i>AID</i>
183	</blockquote>
184
185	<p>Test to make sure your merge didn't mess up the code, then
186	<b>commit</b> and possibly also <b>push</b> your changes. Remember
187	that nobody else can see your changes until you <b>commit</b> and
188

M www/sync.wiki

+60 -58

		--- www/sync.wiki
		+++ www/sync.wiki
		@@ -8,11 +8,12 @@
8	8	repositories.</p>
9	9
10	10	<h2>1.0 Overview</h2>
11	11
12	12	<p>The global state of a fossil repository consists of an unordered
13		-collection of artifacts. Each artifact is identified by its SHA1 hash.
	13	+collection of artifacts. Each artifact is identified by its SHA1 hash
	14	+expressed as a 40-character lower-case hexadecimal string.
14	15	Synchronization is simply the process of sharing artifacts between
15	16	servers so that all servers have copies of all artifacts. Because
16	17	artifacts are unordered, the order in which artifacts are received
17	18	at a server is inconsequential. It is assumed that the SHA1 hashes
18	19	of artifacts are unique - that every artifact has a different SHA1 hash.
		@@ -150,36 +151,37 @@
150	151	login cards. The session privileges are the bit-wise OR of the
151	152	privileges of each individual login.</p>
152	153
153	154	<h3>3.3 File Cards</h3>
154	155
155		-<p>Repository content records or files are transferred using
156		-a "file" card. File cards come in two different formats depending
157		-on whether the file is sent directly or as a delta from some
158		-other file.</p>
	156	+<p>Artifacts are transferred using "file" cards. (The name "file"
	157	+card comes from the fact that most artifacts correspond to files.)
	158	+File cards come in two different formats depending
	159	+on whether the artifact is sent directly or as a delta from some
	160	+other artifact.</p>
159	161
160	162	<blockquote>
161		-<b>file</b> <i>uuid size</i> <b>\n</b> <i>content</i><br>
162		-<b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
	163	+<b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i><br>
	164	+<b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i>
163	165	</blockquote>
164	166
165	167	<p>File cards are different from all other cards in that they
166		-followed by in-line "payload" data. The content of the file
167		-or the file delta consists of the first <i>size</i> bytes of the
	168	+followed by in-line "payload" data. The content of the artifact
	169	+or the artifact delta consists of the first <i>size</i> bytes of the
168	170	x-fossil content that immediately follow the newline that
169	171	terminates the file card. No other cards have this characteristic.
170	172	</p>
171	173
172		-<p>The first argument of a file card is the UUID of the file that
173		-is being transferred. The UUID is the lower-case hexadecimal
174		-representation of the SHA1 hash of the entire file content.
	174	+<p>The first argument of a file card is the ID of the artifact that
	175	+is being transferred. The artifact ID is the lower-case hexadecimal
	176	+representation of the SHA1 hash of the artifact.
175	177	The last argument of the file card is the number of bytes of
176	178	payload that immediately follow the file card. If the file
177	179	card has only two arguments, that means the payload is the
178		-complete content of the file. If the file card has three
	180	+complete content of the artifact. If the file card has three
179	181	arguments, then the payload is a delta and second argument is
180		-the UUID of another file that is the source of the delta.</p>
	182	+the ID of another artifact that is the source of the delta.</p>
181	183
182	184	<p>File cards are sent in both directions: client to server and
183	185	server to client. A delta might be sent before the source of
184	186	the delta, so both client and server should remember deltas
185	187	and be able to apply them when their source arrives.</p>
		@@ -226,33 +228,33 @@
226	228
227	229	<h3>3.6 Igot Cards</h3>
228	230
229	231	<p>An igot card can be sent from either client to server or from
230	232	server to client in order to indicate that the sender holds a copy
231		-of a particular file. The format is:</p>
	233	+of a particular artifact. The format is:</p>
232	234
233	235	<blockquote>
234		-<b>igot</b> <i>uuid</i>
	236	+<b>igot</b> <i>artifact-id</i>
235	237	</blockquote>
236	238
237		-<p>The argument of the igot card is the UUID of the file that
	239	+<p>The argument of the igot card is the ID of the artifact that
238	240	the sender possesses.
239	241	The receiver of an igot card will typically check to see if
240		-it also holds the same file and if not it will request the file
	242	+it also holds the same artifact and if not it will request the artifact
241	243	using a gimme card in either the reply or in the next message.</p>
242	244
243	245	<h3>3.7 Gimme Cards</h3>
244	246
245	247	<p>A gimme card is sent from either client to server or from server
246	248	to client. The gimme card asks the receiver to send a particular
247		-file back to the sender. The format of a gimme card is this:</p>
	249	+artifact back to the sender. The format of a gimme card is this:</p>
248	250
249	251	<blockquote>
250		-<b>gimme</b> <i>uuid</i>
	252	+<b>gimme</b> <i>artifact-id</i>
251	253	</blockquote>
252	254
253		-<p>The argument to the gimme card is the UUID of the file that
	255	+<p>The argument to the gimme card is the ID of the artifact that
254	256	the sender wants. The receiver will typically respond to a
255	257	gimme card by sending a file card in its reply or in the next
256	258	message.</p>
257	259
258	260	<h3>3.8 Cookie Cards</h3>
		@@ -300,53 +302,53 @@
300	302	<p>If either the client or the server sees a card that is not
301	303	described above, then it generates an error and aborts.</p>
302	304
303	305	<h2>4.0 Phantoms And Clusters</h2>
304	306
305		-<p>When a repository knows that a file exists and knows the UUID of
306		-that file, but it does not know the file content, then it stores that
307		-file as a "phantom". A repository will typically create a phantom when
308		-it receives an igot card for a file that it does not hold or when it
	307	+<p>When a repository knows that a artifact exists and knows the ID of
	308	+that artifact, but it does not know the artifact content, then it stores that
	309	+artifact as a "phantom". A repository will typically create a phantom when
	310	+it receives an igot card for a artifact that it does not hold or when it
309	311	receives a file card that references a delta source that it does not
310	312	hold. When a server is generating its reply or when a client is
311	313	generating a new request, it will usually send gimme cards for every
312	314	phantom that it holds.</p>
313	315
314		-<p>A cluster is a special file that tells of the existence of other
315		-files. Any file in the repository that follows the syntactic rules
	316	+<p>A cluster is a special artifact that tells of the existence of other
	317	+artifacts. Any artifact in the repository that follows the syntactic rules
316	318	of a cluster is considered a cluster.</p>
317	319
318		-<p>A cluster is a line oriented file. Each line of a cluster
	320	+<p>A cluster is line oriented. Each line of a cluster
319	321	is a card. The cards are separated by the newline ("\n") character.
320	322	Each card consists of a single character card type, a space, and a
321	323	single argument. No extra whitespace and no trailing or leading
322	324	whitespace is allowed. All cards in the cluster must occur in
323	325	strict lexicographical order.</p>
324	326
325	327	<p>A cluster consists of one or more "M" cards followed by a single
326		-"Z" card. Each M card holds an argument which is a UUID for a file
327		-in the repository. The Z card has a single argument which is the
	328	+"Z" card. Each M card holds an argument which is a artifact ID for an
	329	+artifact in the repository. The Z card has a single argument which is the
328	330	lower-case hexadecimal representation of the MD5 checksum of all
329	331	preceding M cards up to and included the newline character that
330	332	occurred just before the Z that starts the Z card.</p>
331	333
332		-<p>Any file that does not match the specifications of a cluster
	334	+<p>Any artifact that does not match the specifications of a cluster
333	335	exactly is not a cluster. There must be no extra whitespace in
334		-the file. There must be one or more M cards. There must be a
	336	+the artifact. There must be one or more M cards. There must be a
335	337	single Z card with a correct MD5 checksum. And all cards must
336	338	be in strict lexicographical order.</p>
337	339
338	340	<h3>4.1 The Unclustered Table</h3>
339	341
340	342	<p>Every repository maintains a table named "<b>unclustered</b>"
341		-which records the identity of every file and phantom it holds that is not
	343	+which records the identity of every artifact and phantom it holds that is not
342	344	mentioned in a cluster. The entries in the unclustered table can
343		-be thought of as leaves on a tree of files. Some of the unclustered
344		-files will be clusters. Those clusters may contain other clusters,
	345	+be thought of as leaves on a tree of artifacts. Some of the unclustered
	346	+artifacts will be other clusters. Those clusters may contain other clusters,
345	347	which might contain still more clusters, and so forth. Beginning
346		-with the files in the unclustered table, one can follow the chain
347		-of clusters to find every file in the repository.</p>
	348	+with the artifacts in the unclustered table, one can follow the chain
	349	+of clusters to find every artifact in the repository.</p>
348	350
349	351	<h2>5.0 Synchronization Strategies</h2>
350	352
351	353	<h3>5.1 Pull</h3>
352	354
		@@ -360,22 +362,22 @@
360	362	<li>The client sends gimme cards for every phantom that it holds.
361	363	<hr>
362	364	<li>The server checks the login password and rejects the session if
363	365	the user does not have permission to pull.
364	366	<li>If the number entries in the unclustered table on the server is
365		-greater than 100, then the server constructs a new cluster file to
	367	+greater than 100, then the server constructs a new cluster artifact to
366	368	cover all those unclustered entries.
367	369	<li>The server sends file cards for every gimme card it received
368	370	from the client.
369		-<li>The server sends ihave cards for every file in its unclustered
	371	+<li>The server sends ihave cards for every artifact in its unclustered
370	372	table that is not a phantom.
371	373	<hr>
372	374	<li>The client adds the content of file cards to its repository.
373	375	<li>The client creates a phantom for every ihave card in the server reply
374		-that mentions a file that the client does not possess.
	376	+that mentions an artifact that the client does not possess.
375	377	<li>The client creates a phantom for the delta source of file cards when
376		-the delta source is a file that the client does not possess.
	378	+the delta source is an artifact that the client does not possess.
377	379	</ol>
378	380
379	381	<p>These ten steps represent a single HTTP round-trip request.
380	382	The first three steps are the processing that occurs on the client
381	383	to generate the request. The middle four steps are processing
		@@ -382,11 +384,11 @@
382	384	that occurs on the server to interpret the request and generate a
383	385	reply. And the last three steps are the processing that the
384	386	client does to interpret the reply.</p>
385	387
386	388	<p>During a pull, the client will keep sending HTTP requests
387		-until it holds all files that exist on the server.</p>
	389	+until it holds all artifacts that exist on the server.</p>
388	390
389	391	<p>Note that the server tries
390	392	to limit the size of its reply message to something reasonable
391	393	(usually about 1MB) so that it might stop sending file cards as
392	394	described in step (6) if the reply becomes too large.</p>
		@@ -405,33 +407,33 @@
405	407	<p>A typical push operation proceeds roughly as shown below. As
406	408	with a pull, the actual implementation may vary slightly.</p>
407	409
408	410	<ol>
409	411	<li>The client sends login and push cards.
410		-<li>The client sends file cards for any files that it holds that have
411		-never before been pushed - files that come from local check-ins.
	412	+<li>The client sends file cards for any artifacts that it holds that have
	413	+never before been pushed - artifacts that come from local check-ins.
412	414	<li>If this is the second or later cycle in a push, then the
413	415	client sends file cards for any gimme cards that the server sent
414	416	in the previous cycle.
415		-<li>The client sends igot cards for every file in its unclustered table
	417	+<li>The client sends igot cards for every artifact in its unclustered table
416	418	that is not a phantom.
417	419	<hr>
418	420	<li>The server checks the login and push cards and issues an error if
419	421	anything is amiss.
420		-<li>The server accepts file cards from the client and adds those files
	422	+<li>The server accepts file cards from the client and adds those artifacts
421	423	to its repository.
422		-<li>The server creates phantoms for igot cards that mention files it
423		-does not possess or for file cards that mention delta source files that
	424	+<li>The server creates phantoms for igot cards that mention artifacts it
	425	+does not possess or for file cards that mention delta source artifacts that
424	426	it does not possess.
425	427	<li>The server issues gimme cards for all phantoms.
426	428	<hr>
427	429	<li>The client remembers the gimme cards from the server so that it
428	430	can generate file cards in reply on the next cycle.
429	431	</ol>
430	432
431	433	<p>As with a pull, the steps of a push operation repeat until the
432		-server knows all files that exist on the client. Also, as with
	434	+server knows all artifacts that exist on the client. Also, as with
433	435	pull, the client attempts to keep the size of the request from
434	436	growing too large by suppressing file cards once the
435	437	size of the request reaches 1MB.</p>
436	438
437	439	<h3>5.3 Sync</h3>
		@@ -456,20 +458,20 @@
456	458	<ul>
457	459	<li> <b>login</b> <i>userid nonce signature</i>
458	460	<li> <b>push</b> <i>servercode projectcode</i>
459	461	<li> <b>pull</b> <i>servercode projectcode</i>
460	462	<li> <b>clone</b>
461		- <li> <b>file</b> <i>uuid size</i> <b>\n</b> <i>content</i>
462		- <li> <b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
463		- <li> <b>igot</b> <i>uuid</i>
464		- <li> <b>gimme</b> <i>uuid</i>
	463	+ <li> <b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i>
	464	+ <li> <b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i>
	465	+ <li> <b>igot</b> <i>artifact-id</i>
	466	+ <li> <b>gimme</b> <i>artifact-id</i>
465	467	<li> <b>cookie</b> <i>cookie-text</i>
466	468	<li> <b>error</b> <i>error-message</i>
467	469	</ul>
468		-<li>Phantoms are files that a repository knows exist but does not possess.
469		-<li>Clusters are files that contain the UUIDs of other files.
	470	+<li>Phantoms are artifacts that a repository knows exist but does not possess.
	471	+<li>Clusters are artifacts that contain IDs of other artifacts.
470	472	<li>Clusters are created automatically on the server during a pull.
471		-<li>Repositories keep track of all files that are not named in any
472		-cluster and send igot messages for those files.
	473	+<li>Repositories keep track of all artifacts that are not named in any
	474	+cluster and send igot messages for those artifacts.
473	475	<li>Repositories keep track of all the phantoms they hold and send
474		-gimme messages for those files.
	476	+gimme messages for those artifacts.
475	477	</ol>
476	478

	--- www/sync.wiki
	+++ www/sync.wiki
	@@ -8,11 +8,12 @@
8	repositories.</p>
9
10	<h2>1.0 Overview</h2>
11
12	<p>The global state of a fossil repository consists of an unordered
13	collection of artifacts. Each artifact is identified by its SHA1 hash.

14	Synchronization is simply the process of sharing artifacts between
15	servers so that all servers have copies of all artifacts. Because
16	artifacts are unordered, the order in which artifacts are received
17	at a server is inconsequential. It is assumed that the SHA1 hashes
18	of artifacts are unique - that every artifact has a different SHA1 hash.
	@@ -150,36 +151,37 @@
150	login cards. The session privileges are the bit-wise OR of the
151	privileges of each individual login.</p>
152
153	<h3>3.3 File Cards</h3>
154
155	<p>Repository content records or files are transferred using
156	a "file" card. File cards come in two different formats depending
157	on whether the file is sent directly or as a delta from some
158	other file.</p>

159
160	<blockquote>
161	<b>file</b> <i>uuid size</i> <b>\n</b> <i>content</i><br>
162	<b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
163	</blockquote>
164
165	<p>File cards are different from all other cards in that they
166	followed by in-line "payload" data. The content of the file
167	or the file delta consists of the first <i>size</i> bytes of the
168	x-fossil content that immediately follow the newline that
169	terminates the file card. No other cards have this characteristic.
170	</p>
171
172	<p>The first argument of a file card is the UUID of the file that
173	is being transferred. The UUID is the lower-case hexadecimal
174	representation of the SHA1 hash of the entire file content.
175	The last argument of the file card is the number of bytes of
176	payload that immediately follow the file card. If the file
177	card has only two arguments, that means the payload is the
178	complete content of the file. If the file card has three
179	arguments, then the payload is a delta and second argument is
180	the UUID of another file that is the source of the delta.</p>
181
182	<p>File cards are sent in both directions: client to server and
183	server to client. A delta might be sent before the source of
184	the delta, so both client and server should remember deltas
185	and be able to apply them when their source arrives.</p>
	@@ -226,33 +228,33 @@
226
227	<h3>3.6 Igot Cards</h3>
228
229	<p>An igot card can be sent from either client to server or from
230	server to client in order to indicate that the sender holds a copy
231	of a particular file. The format is:</p>
232
233	<blockquote>
234	<b>igot</b> <i>uuid</i>
235	</blockquote>
236
237	<p>The argument of the igot card is the UUID of the file that
238	the sender possesses.
239	The receiver of an igot card will typically check to see if
240	it also holds the same file and if not it will request the file
241	using a gimme card in either the reply or in the next message.</p>
242
243	<h3>3.7 Gimme Cards</h3>
244
245	<p>A gimme card is sent from either client to server or from server
246	to client. The gimme card asks the receiver to send a particular
247	file back to the sender. The format of a gimme card is this:</p>
248
249	<blockquote>
250	<b>gimme</b> <i>uuid</i>
251	</blockquote>
252
253	<p>The argument to the gimme card is the UUID of the file that
254	the sender wants. The receiver will typically respond to a
255	gimme card by sending a file card in its reply or in the next
256	message.</p>
257
258	<h3>3.8 Cookie Cards</h3>
	@@ -300,53 +302,53 @@
300	<p>If either the client or the server sees a card that is not
301	described above, then it generates an error and aborts.</p>
302
303	<h2>4.0 Phantoms And Clusters</h2>
304
305	<p>When a repository knows that a file exists and knows the UUID of
306	that file, but it does not know the file content, then it stores that
307	file as a "phantom". A repository will typically create a phantom when
308	it receives an igot card for a file that it does not hold or when it
309	receives a file card that references a delta source that it does not
310	hold. When a server is generating its reply or when a client is
311	generating a new request, it will usually send gimme cards for every
312	phantom that it holds.</p>
313
314	<p>A cluster is a special file that tells of the existence of other
315	files. Any file in the repository that follows the syntactic rules
316	of a cluster is considered a cluster.</p>
317
318	<p>A cluster is a line oriented file. Each line of a cluster
319	is a card. The cards are separated by the newline ("\n") character.
320	Each card consists of a single character card type, a space, and a
321	single argument. No extra whitespace and no trailing or leading
322	whitespace is allowed. All cards in the cluster must occur in
323	strict lexicographical order.</p>
324
325	<p>A cluster consists of one or more "M" cards followed by a single
326	"Z" card. Each M card holds an argument which is a UUID for a file
327	in the repository. The Z card has a single argument which is the
328	lower-case hexadecimal representation of the MD5 checksum of all
329	preceding M cards up to and included the newline character that
330	occurred just before the Z that starts the Z card.</p>
331
332	<p>Any file that does not match the specifications of a cluster
333	exactly is not a cluster. There must be no extra whitespace in
334	the file. There must be one or more M cards. There must be a
335	single Z card with a correct MD5 checksum. And all cards must
336	be in strict lexicographical order.</p>
337
338	<h3>4.1 The Unclustered Table</h3>
339
340	<p>Every repository maintains a table named "<b>unclustered</b>"
341	which records the identity of every file and phantom it holds that is not
342	mentioned in a cluster. The entries in the unclustered table can
343	be thought of as leaves on a tree of files. Some of the unclustered
344	files will be clusters. Those clusters may contain other clusters,
345	which might contain still more clusters, and so forth. Beginning
346	with the files in the unclustered table, one can follow the chain
347	of clusters to find every file in the repository.</p>
348
349	<h2>5.0 Synchronization Strategies</h2>
350
351	<h3>5.1 Pull</h3>
352
	@@ -360,22 +362,22 @@
360	<li>The client sends gimme cards for every phantom that it holds.
361	<hr>
362	<li>The server checks the login password and rejects the session if
363	the user does not have permission to pull.
364	<li>If the number entries in the unclustered table on the server is
365	greater than 100, then the server constructs a new cluster file to
366	cover all those unclustered entries.
367	<li>The server sends file cards for every gimme card it received
368	from the client.
369	<li>The server sends ihave cards for every file in its unclustered
370	table that is not a phantom.
371	<hr>
372	<li>The client adds the content of file cards to its repository.
373	<li>The client creates a phantom for every ihave card in the server reply
374	that mentions a file that the client does not possess.
375	<li>The client creates a phantom for the delta source of file cards when
376	the delta source is a file that the client does not possess.
377	</ol>
378
379	<p>These ten steps represent a single HTTP round-trip request.
380	The first three steps are the processing that occurs on the client
381	to generate the request. The middle four steps are processing
	@@ -382,11 +384,11 @@
382	that occurs on the server to interpret the request and generate a
383	reply. And the last three steps are the processing that the
384	client does to interpret the reply.</p>
385
386	<p>During a pull, the client will keep sending HTTP requests
387	until it holds all files that exist on the server.</p>
388
389	<p>Note that the server tries
390	to limit the size of its reply message to something reasonable
391	(usually about 1MB) so that it might stop sending file cards as
392	described in step (6) if the reply becomes too large.</p>
	@@ -405,33 +407,33 @@
405	<p>A typical push operation proceeds roughly as shown below. As
406	with a pull, the actual implementation may vary slightly.</p>
407
408	<ol>
409	<li>The client sends login and push cards.
410	<li>The client sends file cards for any files that it holds that have
411	never before been pushed - files that come from local check-ins.
412	<li>If this is the second or later cycle in a push, then the
413	client sends file cards for any gimme cards that the server sent
414	in the previous cycle.
415	<li>The client sends igot cards for every file in its unclustered table
416	that is not a phantom.
417	<hr>
418	<li>The server checks the login and push cards and issues an error if
419	anything is amiss.
420	<li>The server accepts file cards from the client and adds those files
421	to its repository.
422	<li>The server creates phantoms for igot cards that mention files it
423	does not possess or for file cards that mention delta source files that
424	it does not possess.
425	<li>The server issues gimme cards for all phantoms.
426	<hr>
427	<li>The client remembers the gimme cards from the server so that it
428	can generate file cards in reply on the next cycle.
429	</ol>
430
431	<p>As with a pull, the steps of a push operation repeat until the
432	server knows all files that exist on the client. Also, as with
433	pull, the client attempts to keep the size of the request from
434	growing too large by suppressing file cards once the
435	size of the request reaches 1MB.</p>
436
437	<h3>5.3 Sync</h3>
	@@ -456,20 +458,20 @@
456	<ul>
457	<li> <b>login</b> <i>userid nonce signature</i>
458	<li> <b>push</b> <i>servercode projectcode</i>
459	<li> <b>pull</b> <i>servercode projectcode</i>
460	<li> <b>clone</b>
461	<li> <b>file</b> <i>uuid size</i> <b>\n</b> <i>content</i>
462	<li> <b>file</b> <i>uuid delta-uuid size</i> <b>\n</b> <i>content</i>
463	<li> <b>igot</b> <i>uuid</i>
464	<li> <b>gimme</b> <i>uuid</i>
465	<li> <b>cookie</b> <i>cookie-text</i>
466	<li> <b>error</b> <i>error-message</i>
467	</ul>
468	<li>Phantoms are files that a repository knows exist but does not possess.
469	<li>Clusters are files that contain the UUIDs of other files.
470	<li>Clusters are created automatically on the server during a pull.
471	<li>Repositories keep track of all files that are not named in any
472	cluster and send igot messages for those files.
473	<li>Repositories keep track of all the phantoms they hold and send
474	gimme messages for those files.
475	</ol>
476

	--- www/sync.wiki
	+++ www/sync.wiki
	@@ -8,11 +8,12 @@
8	repositories.</p>
9
10	<h2>1.0 Overview</h2>
11
12	<p>The global state of a fossil repository consists of an unordered
13	collection of artifacts. Each artifact is identified by its SHA1 hash
14	expressed as a 40-character lower-case hexadecimal string.
15	Synchronization is simply the process of sharing artifacts between
16	servers so that all servers have copies of all artifacts. Because
17	artifacts are unordered, the order in which artifacts are received
18	at a server is inconsequential. It is assumed that the SHA1 hashes
19	of artifacts are unique - that every artifact has a different SHA1 hash.
	@@ -150,36 +151,37 @@
151	login cards. The session privileges are the bit-wise OR of the
152	privileges of each individual login.</p>
153
154	<h3>3.3 File Cards</h3>
155
156	<p>Artifacts are transferred using "file" cards. (The name "file"
157	card comes from the fact that most artifacts correspond to files.)
158	File cards come in two different formats depending
159	on whether the artifact is sent directly or as a delta from some
160	other artifact.</p>
161
162	<blockquote>
163	<b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i><br>
164	<b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i>
165	</blockquote>
166
167	<p>File cards are different from all other cards in that they
168	followed by in-line "payload" data. The content of the artifact
169	or the artifact delta consists of the first <i>size</i> bytes of the
170	x-fossil content that immediately follow the newline that
171	terminates the file card. No other cards have this characteristic.
172	</p>
173
174	<p>The first argument of a file card is the ID of the artifact that
175	is being transferred. The artifact ID is the lower-case hexadecimal
176	representation of the SHA1 hash of the artifact.
177	The last argument of the file card is the number of bytes of
178	payload that immediately follow the file card. If the file
179	card has only two arguments, that means the payload is the
180	complete content of the artifact. If the file card has three
181	arguments, then the payload is a delta and second argument is
182	the ID of another artifact that is the source of the delta.</p>
183
184	<p>File cards are sent in both directions: client to server and
185	server to client. A delta might be sent before the source of
186	the delta, so both client and server should remember deltas
187	and be able to apply them when their source arrives.</p>
	@@ -226,33 +228,33 @@
228
229	<h3>3.6 Igot Cards</h3>
230
231	<p>An igot card can be sent from either client to server or from
232	server to client in order to indicate that the sender holds a copy
233	of a particular artifact. The format is:</p>
234
235	<blockquote>
236	<b>igot</b> <i>artifact-id</i>
237	</blockquote>
238
239	<p>The argument of the igot card is the ID of the artifact that
240	the sender possesses.
241	The receiver of an igot card will typically check to see if
242	it also holds the same artifact and if not it will request the artifact
243	using a gimme card in either the reply or in the next message.</p>
244
245	<h3>3.7 Gimme Cards</h3>
246
247	<p>A gimme card is sent from either client to server or from server
248	to client. The gimme card asks the receiver to send a particular
249	artifact back to the sender. The format of a gimme card is this:</p>
250
251	<blockquote>
252	<b>gimme</b> <i>artifact-id</i>
253	</blockquote>
254
255	<p>The argument to the gimme card is the ID of the artifact that
256	the sender wants. The receiver will typically respond to a
257	gimme card by sending a file card in its reply or in the next
258	message.</p>
259
260	<h3>3.8 Cookie Cards</h3>
	@@ -300,53 +302,53 @@
302	<p>If either the client or the server sees a card that is not
303	described above, then it generates an error and aborts.</p>
304
305	<h2>4.0 Phantoms And Clusters</h2>
306
307	<p>When a repository knows that a artifact exists and knows the ID of
308	that artifact, but it does not know the artifact content, then it stores that
309	artifact as a "phantom". A repository will typically create a phantom when
310	it receives an igot card for a artifact that it does not hold or when it
311	receives a file card that references a delta source that it does not
312	hold. When a server is generating its reply or when a client is
313	generating a new request, it will usually send gimme cards for every
314	phantom that it holds.</p>
315
316	<p>A cluster is a special artifact that tells of the existence of other
317	artifacts. Any artifact in the repository that follows the syntactic rules
318	of a cluster is considered a cluster.</p>
319
320	<p>A cluster is line oriented. Each line of a cluster
321	is a card. The cards are separated by the newline ("\n") character.
322	Each card consists of a single character card type, a space, and a
323	single argument. No extra whitespace and no trailing or leading
324	whitespace is allowed. All cards in the cluster must occur in
325	strict lexicographical order.</p>
326
327	<p>A cluster consists of one or more "M" cards followed by a single
328	"Z" card. Each M card holds an argument which is a artifact ID for an
329	artifact in the repository. The Z card has a single argument which is the
330	lower-case hexadecimal representation of the MD5 checksum of all
331	preceding M cards up to and included the newline character that
332	occurred just before the Z that starts the Z card.</p>
333
334	<p>Any artifact that does not match the specifications of a cluster
335	exactly is not a cluster. There must be no extra whitespace in
336	the artifact. There must be one or more M cards. There must be a
337	single Z card with a correct MD5 checksum. And all cards must
338	be in strict lexicographical order.</p>
339
340	<h3>4.1 The Unclustered Table</h3>
341
342	<p>Every repository maintains a table named "<b>unclustered</b>"
343	which records the identity of every artifact and phantom it holds that is not
344	mentioned in a cluster. The entries in the unclustered table can
345	be thought of as leaves on a tree of artifacts. Some of the unclustered
346	artifacts will be other clusters. Those clusters may contain other clusters,
347	which might contain still more clusters, and so forth. Beginning
348	with the artifacts in the unclustered table, one can follow the chain
349	of clusters to find every artifact in the repository.</p>
350
351	<h2>5.0 Synchronization Strategies</h2>
352
353	<h3>5.1 Pull</h3>
354
	@@ -360,22 +362,22 @@
362	<li>The client sends gimme cards for every phantom that it holds.
363	<hr>
364	<li>The server checks the login password and rejects the session if
365	the user does not have permission to pull.
366	<li>If the number entries in the unclustered table on the server is
367	greater than 100, then the server constructs a new cluster artifact to
368	cover all those unclustered entries.
369	<li>The server sends file cards for every gimme card it received
370	from the client.
371	<li>The server sends ihave cards for every artifact in its unclustered
372	table that is not a phantom.
373	<hr>
374	<li>The client adds the content of file cards to its repository.
375	<li>The client creates a phantom for every ihave card in the server reply
376	that mentions an artifact that the client does not possess.
377	<li>The client creates a phantom for the delta source of file cards when
378	the delta source is an artifact that the client does not possess.
379	</ol>
380
381	<p>These ten steps represent a single HTTP round-trip request.
382	The first three steps are the processing that occurs on the client
383	to generate the request. The middle four steps are processing
	@@ -382,11 +384,11 @@
384	that occurs on the server to interpret the request and generate a
385	reply. And the last three steps are the processing that the
386	client does to interpret the reply.</p>
387
388	<p>During a pull, the client will keep sending HTTP requests
389	until it holds all artifacts that exist on the server.</p>
390
391	<p>Note that the server tries
392	to limit the size of its reply message to something reasonable
393	(usually about 1MB) so that it might stop sending file cards as
394	described in step (6) if the reply becomes too large.</p>
	@@ -405,33 +407,33 @@
407	<p>A typical push operation proceeds roughly as shown below. As
408	with a pull, the actual implementation may vary slightly.</p>
409
410	<ol>
411	<li>The client sends login and push cards.
412	<li>The client sends file cards for any artifacts that it holds that have
413	never before been pushed - artifacts that come from local check-ins.
414	<li>If this is the second or later cycle in a push, then the
415	client sends file cards for any gimme cards that the server sent
416	in the previous cycle.
417	<li>The client sends igot cards for every artifact in its unclustered table
418	that is not a phantom.
419	<hr>
420	<li>The server checks the login and push cards and issues an error if
421	anything is amiss.
422	<li>The server accepts file cards from the client and adds those artifacts
423	to its repository.
424	<li>The server creates phantoms for igot cards that mention artifacts it
425	does not possess or for file cards that mention delta source artifacts that
426	it does not possess.
427	<li>The server issues gimme cards for all phantoms.
428	<hr>
429	<li>The client remembers the gimme cards from the server so that it
430	can generate file cards in reply on the next cycle.
431	</ol>
432
433	<p>As with a pull, the steps of a push operation repeat until the
434	server knows all artifacts that exist on the client. Also, as with
435	pull, the client attempts to keep the size of the request from
436	growing too large by suppressing file cards once the
437	size of the request reaches 1MB.</p>
438
439	<h3>5.3 Sync</h3>
	@@ -456,20 +458,20 @@
458	<ul>
459	<li> <b>login</b> <i>userid nonce signature</i>
460	<li> <b>push</b> <i>servercode projectcode</i>
461	<li> <b>pull</b> <i>servercode projectcode</i>
462	<li> <b>clone</b>
463	<li> <b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i>
464	<li> <b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i>
465	<li> <b>igot</b> <i>artifact-id</i>
466	<li> <b>gimme</b> <i>artifact-id</i>
467	<li> <b>cookie</b> <i>cookie-text</i>
468	<li> <b>error</b> <i>error-message</i>
469	</ul>
470	<li>Phantoms are artifacts that a repository knows exist but does not possess.
471	<li>Clusters are artifacts that contain IDs of other artifacts.
472	<li>Clusters are created automatically on the server during a pull.
473	<li>Repositories keep track of all artifacts that are not named in any
474	cluster and send igot messages for those artifacts.
475	<li>Repositories keep track of all the phantoms they hold and send
476	gimme messages for those artifacts.
477	</ol>
478

Fossil SCM

Keyboard Shortcuts