Fossil SCM

Documentation tweaks. Change the "Setup" menu title to "Admin". Added pages under Admin to view the RCVFROM table of the database.

drh 2009-01-25 19:18 trunk

Commit 766bec08cebeb858a874df71c4d6e3961e3a33e8

Parent c6646951861ae73…

7 files changed +17 -4 +3 -1 +111 -2 +1 -1 +11 -9 +2 -2 +1 -1

~ src/info.c ~ src/setup.c ~ src/shun.c ~ src/style.c ~ www/branching.wiki ~ www/newrepo.wiki ~ www/quickstart.wiki

M src/info.c

+17 -4

		--- src/info.c
		+++ src/info.c
		@@ -390,14 +390,30 @@
390	390	@ <tr><th>Original Comment:</th><td>%w(zComment)</td></tr>
391	391	}else{
392	392	@ <tr><th>Comment:</th><td>%w(zComment)</td></tr>
393	393	}
394	394	@ </td></tr>
	395	+ if( g.okAdmin ){
	396	+ db_prepare(&q,
	397	+ "SELECT rcvfrom.ipaddr, user.login, datetime(rcvfrom.mtime)"
	398	+ " FROM blob JOIN rcvfrom USING(rcvid) LEFT JOIN user USING(uid)"
	399	+ " WHERE blob.rid=%d",
	400	+ rid
	401	+ );
	402	+ if( db_step(&q)==SQLITE_ROW ){
	403	+ const char *zIpAddr = db_column_text(&q, 0);
	404	+ const char *zUser = db_column_text(&q, 1);
	405	+ const char *zDate = db_column_text(&q, 2);
	406	+ if( zUser==0 \|\| zUser[0]==0 ) zUser = "unknown";
	407	+ @ <tr><th>Received From:</th>
	408	+ @ <td>%h(zUser) @ %h(zIpAddr) on %s(zDate)</td></tr>
	409	+ }
	410	+ db_finalize(&q);
	411	+ }
