1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
|
<!DOCTYPE html>
<html><head>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<link href="sqlite.css" rel="stylesheet">
<title>Quality Management</title>
<!-- path= -->
</head>
<body>
<div class=nosearch>
<a href="index.html">
<img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0">
</a>
<div><!-- IE hack to prevent disappearing logo --></div>
<div class="tagline desktoponly">
Small. Fast. Reliable.<br>Choose any three.
</div>
<div class="menu mainmenu">
<ul>
<li><a href="index.html">Home</a>
<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a>
<li class='wideonly'><a href='about.html'>About</a>
<li class='desktoponly'><a href="docs.html">Documentation</a>
<li class='desktoponly'><a href="download.html">Download</a>
<li class='wideonly'><a href='copyright.html'>License</a>
<li class='desktoponly'><a href="support.html">Support</a>
<li class='desktoponly'><a href="prosupport.html">Purchase</a>
<li class='search' id='search_menubutton'>
<a href="javascript:void(0)" onclick='toggle_search()'>Search</a>
</ul>
</div>
<div class="menu submenu" id="submenu">
<ul>
<li><a href='about.html'>About</a>
<li><a href='docs.html'>Documentation</a>
<li><a href='download.html'>Download</a>
<li><a href='support.html'>Support</a>
<li><a href='prosupport.html'>Purchase</a>
</ul>
</div>
<div class="searchmenu" id="searchmenu">
<form method="GET" action="search">
<select name="s" id="searchtype">
<option value="d">Search Documentation</option>
<option value="c">Search Changelog</option>
</select>
<input type="text" name="q" id="searchbox" value="">
<input type="submit" value="Go">
</form>
</div>
</div>
<script>
function toggle_div(nm) {
var w = document.getElementById(nm);
if( w.style.display=="block" ){
w.style.display = "none";
}else{
w.style.display = "block";
}
}
function toggle_search() {
var w = document.getElementById("searchmenu");
if( w.style.display=="block" ){
w.style.display = "none";
} else {
w.style.display = "block";
setTimeout(function(){
document.getElementById("searchbox").focus()
}, 30);
}
}
function div_off(nm){document.getElementById(nm).style.display="none";}
window.onbeforeunload = function(e){div_off("submenu");}
/* Disable the Search feature if we are not operating from CGI, since */
/* Search is accomplished using CGI and will not work without it. */
if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){
document.getElementById("search_menubutton").style.display = "none";
}
/* Used by the Hide/Show button beside syntax diagrams, to toggle the */
function hideorshow(btn,obj){
var x = document.getElementById(obj);
var b = document.getElementById(btn);
if( x.style.display!='none' ){
x.style.display = 'none';
b.innerHTML='show';
}else{
x.style.display = '';
b.innerHTML='hide';
}
return false;
}
var antiRobot = 0;
function antiRobotGo(){
if( antiRobot!=3 ) return;
antiRobot = 7;
var j = document.getElementById("mtimelink");
if(j && j.hasAttribute("data-href")) j.href=j.getAttribute("data-href");
}
function antiRobotDefense(){
document.body.onmousedown=function(){
antiRobot |= 2;
antiRobotGo();
document.body.onmousedown=null;
}
document.body.onmousemove=function(){
antiRobot |= 2;
antiRobotGo();
document.body.onmousemove=null;
}
setTimeout(function(){
antiRobot |= 1;
antiRobotGo();
}, 100)
antiRobotGo();
}
antiRobotDefense();
</script>
<div class=fancy>
<div class=nosearch>
<div class="fancy_title">
Quality Management
</div>
<div class="fancy_toc">
<a onclick="toggle_toc()">
<span class="fancy_toc_mark" id="toc_mk">►</span>
Table Of Contents
</a>
<div id="toc_sub"><div class="fancy-toc1"><a href="#overview">1. Overview</a></div>
<div class="fancy-toc2"><a href="#about_this_document">1.1. About This Document</a></div>
<div class="fancy-toc1"><a href="#software_development_plan">2. Software Development Plan</a></div>
<div class="fancy-toc2"><a href="#software_life_cycle">2.1. Software Life Cycle</a></div>
<div class="fancy-toc3"><a href="#maintenance_releases">2.1.1. Maintenance Releases</a></div>
<div class="fancy-toc3"><a href="#patch_releases">2.1.2. Patch Releases</a></div>
<div class="fancy-toc2"><a href="#release_history">2.2. Release History</a></div>
<div class="fancy-toc2"><a href="#schedule">2.3. Schedule</a></div>
<div class="fancy-toc1"><a href="#software_development_environment">3. Software Development Environment</a></div>
<div class="fancy-toc1"><a href="#software_verification_plan">4. Software Verification Plan</a></div>
<div class="fancy-toc1"><a href="#software_configuration_management">5. Software Configuration Management</a></div>
<div class="fancy-toc2"><a href="#version_control">5.1. Version Control</a></div>
<div class="fancy-toc2"><a href="#survivability">5.2. Survivability</a></div>
<div class="fancy-toc2"><a href="#repositories">5.3. Repositories</a></div>
<div class="fancy-toc3"><a href="#sqlite_source_code">5.3.1. SQLite Source Code</a></div>
<div class="fancy-toc3"><a href="#sqlite_documentation_sources">5.3.2. SQLite Documentation Sources</a></div>
<div class="fancy-toc3"><a href="#sql_logic_test">5.3.3. SQL Logic Test</a></div>
<div class="fancy-toc3"><a href="#test_harness_3">5.3.4. Test Harness #3</a></div>
<div class="fancy-toc3"><a href="#dbsqlfuzz">5.3.5. Dbsqlfuzz</a></div>
<div class="fancy-toc2"><a href="#software_verification_results">5.4. Software Verification Results</a></div>
<div class="fancy-toc1"><a href="#software_requirements_standards_and_data">6. Software Requirements Standards And Data</a></div>
<div class="fancy-toc1"><a href="#software_design_and_coding_standards">7. Software Design And Coding Standards</a></div>
<div class="fancy-toc1"><a href="#problem_reports">8. Problem Reports</a></div>
</div>
</div>
<script>
function toggle_toc(){
var sub = document.getElementById("toc_sub")
var mk = document.getElementById("toc_mk")
if( sub.style.display!="block" ){
sub.style.display = "block";
mk.innerHTML = "▼";
} else {
sub.style.display = "none";
mk.innerHTML = "►";
}
}
</script>
</div>
<h1 id="overview"><span>1. </span>Overview</h1>
<p>
This is the Quality Management Plan for SQLite.
</p><p>
Quality management documents tend to expand into
binders full of incomprehensible jargon that nobody
reads. This document strives to break that pattern by
being concise and useful.
</p><p>
The inspiration for this document is
<a href="https://en.wikipedia.org/wiki/DO-178B">DO-178B</a>.
Among quality standards, DO-178B seems to have the highest usefulness
to paperwork ratio. Even so, the amount of documentation needed
for a full-up DO-178B implementation is vast. SQLite strives to be
nimble and low-ceremony, and to that end, much of the required
DO-178B documentation is omitted. We retain only those parts that
genuinely improve quality for an open-source software project such
as SQLite.
</p><p>
The purpose of this document is to brief the reader on how the
SQLite development team functions on a daily basis, as they continuously
enhance the SQLite software and work to improve its already high reliability.
The document achieves its purpose if a competent developer can be
assimilated into the development team quickly after perusing this
document.
</p><h2 id="about_this_document"><span>1.1. </span>About This Document</h2>
<p>
The quality management plan was originally composed by going through
the description of outputs in section 11 of DO-178B (pages 48 through 56)
and writing down those elements that seemed relevant to SQLite.
The text will be subsequent revised to track enhancements to the
SQLite quality process.
</p><h1 id="software_development_plan"><span>2. </span>Software Development Plan</h1>
<p>
This section is a combination of the Plan For Software Aspects Of
Certification and the Software Development Plan sections of DO-178B.
</p><p>
See <a href="about.html">About SQLite</a> for an overview of the
SQLite software and what it does and how it is different.
</p><h2 id="software_life_cycle"><span>2.1. </span>Software Life Cycle</h2>
<p>
SQLite uses a continuous integration process. The software
is under constant enhancement and refinement. The latest trunk
check-ins are frequently used internally for mission-critical
operations.
</p><p>
There is no pre-defined release cycle. Releases occur
when there is a critical mass of feature enhancements and/or
bug fixes. Historically, releases have occurred about 5 or 6
times per year.
Users of SQLite pick up new releases from the website on an
as-needed basis.
</p><h3 id="maintenance_releases"><span>2.1.1. </span>Maintenance Releases</h3>
<p>
Routine maintenance releases of SQLite contain feature enhancements,
performance enhancements, and/or fixes for non-critical issues.
The version number for major releases are of the form "3.N.0"
for some integer N. See the <a href="versionnumbers.html">version numbering conventions</a> document
for details.
</p><p>
Upcoming maintenance releases announced on the sqlite-users and
sqlite-dev <a href="support.html#mailinglists">mailing lists</a> about two weeks prior to the anticipated
release. Approximately one week prior to release, the lead developer
declares "pencils down" after which only bug-fix check-ins are
allowed on trunk. A new
<a href="https://sqlite.org/src/ext/checklist/top/index">release checklist</a>
is created and updated as needed. As items of the checklist are
verified, they are checked off and turn green. The release occurs
when all elements of the checklist are green. That process normally
takes about a week.
</p><h3 id="patch_releases"><span>2.1.2. </span>Patch Releases</h3>
<p>
Occasionally, a serious problem is found and a small "patch" release
must be made against a regular maintenance release. Patches are distinct
from maintenance releases in that the number of lines of code changed
from the previous release is small. Every effort is made to avoid
patch releases by making sure that maintenance releases are bug free.
</p><p>
Patch releases may or may not have a release checklist, depending on the
issue. This is a judgement call by the project leader.
</p><h2 id="release_history"><span>2.2. </span>Release History</h2>
<p>The documentation system automatically maintains a
<a href="chronology.html">chronology</a> of past releases, as well as a
<a href="changes.html">complete list of SQLite releases</a> with change summaries.
</p><h2 id="schedule"><span>2.3. </span>Schedule</h2>
<p>SQLite has a long-range vision.
Planning is done with the assumption that SQLite
will be used and supported through at least the year 2050.
All code is written with the idea that it will one day be read and
maintained by people not yet born. The code is carefully commented
with an eye toward helping those future developers more easily
understand the logic and the rationale behind the code.
</p><h1 id="software_development_environment"><span>3. </span>Software Development Environment</h1>
<p>
SQLite is written in portable C code.
Development work occurs on a mix of Linux, Mac, and Windows workstations.
The developers use command-line tools and eschew integrated development
environments (IDEs) whenever possible. All developers are expected to be
fluent with the unix command-line.
</p><p>
A minimum setup for compiling and testing SQLite from canonical
sources is as follows:
</p><ul>
<li> A host computer with a 32-bit or 64-bit address space.
The OS can be Linux, Mac, Windows, *BSD, Solaris, or some other.
</li><li> A C99 compiler such as GCC (including MinGW variants for Windows),
Clang, or MSVC
</li><li> A text editor of the user's choice supporting UTF-8 text.
</li><li> <a href="https://core.tcl.tk/">Tcl</a> version 8.6 or later.
</li><li> The "make" utility, or optionally "nmake" on Windows.
</li></ul>
<p>
The Tcl script language is used to help translate canonical source code
into the <a href="amalgamation.html">amalgamation</a> and to manage testing. Tcl is not used directly
by SQLite itself (unless requested by a compile-time option). End users
of the SQLite amalgamation sources do not need Tcl.
</p><p>
When building the <a href="cli.html">CLI</a>, it is helpful, but not required, to have
the following third-party libraries on hand:
</p><ul>
<li> <a href="https://zlib.net/">zLib</a>
</li><li> <a href="http://git.savannah.gnu.org/cgit/readline.git?h=devel">readline</a>
or <a href="http://thrysoee.dk/editline/">editline</a>
or <a href="https://github.com/antirez/linenoise">linenoise</a> for
command-line editing.
</li></ul>
<p>
A complete release-test of SQLite requires additional software,
</p><ul>
<li> <a href="http://www.valgrind.org/">valgrind</a>
</li><li> <a href="https://gcc.gnu.org/onlinedocs/gcc/Gcov.html">gcov</a>
</li></ul>
<p>
SQLite is expected to operate the same, and use exactly the same
<a href="fileformat2.html">on-disk format</a>,
on all modern operating systems, on all modern computer architectures,
and using all modern C compilers. The developers are constantly testing
SQLite on as many diverse platforms as they can get their hands on.
</p><h1 id="software_verification_plan"><span>4. </span>Software Verification Plan</h1>
<p>The testing process for SQLite is described in the <a href="testing.html">testing</a> document.
Testing objectives include:
</p><ul>
<li> 100% MC/DC in an as-delivered configuration
</li><li> Testing of both source code and object code
</li><li> Testing on multiple platforms and with multiple compilers
</li><li> Fuzz testing
</li><li> Code change inspection
</li><li> Dynamic and static analysis of the code
</li></ul>
<p>The testing process is controlled by the
<a href="testing.html#cklist">release testing checklists</a>. The checklists succinctly summarize
all steps necessary to fully validate SQLite, and they record when
and by whom each validation step was performed.
</p><p>The set of checklist items for release checklist is potentially
updated for each release. The content and complete
history of each release checklist are retained for the historical
record.
</p><h1 id="software_configuration_management"><span>5. </span>Software Configuration Management</h1>
<h2 id="version_control"><span>5.1. </span>Version Control</h2>
<p>
SQLite source code is managed using the <a href="https://fossil-scm.org">Fossil</a>
version control system. Fossil was written specifically to support
SQLite development. Fossil provides both distributed version control
and issue tracking.
</p><h2 id="survivability"><span>5.2. </span>Survivability</h2>
<p>
All code is archived on three separate machines:
<a href="https://www.sqlite.org">https://www.sqlite.org</a>, <a href="https://www2.sqlite.org">https://www2.sqlite.org</a>, <a href="https://www3.sqlite.org">https://www3.sqlite.org</a>.
These machines are located in different cities (Dallas, Newark, and
San Francisco, respectively) and managed by two different hosting
companies (<a href="https://linode.com">Linode</a> for the first two and
<a href="https://digitalocean.com">Digital Ocean</a> for the third).
This diversity is intended to avoid a single point of failure.
</p><p>
The main machine in Dallas <a href="https://www.sqlite.org/">https://www.sqlite.org/</a> is the primary
server and the one that most people use. The other two are considered
backups.
</p><p>
In addition to the official repositories, the developers typically
keep complete clones of all software on their personal machines.
And there are other clones scattered about the internet.
</p><h2 id="repositories"><span>5.3. </span>Repositories</h2>
<p>The SQLite source is broken up into multiple repositories, each described
in a separate section below.
</p><h3 id="sqlite_source_code"><span>5.3.1. </span>SQLite Source Code</h3>
<p>The SQLite source code and the <a href="testing.html#tcl">TCL test suite</a> are stored together
in a single repository. This one repository is all that is required to
build the SQLite. The source repository is public and is
readable by anonymous passersby on the internet.
</p><ul>
<li> Primary location: <a href="https://www.sqlite.org/src">https://www.sqlite.org/src</a>
</li><li> Backup A: <a href="https://www2.sqlite.org/src">https://www2.sqlite.org/src</a>
</li><li> Backup B: <a href="https://www3.sqlite.org/cgi/src">https://www3.sqlite.org/cgi/src</a>
</li><li> GitHub mirror: <a href="https://github.com/sqlite/sqlite/">https://github.com/sqlite/sqlite/</a>
</li></ul>
<h3 id="sqlite_documentation_sources"><span>5.3.2. </span>SQLite Documentation Sources</h3>
<p>The documentation sources include documentation text and images with the
scripts and makefile needed to construct the SQLite website documentation.
This document is contained within the documentation sources. The
document sources are kept in a separate repository distinct from the
source code. The documentation sources repository is publicly readable.
</p><p>The makefiles and scripts used to generate the documentation gather
text from baseline documents in the documentation source repository.
Additional text is extracted from comments in the SQLite source code.
Requirements coverage information is extracted from special comments in the
<a href="testing.html#tcl">TCL test suite</a> which is part of the source repository, and from
comments in the <a href="th3.html">TH3</a> test suite which is in a separate private repository.
</p><ul>
<li> Primary location: <a href="https://www.sqlite.org/docsrc">https://www.sqlite.org/docsrc</a>
</li><li> Backup A: <a href="https://www2.sqlite.org/docsrc">https://www2.sqlite.org/docsrc</a>
</li><li> Backup B: <a href="https://www3.sqlite.org/cgi/docsrc">https://www3.sqlite.org/cgi/docsrc</a>
</li></ul>
<h3 id="sql_logic_test"><span>5.3.3. </span>SQL Logic Test</h3>
<p>
The <a href="testing.html#slt">SQL Logic Tests</a> are a set of test cases designed to show that
SQLite behaves the same as other SQL database engines. These tests
are hosted in a separate code public repository.
</p><ul>
<li> Primary location: <a href="https://www.sqlite.org/sqllogictest">https://www.sqlite.org/sqllogictest</a>
</li><li> Backups on private servers
</li></ul>
<h3 id="test_harness_3"><span>5.3.4. </span>Test Harness #3</h3>
<p>
The <a href="th3.html">Test Harness #3</a> or <a href="th3.html">TH3</a> test suite is a private set of
test cases used to test SQLite to 100% MC/DC in an as-delivered
configuration. TH3 sources are served on the same servers as the
other SQLite repositories, but differ from the others in being
proprietary. The TH3 code is only accessible to SQLite developers.
</p><ul>
<li> Primary location: <a href="https://www.sqlite.org/th3">https://www.sqlite.org/th3</a>
</li><li> Backup A: <a href="https://www3.sqlite.org/cgi/th3">https://www3.sqlite.org/cgi/th3</a>
</li><li> Additional backups on private servers
</li></ul>
<h3 id="dbsqlfuzz"><span>5.3.5. </span>Dbsqlfuzz</h3>
<p>
The dbsqlfuzz module is a
<a href="https://www.llvm.org/docs/LibFuzzer.html">libFuzzer</a>-based fuzzer
for SQLite. Dbsqlfuzz fuzzes both the SQL and the database file at
the same time. Dbsqlfuzz uses a customized mutator.
</p><p>
Dbsqlfuzz seems to work better at finding problems than any other
fuzzer available. For that reason, it is kept private. We do not
want hacker gaining access to this technology.
</p><ul>
<li> Primary location: <a href="https://www.sqlite.org/dbsqlfuzz">https://www.sqlite.org/dbsqlfuzz</a>
</li><li> Backup A: <a href="https://www3.sqlite.org/cgi/dbsqlfuzz">https://www3.sqlite.org/cgi/dbsqlfuzz</a>
</li><li> Additional backups on private servers
</li></ul>
<h2 id="software_verification_results"><span>5.4. </span>Software Verification Results</h2>
<p>
Release testing proceeds by <a href="testing.html#cklist">checklist</a>. The current status and
complete change history for each checklist is stored in a separate
SQLite database file. These files are not version controlled, but
separate copies are maintained on private backup servers.
</p><p>The source code to the software that runs the checklists is stored
in its own Fossil repository at <a href="https://www.sqlite.org/checklistapp">https://www.sqlite.org/checklistapp</a>.
</p><h1 id="software_requirements_standards_and_data"><span>6. </span>Software Requirements Standards And Data</h1>
<p>In the SQLite project, the "requirements" are the project documentation.
Special markup in the documentation text indentifies individual requirements.
The requirement numbers are based on a cryptographic hash of normalized
requirement text, so that it is impossible to change the requirement text
without also changing the requirement number.
</p><p>Documentation text (and hence requirement text) is taken from the
SQLite Documentation source repository, described above, and also from
comments in the implementation. The makefiles to build the documentation
are in the documentation source repository.
</p><p>When the documentation is build, requirements are identified and labeled.
The documentation build process also scans for test cases that verify
each requirement and constructs a matrix showing which requirements have
been testing and identifying the specific test cases that test those
requirements.
</p><h1 id="software_design_and_coding_standards"><span>7. </span>Software Design And Coding Standards</h1>
<p>Objective coding standards for SQLite are minimal:
</p><ul>
<li> 2-space indentation
</li><li> No lines over 80 characters in length
</li><li> No tabs
</li></ul>
<p>All other design and coding rules are subjective. The
goal here is to make the software so that it is readable
and maintainable through the year 2050. To that end, we look
for succinct yet useful comments (no boilerplate), carefully
chosen variable names, and careful explanation of the meaning
of each data structure and the role of each code block.
</p><h1 id="problem_reports"><span>8. </span>Problem Reports</h1>
<p>All problems are fixed expeditiously. There are no lingering problems
in the sQLite software.
</p><p>The <a href="https://fossil-scm.org/">Fossil version control system</a> utilized by
SQLite contains built-in support for tracking trouble-tickets. This built-in
ticket system is used to track and document many historical problems.
</p><p>The <a href="https://fossil-scm.org/forum">SQLite Community Forum</a> is a place
where anybody on the internet can go to ask questions about or report bugs
against SQLite. Bugs found by third-parties are often reported initially
on the Forum. Forum-reported bugs will sometimes be transferred to tickets,
though recent practice as been to just deal with the bugs on the Forum.
The Forum has an excellent full-text search feature, is mirrored to
multiple machines, and is just as searchable and survivable as the ticket
system, so it seems unnecessary to duplicate Forum-originated bug reports
into the ticket system. The public locations of the Forum are:
</p><ul>
<li> Primary location: <a href="https://www.sqlite.org/forum">https://www.sqlite.org/forum</a>
</li><li> Backup A: <a href="https://www2.sqlite.org/forum">https://www2.sqlite.org/forum</a>
</li><li> Backup B: <a href="https://www3.sqlite.org/cgi/forum">https://www3.sqlite.org/cgi/forum</a>
</li></ul>
<p>
As with the source repositories, the Forum is also synced to various
private machines.
Note that because of the way Fossil works, the "backups" are more than just
read-only backups. They can also function as data inputs. All content
entered is synced to all repositories, regardless of which repository is
used for insertion.
</p><p align="center"><small><i>This page last modified on <a href="https://sqlite.org/docsrc/honeypot" id="mtimelink" data-href="https://sqlite.org/docsrc/finfo/pages/qmplan.in?m=601675a989">2022-04-18 02:55:50</a> UTC </small></i></p>
|
