Documentation Source Text

Artifact [03da7741e5]

Artifact 03da7741e52bb44becdb23f86988b633afd24c04bbe4e8f1ab0d55a9a8acfe4f:

<title>How To Download Canonical SQLite Source Code</title>
<tcl>hd_keywords {canonical source code} {get the canonical source code}</tcl>



<p>Most programmers compile SQLite into their applications using
the [amalgamation].  The [amalgamation] is C-code but it is not
"source code".  The [amalgamation] is generated from source code
by scripts.

<p>This document describes how to obtain the canonical source code
for SQLite - the raw source files from which the amalgamation is
built.  See the [How To Compile SQLite] page for additional information
on what to do with the canonical source code once it is obtained.

<h1>Direct Downloads</h1>

<p>Snapshots of official releases of SQLite source code can often
be obtained directly from the [download page] of the SQLite website.
Even if the specific version desired is not listed on the download page,
the naming conventions are fairly clear and so programmers can often
guess the name of an historical release and download it that way.

<h1>Obtaining Code Directly From the Version Control System</h1>

<p>For any historical version of SQLite, the source tree can be obtained
from the [|Fossil] version control system,
either downloading a tarball or ZIP archive for a specific version, or
by cloning the entire project history.

<p>SQLite sources are maintained on three geographically dispersed

[] (Dallas)<br>
[] (Newark)<br>
[] (San Francisco)<br>

<p>The documentation is maintained in separate source repositories on
those same servers:

[] (Dallas)<br>
[] (Newark)<br>
[] (San Francisco)<br>

<p>To download a specific historical version, first locate the specific
version desired by visiting the timeline page on one of these servers
(for example: []).  If
you know the approximate date of the version you want to download, you
can add a query parameter like "c=YYYY-MM-DD" to the "timeline" URL to
see a timeline centered on that date.  For example, to see all the check-ins
that occurred around August 26, 2013, visit
If you are looking for an official release, visit the
[chronology] page, click on the date to the left of the release
you are looking for, and that will take you immediately to the
check-in corresponding to the release.

<p>Once you locate a specific version, click on the hyperlink for that
version to see the "Check-in Information Page".
Then click on either the "Tarball" link or the
"ZIP archive" link to download the complete source tree.

<tcl>hd_fragment {clone} {clone the entire repository}</tcl>
<h1>Cloning The Complete Development History</h1>

<p>To clone the entire history of SQLite, first go to the
[] page and grab a precompiled binary
for the Fossil version control program.  Or get the source code on the
same page and compile it yourself.

<p>As of 2017-03-12, you must use Fossil version
2.0 or later for the following instructions to work.  
The SQLite repository started using
artifacts named using SHA3 hashes instead of SHA1 hashes on that date,
and Fossil 2.0 or later is needed in order to understand the new SHA3
hashes.  To find out what version of Fossil you are running, 
type "fossil -v".</p>

<p>Fossil is a completely stand-alone
program, so install it simply by putting the "fossil" or "fossil.exe"
executable someplace on your $PATH or %PATH%.  After you have Fossil
installed, do this:

fossil clone sqlite.fossil

<p>The command above
will make a copy of the complete development history of
SQLite into the "sqlite.fossil" file on your computer.  Making this copy
takes about a minute and uses about 32 megabytes of transfer.  After
making the copy, "open" the repository by typing:

fossil open sqlite.fossil

<p>This second command will "checkout" the latest check-in from the SQLite
source tree into your current directory.  Subsequently, you can easily switch
to a different version by typing:

fossil update VERSION

<p>Where VERSION can be a branch name (like "trunk" or "session") to get the
latest check-in on a specific branch, or VERSION can be a SHA1 hash or a
prefix of a SHA1 hash for a specific check-in, or VERSION can be a tag
such as "version-3.8.8".  Every time you run "fossil update" it will
automatically reach out to the original repository at to obtain new check-ins that might have been
made by others since your previous update.