395	412	if( g.okHistory ){
396	413	char *zShortUuid = mprintf("%.10s", zUuid);
397	414	const char *zProjName = db_get("project-name", "unnamed");
398		- Stmt q;
399	415	@ <tr><th>Timelines:</th><td>
400	416	@ <a href="%s(g.zBaseURL)/timeline?p=%d(rid)">ancestors</a>
401	417	@ \| <a href="%s(g.zBaseURL)/timeline?d=%d(rid)">descendants</a>
402	418	@ \| <a href="%s(g.zBaseURL)/timeline?d=%d(rid)&p=%d(rid)">both</a>
403	419	db_prepare(&q, "SELECT substr(tag.tagname,5) FROM tagxref, tag "
		@@ -1128,13 +1144,10 @@
1128	1144	return;
1129	1145	}
1130	1146	if( db_exists("SELECT 1 FROM mlink WHERE mid=%d", rid) ){
1131	1147	vinfo_page();
1132	1148	}else
1133		- if( db_exists("SELECT 1 FROM mlink WHERE fid=%d", rid) ){
1134		- finfo_page();
1135		- }else
1136	1149	if( db_exists("SELECT 1 FROM tagxref JOIN tag USING(tagid)"
1137	1150	" WHERE rid=%d AND tagname LIKE 'wiki-%%'", rid) ){
1138	1151	winfo_page();
1139	1152	}else
1140	1153	if( db_exists("SELECT 1 FROM tagxref JOIN tag USING(tagid)"
1141	1154

	--- src/info.c
	+++ src/info.c
	@@ -390,14 +390,30 @@
390	@ <tr><th>Original Comment:</th><td>%w(zComment)</td></tr>
391	}else{
392	@ <tr><th>Comment:</th><td>%w(zComment)</td></tr>
393	}
394	@ </td></tr>

















395	if( g.okHistory ){
396	char *zShortUuid = mprintf("%.10s", zUuid);
397	const char *zProjName = db_get("project-name", "unnamed");
398	Stmt q;
399	@ <tr><th>Timelines:</th><td>
400	@ <a href="%s(g.zBaseURL)/timeline?p=%d(rid)">ancestors</a>
401	@ \| <a href="%s(g.zBaseURL)/timeline?d=%d(rid)">descendants</a>
402	@ \| <a href="%s(g.zBaseURL)/timeline?d=%d(rid)&p=%d(rid)">both</a>
403	db_prepare(&q, "SELECT substr(tag.tagname,5) FROM tagxref, tag "
	@@ -1128,13 +1144,10 @@
1128	return;
1129	}
1130	if( db_exists("SELECT 1 FROM mlink WHERE mid=%d", rid) ){
1131	vinfo_page();
1132	}else
1133	if( db_exists("SELECT 1 FROM mlink WHERE fid=%d", rid) ){
1134	finfo_page();
1135	}else
1136	if( db_exists("SELECT 1 FROM tagxref JOIN tag USING(tagid)"
1137	" WHERE rid=%d AND tagname LIKE 'wiki-%%'", rid) ){
1138	winfo_page();
1139	}else
1140	if( db_exists("SELECT 1 FROM tagxref JOIN tag USING(tagid)"
1141

	--- src/info.c
	+++ src/info.c
	@@ -390,14 +390,30 @@
390	@ <tr><th>Original Comment:</th><td>%w(zComment)</td></tr>
391	}else{
392	@ <tr><th>Comment:</th><td>%w(zComment)</td></tr>
393	}
394	@ </td></tr>
395	if( g.okAdmin ){
396	db_prepare(&q,
397	"SELECT rcvfrom.ipaddr, user.login, datetime(rcvfrom.mtime)"
398	" FROM blob JOIN rcvfrom USING(rcvid) LEFT JOIN user USING(uid)"
399	" WHERE blob.rid=%d",
400	rid
401	);
402	if( db_step(&q)==SQLITE_ROW ){
403	const char *zIpAddr = db_column_text(&q, 0);
404	const char *zUser = db_column_text(&q, 1);
405	const char *zDate = db_column_text(&q, 2);
406	if( zUser==0 \|\| zUser[0]==0 ) zUser = "unknown";
407	@ <tr><th>Received From:</th>
408	@ <td>%h(zUser) @ %h(zIpAddr) on %s(zDate)</td></tr>
409	}
410	db_finalize(&q);
411	}
412	if( g.okHistory ){
413	char *zShortUuid = mprintf("%.10s", zUuid);
414	const char *zProjName = db_get("project-name", "unnamed");

415	@ <tr><th>Timelines:</th><td>
416	@ <a href="%s(g.zBaseURL)/timeline?p=%d(rid)">ancestors</a>
417	@ \| <a href="%s(g.zBaseURL)/timeline?d=%d(rid)">descendants</a>
418	@ \| <a href="%s(g.zBaseURL)/timeline?d=%d(rid)&p=%d(rid)">both</a>
419	db_prepare(&q, "SELECT substr(tag.tagname,5) FROM tagxref, tag "
	@@ -1128,13 +1144,10 @@
1144	return;
1145	}
1146	if( db_exists("SELECT 1 FROM mlink WHERE mid=%d", rid) ){
1147	vinfo_page();
1148	}else



1149	if( db_exists("SELECT 1 FROM tagxref JOIN tag USING(tagid)"
1150	" WHERE rid=%d AND tagname LIKE 'wiki-%%'", rid) ){
1151	winfo_page();
1152	}else
1153	if( db_exists("SELECT 1 FROM tagxref JOIN tag USING(tagid)"
1154

M src/setup.c

+3 -1

		--- src/setup.c
		+++ src/setup.c
		@@ -56,11 +56,11 @@
56	56	login_check_credentials();
57	57	if( !g.okSetup ){
58	58	login_needed();
59	59	}
60	60
61		- style_header("Setup");
	61	+ style_header("Server Administration");
62	62	@ <table border="0" cellspacing="20">
63	63	setup_menu_entry("Users", "setup_ulist",
64	64	"Grant privileges to individual users.");
65	65	setup_menu_entry("Access", "setup_access",
66	66	"Control access settings.");
		@@ -76,10 +76,12 @@
76	76	"Edit HTML text inserted at the top of every page");
77	77	setup_menu_entry("Footer", "setup_footer",
78	78	"Edit HTML text inserted at the bottom of every page");
79	79	setup_menu_entry("Shunned", "shun",
80	80	"Show artifacts that are shunned by this repository");
	81	+ setup_menu_entry("Log", "rcvfromlist",
	82	+ "A record of received artifacts and their sources");
81	83	setup_menu_entry("Stats", "stat",
82	84	"Display repository statistics");
83	85	@ </table>
84	86
85	87	style_footer();
86	88

	--- src/setup.c
	+++ src/setup.c
	@@ -56,11 +56,11 @@
56	login_check_credentials();
57	if( !g.okSetup ){
58	login_needed();
59	}
60
61	style_header("Setup");
62	@ <table border="0" cellspacing="20">
63	setup_menu_entry("Users", "setup_ulist",
64	"Grant privileges to individual users.");
65	setup_menu_entry("Access", "setup_access",
66	"Control access settings.");
	@@ -76,10 +76,12 @@
76	"Edit HTML text inserted at the top of every page");
77	setup_menu_entry("Footer", "setup_footer",
78	"Edit HTML text inserted at the bottom of every page");
79	setup_menu_entry("Shunned", "shun",
80	"Show artifacts that are shunned by this repository");


81	setup_menu_entry("Stats", "stat",
82	"Display repository statistics");
83	@ </table>
84
85	style_footer();
86

	--- src/setup.c
	+++ src/setup.c
	@@ -56,11 +56,11 @@
56	login_check_credentials();
57	if( !g.okSetup ){
58	login_needed();
59	}
60
61	style_header("Server Administration");
62	@ <table border="0" cellspacing="20">
63	setup_menu_entry("Users", "setup_ulist",
64	"Grant privileges to individual users.");
65	setup_menu_entry("Access", "setup_access",
66	"Control access settings.");
	@@ -76,10 +76,12 @@
76	"Edit HTML text inserted at the top of every page");
77	setup_menu_entry("Footer", "setup_footer",
78	"Edit HTML text inserted at the bottom of every page");
79	setup_menu_entry("Shunned", "shun",
80	"Show artifacts that are shunned by this repository");
81	setup_menu_entry("Log", "rcvfromlist",
82	"A record of received artifacts and their sources");
83	setup_menu_entry("Stats", "stat",
84	"Display repository statistics");
85	@ </table>
86
87	style_footer();
88

M src/shun.c

+111 -2

		--- src/shun.c
		+++ src/shun.c
		@@ -26,11 +26,11 @@
26	26	#include "config.h"
27	27	#include "shun.h"
28	28	#include <assert.h>
29	29
30	30	/*
31		-** Return true if the given UUID should be shunned.
	31	+** Return true if the given artifact ID should be shunned.
32	32	*/
33	33	int uuid_is_shunned(const char *zUuid){
34	34	static Stmt q;
35	35	int rc;
36	36	if( zUuid==0 \|\| zUuid[0]==0 ) return 0;
		@@ -119,14 +119,18 @@
119	119	}
120	120	db_finalize(&q);
121	121	@ </blockquote>
122	122	@ <hr>
123	123	@ <a name="addshun"></a>
124		- @ <p>To shun an artifact, enter its UUID in the
	124	+ @ <p>To shun an artifact, enter its artifact ID (the 40-character SHA1
	125	+ @ hash of the artifact) in the
125	126	@ following box and press the "Shun" button. This will cause the artifact
126	127	@ to be removed from the repository and will prevent the artifact from being
127	128	@ readded to the repository by subsequent sync operation.</p>
	129	+ @
	130	+ @ <p>Note that you must enter the full 40-character artifact ID, not
	131	+ @ an abbreviation or a symbolic tag.</p>
128	132	@
129	133	@ <p>Warning: Shunning should only be used to remove inappropriate content
130	134	@ from the repository. Inappropriate content includes such things as
131	135	@ spam added to Wiki, files that violate copyright or patent agreements,
132	136	@ or artifacts that by design or accident interfere with the processing
		@@ -153,10 +157,11 @@
153	157	@ <input type="text" name="uuid" size="50">
154	158	@ <input type="submit" name="sub" value="Accept">
155	159	@ </form>
156	160	@ </blockquote>
157	161	@
	162	+ @ <hr>
158	163	@ <p>Press the button below to rebuild the respository. The rebuild
159	164	@ may take several seconds, so be patient after pressing the button.</p>
160	165	@
161	166	@ <blockquote>
162	167	@ <form method="POST" action="%s(g.zBaseURL)/%s(g.zPath)">
		@@ -189,5 +194,109 @@
189	194	"DELETE FROM delta WHERE rid IN toshun;"
190	195	"DELETE FROM blob WHERE rid IN toshun;"
191	196	"DROP TABLE toshun;"
192	197	);
193	198	}
	199	+
	200	+/*
	201	+** WEBPAGE: rcvfromlist
	202	+**
	203	+** Show a listing of RCVFROM table entries.
	204	+*/
	205	+void rcvfromlist_page(void){
	206	+ int ofst = atoi(PD("ofst","0"));
	207	+ int cnt;
	208	+ Stmt q;
	209	+
	210	+ login_check_credentials();
	211	+ if( !g.okAdmin ){
	212	+ login_needed();
	213	+ }
	214	+ style_header("Content Sources");
	215	+ if( ofst>0 ){
	216	+ style_submenu_element("Later", "Later", "rcvfromlist?ofst=%d",
	217	+ ofst>30 ? ofst-30 : 0);
	218	+ }
	219	+ db_prepare(&q,
	220	+ "SELECT rcvid, login, datetime(rcvfrom.mtime), rcvfrom.ipaddr"
	221	+ " FROM rcvfrom LEFT JOIN user USING(uid)"
	222	+ " ORDER BY rcvid DESC LIMIT 31 OFFSET %d",
	223	+ ofst
	224	+ );
	225	+ @ <table cellpadding=0 cellspacing=0 border=0>
	226	+ @ <tr><th>rcvid</th><th width=15>
	227	+ @ <th>Date</th><th width=15><th>User</th>
	228	+ @ <th width=15><th>IP Address</th></tr>
	229	+ cnt = 0;
	230	+ while( db_step(&q)==SQLITE_ROW ){
	231	+ int rcvid = db_column_int(&q, 0);
	232	+ const char *zUser = db_column_text(&q, 1);
	233	+ const char *zDate = db_column_text(&q, 2);
	234	+ const char *zIpAddr = db_column_text(&q, 3);
	235	+ if( cnt==30 ){
	236	+ style_submenu_element("Earlier", "Earlier",
	237	+ "rcvfromlist?ofst=%d", ofst+30);
	238	+ }else{
	239	+ cnt++;
	240	+ @ <tr>
	241	+ @ <td><a href="rcvfrom?rcvid=%d(rcvid)">%d(rcvid)</a></td><td>
	242	+ @ <td>%s(zDate)</td><td>
	243	+ @ <td>%h(zUser)</td><td>
	244	+ @ <td> %s(zIpAddr)&nbsp</td>
	245	+ @ </tr>
	246	+ }
	247	+ }
	248	+ db_finalize(&q);
	249	+ @ </table>
	250	+ style_footer();
	251	+}
	252	+
	253	+/*
	254	+** WEBPAGE: rcvfrom
	255	+**
	256	+** Show a single RCVFROM table entry.
	257	+*/
	258	+void rcvfrom_page(void){
	259	+ int rcvid = atoi(PD("rcvid","0"));
	260	+ Stmt q;
	261	+
	262	+ login_check_credentials();
	263	+ if( !g.okAdmin ){
	264	+ login_needed();
	265	+ }
	266	+ style_header("Content Source %d", rcvid);
	267	+ db_prepare(&q,
	268	+ "SELECT login, datetime(rcvfrom.mtime), rcvfrom.ipaddr"
	269	+ " FROM rcvfrom LEFT JOIN user USING(uid)"
	270	+ " WHERE rcvid=%d",
	271	+ rcvid
	272	+ );
	273	+ @ <table cellspacing=15 cellpadding=0 border=0>
	274	+ @ <tr><td valign="top" align="right">rcvid:</td>
	275	+ @ <td valign="top">%d(rcvid)</td></tr>
	276	+ if( db_step(&q)==SQLITE_ROW ){
	277	+ const char *zUser = db_column_text(&q, 0);
	278	+ const char *zDate = db_column_text(&q, 1);
	279	+ const char *zIpAddr = db_column_text(&q, 2);
	280	+ @ <tr><td valign="top" align="right">User:</td>
	281	+ @ <td valign="top">%s(zUser)</td></tr>
	282	+ @ <tr><td valign="top" align="right">Date:</td>
	283	+ @ <td valign="top">%s(zDate)</td></tr>
	284	+ @ <tr><td valign="top" align="right">IP&nbspAddress:</td>
	285	+ @ <td valign="top">%s(zIpAddr)</td></tr>
	286	+ }
	287	+ db_finalize(&q);
	288	+ db_prepare(&q,
	289	+ "SELECT rid, uuid, size FROM blob WHERE rcvid=%d", rcvid
	290	+ );
	291	+ @ <tr><td valign="top" align="right">Artifacts:</td>
	292	+ @ <td valign="top">
	293	+ while( db_step(&q)==SQLITE_ROW ){
	294	+ int rid = db_column_int(&q, 0);
	295	+ const char *zUuid = db_column_text(&q, 1);
	296	+ int size = db_column_int(&q, 2);
	297	+ @ <a href="%s(g.zBaseURL)/info/%s(zUuid)">%s(zUuid)</a>
	298	+ @ (rid: %d(rid), size: %d(size))<br>
	299	+ }
	300	+ @ </td></tr>
	301	+ @ </table>
	302	+}
194	303

	--- src/shun.c
	+++ src/shun.c
	@@ -26,11 +26,11 @@
26	#include "config.h"
27	#include "shun.h"
28	#include <assert.h>
29
30	/*
31	** Return true if the given UUID should be shunned.
32	*/
33	int uuid_is_shunned(const char *zUuid){
34	static Stmt q;
35	int rc;
36	if( zUuid==0 \|\| zUuid[0]==0 ) return 0;
	@@ -119,14 +119,18 @@
119	}
120	db_finalize(&q);
121	@ </blockquote>
122	@ <hr>
123	@ <a name="addshun"></a>
124	@ <p>To shun an artifact, enter its UUID in the

125	@ following box and press the "Shun" button. This will cause the artifact
126	@ to be removed from the repository and will prevent the artifact from being
127	@ readded to the repository by subsequent sync operation.</p>



128	@
129	@ <p>Warning: Shunning should only be used to remove inappropriate content
130	@ from the repository. Inappropriate content includes such things as
131	@ spam added to Wiki, files that violate copyright or patent agreements,
132	@ or artifacts that by design or accident interfere with the processing
	@@ -153,10 +157,11 @@
153	@ <input type="text" name="uuid" size="50">
154	@ <input type="submit" name="sub" value="Accept">
155	@ </form>
156	@ </blockquote>
157	@

158	@ <p>Press the button below to rebuild the respository. The rebuild
159	@ may take several seconds, so be patient after pressing the button.</p>
160	@
161	@ <blockquote>
162	@ <form method="POST" action="%s(g.zBaseURL)/%s(g.zPath)">
	@@ -189,5 +194,109 @@
189	"DELETE FROM delta WHERE rid IN toshun;"
190	"DELETE FROM blob WHERE rid IN toshun;"
191	"DROP TABLE toshun;"
192	);
193	}








































































































