a31c8aa Add NewAppendableFile for win32 environment 1913d71 Merge upstream LevelDB 1.19 3080a45 Increase leveldb version to 1.19. fa6dc01 A zippy change broke test assumptions about the size of compressed output. Fix the tests by allowing more slop in zippy's behavior. ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=123432472 06a191b fix problems in LevelDB's caching code a7bff69 Fix LevelDB build when asserts are enabled in release builds. (#367) ea992b4 Change std::uint64_t to uint64_t (#354) e84b5bd This CL fixes a bug encountered when reading records from leveldb files that have been split, as in a [] input task split. 3211343 Deleted redundant null ptr check prior to delete. 7306ef8 Merge pull request #348 from randomascii/master 6b18316 Fix signed/unsigned mismatch on VC++ builds adbe3eb Putting build artifacts in subdirectory. 2d0320a Merge pull request #329 from ralphtheninja/travis-badge dd1c3c3 add travis build badge 43fcf23 Merge pull request #328 from cmumford/master 9fcae61 Added a Travis CI build file. dac40d2 Merge pull request #284 from ideawu/master 8ec241a Merge pull request #317 from falvojr/patch-1 5d36bed Merge pull request #272 from vapier/master 4753c9b Added a contributors section to README.md e2446d0 Merge pull request #275 from paulirish/patch-1 706b7f8 Resolve race when getting approximate-memory-usage property 3c9ff3c Only compiling TrimSpace on linux. f8d205c Including atomic_pointer.h in port_posix 889de31 Let LevelDB use xcrun to determine Xcode.app path instead of using a hardcoded path. 528c2bc Add "approximate-memory-usage" property to leveldb::DB::GetProperty 359b6bc Add leveldb::Cache::Prune 50e77a8 Fix size_t/int comparison/conversion issues in leveldb. 5208e79 Added leveldb::Status::IsInvalidArgument() method. ce45404 Suppress error reporting after seeking but before a valid First or Full record is encountered. b9afa1f include <assert> -> <cassert> edf2939 Update README.md 65190ac Will not reuse manifest if reuse_logs options is false. ac1d69d LevelDB now attempts to reuse the preceding MANIFEST and log file when re-opened. 76bba13 fix indent 8fcceb2 log compaction output file's level along with number 0e0f074 documentation. improved link c85addc readme: improved documentation link ceff6f1 Fix Android/MIPS build. 77948e7 Add benchmark that measures cost of repeatedly opening the database. 34ad72e Move header guard below copyright banner. a75d435 Clean up layering of storage/leveldb/... b234f65 Added a new fault injection test. c4c38f9 Add arm64 support to leveldb. cea9b10 Fixed incorrect comment wording for Iterator::Seek. c00c569 Deleted old README file. git-subtree-dir: src/leveldb git-subtree-split: a31c8aa408d5594830f7cb20ead1ef1dff51b79e
3.5 KiB
Bitcoin Core integration/staging tree
What is Bitcoin?
Bitcoin is an experimental digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: managing transactions and issuing money are carried out collectively by the network. Bitcoin Core is the name of open source software which enables the use of this currency.
For more information, as well as an immediately useable, binary version of the Bitcoin Core software, see https://bitcoin.org/en/download, or read the original whitepaper.
License
Bitcoin Core is released under the terms of the MIT license. See COPYING for more information or see https://opensource.org/licenses/MIT.
Development Process
The master
branch is regularly built and tested, but is not guaranteed to be
completely stable. Tags are created
regularly to indicate new official, stable release versions of Bitcoin Core.
The contribution workflow is described in CONTRIBUTING.md.
The developer mailing list should be used to discuss complicated or controversial changes before working on a patch set.
Developer IRC can be found on Freenode at #bitcoin-core-dev.
Testing
Testing and code review is the bottleneck for development; we get more pull requests than we can review and test on short notice. Please be patient and help out by testing other people's pull requests, and remember this is a security-critical project where any mistake might cost people lots of money.
Automated Testing
Developers are strongly encouraged to write unit tests for new code, and to
submit new unit tests for old code. Unit tests can be compiled and run
(assuming they weren't disabled in configure) with: make check
. Further details on running
and extending unit tests can be found in /src/test/README.md.
There are also regression and integration tests of the RPC interface, written
in Python, that are run automatically on the build server.
These tests can be run (if the test dependencies are installed) with: qa/pull-tester/rpc-tests.py
The Travis CI system makes sure that every pull request is built for Windows, Linux, and OS X, and that unit/sanity tests are run automatically.
Manual Quality Assurance (QA) Testing
Changes should be tested by somebody other than the developer who wrote the code. This is especially important for large or high-risk changes. It is useful to add a test plan to the pull request description if testing the changes is not straightforward.
Translations
Changes to translations as well as new translations can be submitted to Bitcoin Core's Transifex page.
Translations are periodically pulled from Transifex and merged into the git repository. See the translation process for details on how this works.
Important: We do not accept translation changes as GitHub pull requests because the next pull from Transifex would automatically overwrite them again.
Translators should also subscribe to the mailing list.