Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Update the README.md file at the top level to talk about how to deal with version names and how to verify the code in Git mirrors. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
e8c87a0ac1bf434c12a8ab602e7913a8 |
User & Date: | drh 2019-03-17 23:44:16.475 |
Context
2019-03-17
| ||
23:59 | New hyperlink on the README.md file. (check-in: cc5ab96715 user: drh tags: trunk) | |
23:44 | Update the README.md file at the top level to talk about how to deal with version names and how to verify the code in Git mirrors. (check-in: e8c87a0ac1 user: drh tags: trunk) | |
2019-03-15
| ||
19:08 | Back out the change to support Fuchsia, since it turns out fuchsia does not like dot-file locks. (check-in: 1d801a3b2c user: drh tags: trunk) | |
Changes
Changes to README.md.
1 2 3 4 5 6 7 | <h1 align="center">SQLite Source Repository</h1> This repository contains the complete source code for the [SQLite database engine](https://sqlite.org/). Some test scripts are also included. However, many other test scripts and most of the documentation are managed separately. | > | > > > > > | > > > > | > > | > > > < < < | 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 | <h1 align="center">SQLite Source Repository</h1> This repository contains the complete source code for the [SQLite database engine](https://sqlite.org/). Some test scripts are also included. However, many other test scripts and most of the documentation are managed separately. ## Version Control SQLite sources are managed using the [Fossil](https://www.fossil-scm.org/), a distributed version control system that was specifically designed and written to support SQLite development. The Fossil repository contains the urtext. If you are reading this on GitHub or some other Git repository or service, then you are looking at a mirror. The names of check-ins and other artifacts in a Git mirror are different from the official names for those objects. The offical names for check-ins are found in a footer on the check-in comment for authorized mirrors. The official check-in name can also be seen in the `manifest.uuid` file in the root of the tree. Always use the official name, not the Git-name, when communicating about an SQLite check-in. If you pulled your SQLite source code from a secondary source and want to verify its integrity, there are hints on how to do that in the [Verifying Code Authenticity](#vauth) section below. ## Obtaining The Code If you do not want to use Fossil, you can download tarballs or ZIP archives or [SQLite archives](https://sqlite.org/cli.html#sqlar) as follows: * Lastest trunk check-in as [Tarball](https://www.sqlite.org/src/tarball/sqlite.tar.gz), [ZIP-archive](https://www.sqlite.org/src/zip/sqlite.zip), or [SQLite-archive](https://www.sqlite.org/src/sqlar/sqlite.sqlar). |
︙ | ︙ | |||
290 291 292 293 294 295 296 297 298 299 300 301 302 303 | * **ext/misc/json1.c** - This file implements the various JSON functions that are build into SQLite. There are many other source files. Each has a succinct header comment that describes its purpose and role within the larger system. ## Contacts The main SQLite webpage is [http://www.sqlite.org/](http://www.sqlite.org/) with geographically distributed backups at [http://www2.sqlite.org/](http://www2.sqlite.org) and [http://www3.sqlite.org/](http://www3.sqlite.org). | > > > > > > > > > > > > > > > > > > > > > > > > > > > | 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 | * **ext/misc/json1.c** - This file implements the various JSON functions that are build into SQLite. There are many other source files. Each has a succinct header comment that describes its purpose and role within the larger system. <a name="vauth"></a> ## Verifying Code Authenticity If you obtained an SQLite source tree from a secondary source, such as a GitHub mirror, and you want to verify that it has not been altered, there are a couple of ways to do that. If you have an official release version of SQLite, and you are using the `sqlite3.c` amalgamation, then SHA3-256 hashes for the amalgamation are available in the [change log](https://www.sqlite.org/changes.html) on the official website. After building the `sqlite3.c` file, you can check that is authentic by comparing the hash. This does not ensure that the test scripts are unaltered, but it does validate the deliverable part of the code and only involves computing and comparing a single hash. For versions other than an official release, or if you are building the `sqlite3.c` amalgamation using non-standard build options, the verification process is a little more involved. The `manifest` file at the root directory of the source tree ([example](https://sqlite.org/src/artifact/bd49a8271d650fa8)) contains either a SHA3-256 hash (for newer files) or a SHA1 hash (for older files) for every source file in the repository. You can write a script to extracts hashes from `manifest` and verifies the hashes against the corresponding files in the source tree. The SHA3-256 hash of the `manifest` file itself is the official name of the version of the source tree that you have. The `manifest.uuid` file should contain the SHA3-256 hash of the `manifest` file. If all of the above hash comparisons are correct, then you can be confident that your source tree is authentic and unadulterated. ## Contacts The main SQLite webpage is [http://www.sqlite.org/](http://www.sqlite.org/) with geographically distributed backups at [http://www2.sqlite.org/](http://www2.sqlite.org) and [http://www3.sqlite.org/](http://www3.sqlite.org). |