194

	--- src/shun.c
	+++ src/shun.c
	@@ -26,11 +26,11 @@
26	#include "config.h"
27	#include "shun.h"
28	#include <assert.h>
29
30	/*
31	** Return true if the given artifact ID should be shunned.
32	*/
33	int uuid_is_shunned(const char *zUuid){
34	static Stmt q;
35	int rc;
36	if( zUuid==0 \|\| zUuid[0]==0 ) return 0;
	@@ -119,14 +119,18 @@
119	}
120	db_finalize(&q);
121	@ </blockquote>
122	@ <hr>
123	@ <a name="addshun"></a>
124	@ <p>To shun an artifact, enter its artifact ID (the 40-character SHA1
125	@ hash of the artifact) in the
126	@ following box and press the "Shun" button. This will cause the artifact
127	@ to be removed from the repository and will prevent the artifact from being
128	@ readded to the repository by subsequent sync operation.</p>
129	@
130	@ <p>Note that you must enter the full 40-character artifact ID, not
131	@ an abbreviation or a symbolic tag.</p>
132	@
133	@ <p>Warning: Shunning should only be used to remove inappropriate content
134	@ from the repository. Inappropriate content includes such things as
135	@ spam added to Wiki, files that violate copyright or patent agreements,
136	@ or artifacts that by design or accident interfere with the processing
	@@ -153,10 +157,11 @@
157	@ <input type="text" name="uuid" size="50">
158	@ <input type="submit" name="sub" value="Accept">
159	@ </form>
160	@ </blockquote>
161	@
162	@ <hr>
163	@ <p>Press the button below to rebuild the respository. The rebuild
164	@ may take several seconds, so be patient after pressing the button.</p>
165	@
166	@ <blockquote>
167	@ <form method="POST" action="%s(g.zBaseURL)/%s(g.zPath)">
	@@ -189,5 +194,109 @@
194	"DELETE FROM delta WHERE rid IN toshun;"
195	"DELETE FROM blob WHERE rid IN toshun;"
196	"DROP TABLE toshun;"
197	);
198	}
199
200	/*
201	** WEBPAGE: rcvfromlist
202	**
203	** Show a listing of RCVFROM table entries.
204	*/
205	void rcvfromlist_page(void){
206	int ofst = atoi(PD("ofst","0"));
207	int cnt;
208	Stmt q;
209
210	login_check_credentials();
211	if( !g.okAdmin ){
212	login_needed();
213	}
214	style_header("Content Sources");
215	if( ofst>0 ){
216	style_submenu_element("Later", "Later", "rcvfromlist?ofst=%d",
217	ofst>30 ? ofst-30 : 0);
218	}
219	db_prepare(&q,
220	"SELECT rcvid, login, datetime(rcvfrom.mtime), rcvfrom.ipaddr"
221	" FROM rcvfrom LEFT JOIN user USING(uid)"
222	" ORDER BY rcvid DESC LIMIT 31 OFFSET %d",
223	ofst
224	);
225	@ <table cellpadding=0 cellspacing=0 border=0>
226	@ <tr><th>rcvid</th><th width=15>
227	@ <th>Date</th><th width=15><th>User</th>
228	@ <th width=15><th>IP Address</th></tr>
229	cnt = 0;
230	while( db_step(&q)==SQLITE_ROW ){
231	int rcvid = db_column_int(&q, 0);
232	const char *zUser = db_column_text(&q, 1);
233	const char *zDate = db_column_text(&q, 2);
234	const char *zIpAddr = db_column_text(&q, 3);
235	if( cnt==30 ){
236	style_submenu_element("Earlier", "Earlier",
237	"rcvfromlist?ofst=%d", ofst+30);
238	}else{
239	cnt++;
240	@ <tr>
241	@ <td><a href="rcvfrom?rcvid=%d(rcvid)">%d(rcvid)</a></td><td>
242	@ <td>%s(zDate)</td><td>
243	@ <td>%h(zUser)</td><td>
244	@ <td> %s(zIpAddr)&nbsp</td>
245	@ </tr>
246	}
247	}
248	db_finalize(&q);
249	@ </table>
250	style_footer();
251	}
252
253	/*
254	** WEBPAGE: rcvfrom
255	**
256	** Show a single RCVFROM table entry.
257	*/
258	void rcvfrom_page(void){
259	int rcvid = atoi(PD("rcvid","0"));
260	Stmt q;
261
262	login_check_credentials();
263	if( !g.okAdmin ){
264	login_needed();
265	}
266	style_header("Content Source %d", rcvid);
267	db_prepare(&q,
268	"SELECT login, datetime(rcvfrom.mtime), rcvfrom.ipaddr"
269	" FROM rcvfrom LEFT JOIN user USING(uid)"
270	" WHERE rcvid=%d",
271	rcvid
272	);
273	@ <table cellspacing=15 cellpadding=0 border=0>
274	@ <tr><td valign="top" align="right">rcvid:</td>
275	@ <td valign="top">%d(rcvid)</td></tr>
276	if( db_step(&q)==SQLITE_ROW ){
277	const char *zUser = db_column_text(&q, 0);
278	const char *zDate = db_column_text(&q, 1);
279	const char *zIpAddr = db_column_text(&q, 2);
280	@ <tr><td valign="top" align="right">User:</td>
281	@ <td valign="top">%s(zUser)</td></tr>
282	@ <tr><td valign="top" align="right">Date:</td>
283	@ <td valign="top">%s(zDate)</td></tr>
284	@ <tr><td valign="top" align="right">IP&nbspAddress:</td>
285	@ <td valign="top">%s(zIpAddr)</td></tr>
286	}
287	db_finalize(&q);
288	db_prepare(&q,
289	"SELECT rid, uuid, size FROM blob WHERE rcvid=%d", rcvid
290	);
291	@ <tr><td valign="top" align="right">Artifacts:</td>
292	@ <td valign="top">
293	while( db_step(&q)==SQLITE_ROW ){
294	int rid = db_column_int(&q, 0);
295	const char *zUuid = db_column_text(&q, 1);
296	int size = db_column_int(&q, 2);
297	@ <a href="%s(g.zBaseURL)/info/%s(zUuid)">%s(zUuid)</a>
298	@ (rid: %d(rid), size: %d(size))<br>
299	}
300	@ </td></tr>
301	@ </table>
302	}
303

M src/style.c

+1 -1

		--- src/style.c
		+++ src/style.c
		@@ -221,11 +221,11 @@
221	221	@ }
222	222	@ if {[hascap j]} {
223	223	@ html "<a href='$baseurl/wiki'>Wiki</a>"
224	224	@ }
225	225	@ if {[hascap s]} {
226		-@ html "<a href='$baseurl/setup'>Setup</a>"
	226	+@ html "<a href='$baseurl/setup'>Admin</a>"
227	227	@ } elseif {[hascap a]} {
228	228	@ html "<a href='$baseurl/setup_ulist'>Users</a>"
229	229	@ }
230	230	@ if {[info exists login]} {
231	231	@ html "<a href='$baseurl/login'>Logout</a>"
232	232

	--- src/style.c
	+++ src/style.c
	@@ -221,11 +221,11 @@
221	@ }
222	@ if {[hascap j]} {
223	@ html "<a href='$baseurl/wiki'>Wiki</a>"
224	@ }
225	@ if {[hascap s]} {
226	@ html "<a href='$baseurl/setup'>Setup</a>"
227	@ } elseif {[hascap a]} {
228	@ html "<a href='$baseurl/setup_ulist'>Users</a>"
229	@ }
230	@ if {[info exists login]} {
231	@ html "<a href='$baseurl/login'>Logout</a>"
232

	--- src/style.c
	+++ src/style.c
	@@ -221,11 +221,11 @@
221	@ }
222	@ if {[hascap j]} {
223	@ html "<a href='$baseurl/wiki'>Wiki</a>"
224	@ }
225	@ if {[hascap s]} {
226	@ html "<a href='$baseurl/setup'>Admin</a>"
227	@ } elseif {[hascap a]} {
228	@ html "<a href='$baseurl/setup_ulist'>Users</a>"
229	@ }
230	@ if {[info exists login]} {
231	@ html "<a href='$baseurl/login'>Logout</a>"
232

M www/branching.wiki

+11 -9

		--- www/branching.wiki
		+++ www/branching.wiki
		@@ -80,13 +80,13 @@
80	80	<tr><td align="center">
81	81	<img src="branch03.gif" width=282 height=152><br>
82	82	Figure 3
83	83	</td></tr></table></center>
84	84
85		-Check-in 5 is a direct child of check-in 3 because it was created by editing
	85	+Check-in 5 is a child of check-in 3 because it was created by editing
86	86	check-in 3. But check-in 5 also inherits the changes from check-in 4 by
87		-virtual of the merge. So we say that check-in 5 is a <i>merge child</i>
	87	+virtue of the merge. So we say that check-in 5 is a <i>merge child</i>
88	88	of check-in 4 and that it is a <i>direct child</i> of check-in 3.
89	89	The graph is now back to a single leaf (check-in 5).
90	90
91	91	We have already seen that if fossil is in autosync mode then Bob would
92	92	have been warned about the potential fork the first time he tried to
		@@ -109,13 +109,13 @@
109	109	instead of as a separate manual step. We will not take sides in that
110	110	debate. We will simply point out that fossil enables you to do it either way.
111	111
112	112	<h2>Forking Versus Branching</h2>
113	113
114		-Forking and having more than one leaf in the check-in tree is usually
115		-considered undesirable, and so forks are usually quickly resolved as
116		-shown in figure 3 above.
	114	+Having more than one leaf in the check-in tree is usually
	115	+considered undesirable, and so forks are usually either avoided entirely,
	116	+as in figure 1, or else quickly resolved as shown in figure 3.
117	117	But sometimes, one does want to have multiple leaves. For example, a project
118	118	might have one leaf that is the latest version of the project under
119	119	development and another leaf that is the latest version that has been
120	120	tested.
121	121	When multiple leaves are desirable, we call the phenomenon <i>branching</i>
		@@ -146,11 +146,11 @@
146	146	shown by the dashed merge arrows between check-ins 6 and 7 and between
147	147	check-ins 9 and 10.
148	148
149	149	In both figures 2 and 4, check-in 2 has two children. In figure 2,
150	150	we called this a "fork". In diagram 4, we call it a "branch". What is
151		-the difference? As far as the internal fossil data structure are
	151	+the difference? As far as the internal fossil data structures are
152	152	concerned, there is no difference. The distinction is in the intent.
153	153	In figure 2, the fact that check-in 2 has multiple children is an
154	154	accident that stems from concurrent development. In figure 4, giving
155	155	check-in 2 multiple children is a deliberate act. So, to a good
156	156	approximation, we define forking to be by accident and branching to
		@@ -172,19 +172,20 @@
172	172	<i>property</i> is a name/value pair. Internally, fossil implements
173	173	tags as properties with a NULL value. So, tags and properties really
174	174	are much the same thing, and henceforth we will use the word "tag"
175	175	to mean either a tag or a property.
176	176
177		-A tag can be either a one-time tag or an propagating tag or a cancellation.
	177	+A tag can be either a one-time tag or an propagating tag or a cancellation tag.
178	178	A one-time tag only applies to the check-in to which it is attached. A
179	179	propagating tag applies to the check-in to which it is attached and also
180	180	to all direct descendants of that check-in. A <i>direct descendant</i>
181	181	is a descendant through direct children. Tags propagation does not
182	182	cross merges. Tag propagation also stops as soon
183	183	as it encounters another check-in with the same tag. A cancellation tag
184	184	is attached to a single check-in in order to either override a one-time
185		-tag that was placed on that same check-in, or to block tag propagation.
	185	+tag that was previously placed on that same check-in, or to block
	186	+tag propagation from an ancestor.
186	187
187	188	Every repository is created with a single empty check-in that has two
188	189	propagating tags. In figure 5, that initial empty check-in is check-in 1.
189	190	The <b>branch</b> tag tells (by its value)
190	191	what branch the check-in is a member of.
		@@ -214,11 +215,11 @@
214	215	<b>sym-trunk</b> on check-in 4. The net effect of all of this is that
215	216	check-ins on the trunk go by the symbolic name of "trunk" and check-ins
216	217	that are on the test branch go by the symbolic name "test".
217	218
218	219	The <b>bgcolor=blue</b> tag on check-in 4 causes the background color
219		-of timelines to be blue for check-in 4 and its descendants.
	220	+of timelines to be blue for check-in 4 and its direct descendants.
220	221
221	222	Figure 5 also shows two one-time tags on check-in 9. (The diagram does
222	223	not make a graphical distinction between one-time and propagating tags.)
223	224	The <b>sym-release-1.0</b> tag means that check-in 9 can be referred to
224	225	using the more meaningful name "release-1.0". The <b>closed</b> tag means
		@@ -231,10 +232,11 @@
231	232
232	233
233	234	<blockquote><dl>
234	235	<dt><b>Branch</b></dt>
235	236	<dd><p>A branch is a set of check-ins that have the same value for their
	237	+branch property.</p></dd>
236	238	<dt><b>Leaf</b></dt>
237	239	<dd><p>A leaf is a check-in that has no children in the same branch.</p></dd>
238	240	<dt><b>Closed Leaf</b></dt>
239	241	<dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves
240	242	are intented to never be extended with descendents and hence are omitted
241	243

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -80,13 +80,13 @@
80	<tr><td align="center">
81	<img src="branch03.gif" width=282 height=152><br>
82	Figure 3
83	</td></tr></table></center>
84
85	Check-in 5 is a direct child of check-in 3 because it was created by editing
86	check-in 3. But check-in 5 also inherits the changes from check-in 4 by
87	virtual of the merge. So we say that check-in 5 is a <i>merge child</i>
88	of check-in 4 and that it is a <i>direct child</i> of check-in 3.
89	The graph is now back to a single leaf (check-in 5).
90
91	We have already seen that if fossil is in autosync mode then Bob would
92	have been warned about the potential fork the first time he tried to
	@@ -109,13 +109,13 @@
109	instead of as a separate manual step. We will not take sides in that
110	debate. We will simply point out that fossil enables you to do it either way.
111
112	<h2>Forking Versus Branching</h2>
113
114	Forking and having more than one leaf in the check-in tree is usually
115	considered undesirable, and so forks are usually quickly resolved as
116	shown in figure 3 above.
117	But sometimes, one does want to have multiple leaves. For example, a project
118	might have one leaf that is the latest version of the project under
119	development and another leaf that is the latest version that has been
120	tested.
121	When multiple leaves are desirable, we call the phenomenon <i>branching</i>
	@@ -146,11 +146,11 @@
146	shown by the dashed merge arrows between check-ins 6 and 7 and between
147	check-ins 9 and 10.
148
149	In both figures 2 and 4, check-in 2 has two children. In figure 2,
150	we called this a "fork". In diagram 4, we call it a "branch". What is
151	the difference? As far as the internal fossil data structure are
152	concerned, there is no difference. The distinction is in the intent.
153	In figure 2, the fact that check-in 2 has multiple children is an
154	accident that stems from concurrent development. In figure 4, giving
155	check-in 2 multiple children is a deliberate act. So, to a good
156	approximation, we define forking to be by accident and branching to
	@@ -172,19 +172,20 @@
172	<i>property</i> is a name/value pair. Internally, fossil implements
173	tags as properties with a NULL value. So, tags and properties really
174	are much the same thing, and henceforth we will use the word "tag"
175	to mean either a tag or a property.
176
177	A tag can be either a one-time tag or an propagating tag or a cancellation.
178	A one-time tag only applies to the check-in to which it is attached. A
179	propagating tag applies to the check-in to which it is attached and also
180	to all direct descendants of that check-in. A <i>direct descendant</i>
181	is a descendant through direct children. Tags propagation does not
182	cross merges. Tag propagation also stops as soon
183	as it encounters another check-in with the same tag. A cancellation tag
184	is attached to a single check-in in order to either override a one-time
185	tag that was placed on that same check-in, or to block tag propagation.

186
187	Every repository is created with a single empty check-in that has two
188	propagating tags. In figure 5, that initial empty check-in is check-in 1.
189	The <b>branch</b> tag tells (by its value)
190	what branch the check-in is a member of.
	@@ -214,11 +215,11 @@
214	<b>sym-trunk</b> on check-in 4. The net effect of all of this is that
215	check-ins on the trunk go by the symbolic name of "trunk" and check-ins
216	that are on the test branch go by the symbolic name "test".
217
218	The <b>bgcolor=blue</b> tag on check-in 4 causes the background color
219	of timelines to be blue for check-in 4 and its descendants.
220
221	Figure 5 also shows two one-time tags on check-in 9. (The diagram does
222	not make a graphical distinction between one-time and propagating tags.)
223	The <b>sym-release-1.0</b> tag means that check-in 9 can be referred to
224	using the more meaningful name "release-1.0". The <b>closed</b> tag means
	@@ -231,10 +232,11 @@
231
232
233	<blockquote><dl>
234	<dt><b>Branch</b></dt>
235	<dd><p>A branch is a set of check-ins that have the same value for their

236	<dt><b>Leaf</b></dt>
237	<dd><p>A leaf is a check-in that has no children in the same branch.</p></dd>
238	<dt><b>Closed Leaf</b></dt>
239	<dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves
240	are intented to never be extended with descendents and hence are omitted
241

	--- www/branching.wiki
	+++ www/branching.wiki
	@@ -80,13 +80,13 @@
80	<tr><td align="center">
81	<img src="branch03.gif" width=282 height=152><br>
82	Figure 3
83	</td></tr></table></center>
84
85	Check-in 5 is a child of check-in 3 because it was created by editing
86	check-in 3. But check-in 5 also inherits the changes from check-in 4 by
87	virtue of the merge. So we say that check-in 5 is a <i>merge child</i>
88	of check-in 4 and that it is a <i>direct child</i> of check-in 3.
89	The graph is now back to a single leaf (check-in 5).
90
91	We have already seen that if fossil is in autosync mode then Bob would
92	have been warned about the potential fork the first time he tried to
	@@ -109,13 +109,13 @@
109	instead of as a separate manual step. We will not take sides in that
110	debate. We will simply point out that fossil enables you to do it either way.
111
112	<h2>Forking Versus Branching</h2>
113
114	Having more than one leaf in the check-in tree is usually
115	considered undesirable, and so forks are usually either avoided entirely,
116	as in figure 1, or else quickly resolved as shown in figure 3.
117	But sometimes, one does want to have multiple leaves. For example, a project
118	might have one leaf that is the latest version of the project under
119	development and another leaf that is the latest version that has been
120	tested.
121	When multiple leaves are desirable, we call the phenomenon <i>branching</i>
	@@ -146,11 +146,11 @@
146	shown by the dashed merge arrows between check-ins 6 and 7 and between
147	check-ins 9 and 10.
148
149	In both figures 2 and 4, check-in 2 has two children. In figure 2,
150	we called this a "fork". In diagram 4, we call it a "branch". What is
151	the difference? As far as the internal fossil data structures are
152	concerned, there is no difference. The distinction is in the intent.
153	In figure 2, the fact that check-in 2 has multiple children is an
154	accident that stems from concurrent development. In figure 4, giving
155	check-in 2 multiple children is a deliberate act. So, to a good
156	approximation, we define forking to be by accident and branching to
	@@ -172,19 +172,20 @@
172	<i>property</i> is a name/value pair. Internally, fossil implements
173	tags as properties with a NULL value. So, tags and properties really
174	are much the same thing, and henceforth we will use the word "tag"
175	to mean either a tag or a property.
176
177	A tag can be either a one-time tag or an propagating tag or a cancellation tag.
178	A one-time tag only applies to the check-in to which it is attached. A
179	propagating tag applies to the check-in to which it is attached and also
180	to all direct descendants of that check-in. A <i>direct descendant</i>
181	is a descendant through direct children. Tags propagation does not
182	cross merges. Tag propagation also stops as soon
183	as it encounters another check-in with the same tag. A cancellation tag
184	is attached to a single check-in in order to either override a one-time
185	tag that was previously placed on that same check-in, or to block
186	tag propagation from an ancestor.
187
188	Every repository is created with a single empty check-in that has two
189	propagating tags. In figure 5, that initial empty check-in is check-in 1.
190	The <b>branch</b> tag tells (by its value)
191	what branch the check-in is a member of.
	@@ -214,11 +215,11 @@
215	<b>sym-trunk</b> on check-in 4. The net effect of all of this is that
216	check-ins on the trunk go by the symbolic name of "trunk" and check-ins
217	that are on the test branch go by the symbolic name "test".
218
219	The <b>bgcolor=blue</b> tag on check-in 4 causes the background color
220	of timelines to be blue for check-in 4 and its direct descendants.
221
222	Figure 5 also shows two one-time tags on check-in 9. (The diagram does
223	not make a graphical distinction between one-time and propagating tags.)
224	The <b>sym-release-1.0</b> tag means that check-in 9 can be referred to
225	using the more meaningful name "release-1.0". The <b>closed</b> tag means
	@@ -231,10 +232,11 @@
232
233
234	<blockquote><dl>
235	<dt><b>Branch</b></dt>
236	<dd><p>A branch is a set of check-ins that have the same value for their
237	branch property.</p></dd>
238	<dt><b>Leaf</b></dt>
239	<dd><p>A leaf is a check-in that has no children in the same branch.</p></dd>
240	<dt><b>Closed Leaf</b></dt>
241	<dd><p>A closed leaf is leaf that has the <b>closed</b> tag. Such leaves
242	are intented to never be extended with descendents and hence are omitted
243

M www/newrepo.wiki

+2 -2

		--- www/newrepo.wiki
		+++ www/newrepo.wiki
		@@ -30,11 +30,11 @@
30	30	</verbatim>
31	31
32	32	The <tt>ui</tt> command starts up a server (with an optional <tt>-port
33	33	NUMBER</tt> argument) and launches a web browser pointing at the
34	34	fossil server. From there it takes just a few moments to configure the
35		-repo. Most importantly, go to the Setup menu, then the Users link, and
	35	+repo. Most importantly, go to the Admin menu, then the Users link, and
36	36	set your account name and password, and grant your account all access
37	37	priviledges. (I also like to grant Clone access to the anonymous user,
38	38	but that's personal preference.)
39	39
40	40	Once you are done, kill the fossil server (with Ctrl-C or equivalent)
		@@ -154,11 +154,11 @@
154	154	remote repository. If you have <tt>autosync</tt> on then this sync
155	155	happens automatically, otherwise you will need to use the
156	156	<em>pull</em> command to get remote changes and the <em>push</em>
157	157	command to push your local commits to the remote repository. You must
158	158	of course have authorization to commit changes (access is configured
159		-via the Setup/Users page mentioned above).
	159	+via the Admin/Users page mentioned above).
160	160
161	161	You may always use the <em>server</em> or <em>ui</em> commands to
162	162	browse a cloned repository. You can even edit create or wiki entries,
163	163	etc., and they will be pushed to the remote side the next time you
164	164	push data to the the remote.
165	165

	--- www/newrepo.wiki
	+++ www/newrepo.wiki
	@@ -30,11 +30,11 @@
30	</verbatim>
31
32	The <tt>ui</tt> command starts up a server (with an optional <tt>-port
33	NUMBER</tt> argument) and launches a web browser pointing at the
34	fossil server. From there it takes just a few moments to configure the
35	repo. Most importantly, go to the Setup menu, then the Users link, and
36	set your account name and password, and grant your account all access
37	priviledges. (I also like to grant Clone access to the anonymous user,
38	but that's personal preference.)
39
40	Once you are done, kill the fossil server (with Ctrl-C or equivalent)
	@@ -154,11 +154,11 @@
154	remote repository. If you have <tt>autosync</tt> on then this sync
155	happens automatically, otherwise you will need to use the
156	<em>pull</em> command to get remote changes and the <em>push</em>
157	command to push your local commits to the remote repository. You must
158	of course have authorization to commit changes (access is configured
159	via the Setup/Users page mentioned above).
160
161	You may always use the <em>server</em> or <em>ui</em> commands to
162	browse a cloned repository. You can even edit create or wiki entries,
163	etc., and they will be pushed to the remote side the next time you
164	push data to the the remote.
165

	--- www/newrepo.wiki
	+++ www/newrepo.wiki
	@@ -30,11 +30,11 @@
30	</verbatim>
31
32	The <tt>ui</tt> command starts up a server (with an optional <tt>-port
33	NUMBER</tt> argument) and launches a web browser pointing at the
34	fossil server. From there it takes just a few moments to configure the
35	repo. Most importantly, go to the Admin menu, then the Users link, and
36	set your account name and password, and grant your account all access
37	priviledges. (I also like to grant Clone access to the anonymous user,
38	but that's personal preference.)
39
40	Once you are done, kill the fossil server (with Ctrl-C or equivalent)
	@@ -154,11 +154,11 @@
154	remote repository. If you have <tt>autosync</tt> on then this sync
155	happens automatically, otherwise you will need to use the
156	<em>pull</em> command to get remote changes and the <em>push</em>
157	command to push your local commits to the remote repository. You must
158	of course have authorization to commit changes (access is configured
159	via the Admin/Users page mentioned above).
160
161	You may always use the <em>server</em> or <em>ui</em> commands to
162	browse a cloned repository. You can even edit create or wiki entries,
163	etc., and they will be pushed to the remote side the next time you
164	push data to the the remote.
165

M www/quickstart.wiki

+1 -1

		--- www/quickstart.wiki
		+++ www/quickstart.wiki
		@@ -73,11 +73,11 @@
73	73	After the server is running, fossil will then attempt to launch your
74	74	web browser and make it point to this web server. If your system
75	75	has an unusual configuration, fossil might not be able to figure out
76	76	how to start your web browser. In that case, start the web browser
77	77	yourself and point it at http://localhost:8080/. Click on the
78		- "Setup" link on the menu bar to start configuring your repository.</p>
	78	+ "Admin" link on the menu bar to start configuring your repository.</p>
79	79
80	80	<p>By default, fossil does not require a login for HTTP connections
81	81	coming in from the IP loopback address 127.0.0.1. You can, and perhaps
82	82	should, change this after you create a few users.</p>
83	83
84	84

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -73,11 +73,11 @@
73	After the server is running, fossil will then attempt to launch your
74	web browser and make it point to this web server. If your system
75	has an unusual configuration, fossil might not be able to figure out
76	how to start your web browser. In that case, start the web browser
77	yourself and point it at http://localhost:8080/. Click on the
78	"Setup" link on the menu bar to start configuring your repository.</p>
79
80	<p>By default, fossil does not require a login for HTTP connections
81	coming in from the IP loopback address 127.0.0.1. You can, and perhaps
82	should, change this after you create a few users.</p>
83
84

	--- www/quickstart.wiki
	+++ www/quickstart.wiki
	@@ -73,11 +73,11 @@
73	After the server is running, fossil will then attempt to launch your
74	web browser and make it point to this web server. If your system
75	has an unusual configuration, fossil might not be able to figure out
76	how to start your web browser. In that case, start the web browser
77	yourself and point it at http://localhost:8080/. Click on the
78	"Admin" link on the menu bar to start configuring your repository.</p>
79
80	<p>By default, fossil does not require a login for HTTP connections
81	coming in from the IP loopback address 127.0.0.1. You can, and perhaps
82	should, change this after you create a few users.</p>
83
84

Fossil SCM

Keyboard Shortcuts