Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • hive hive
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 86
    • Issues 86
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 22
    • Merge requests 22
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • hive
  • hivehive
  • Wiki
  • Home

Last edited by Dan Notestein Jul 01, 2020
Page history

Home

General notes on hive development process

Branching methodology

Hived is being developed using a master/develop branching process. Production builds should always be made from the master branch, and only production fixes should be merged to the master branch except when an official release is ready. Normal development changes should be merged to the develop branch. We are using this process to enable fixes to be made to production systems without requiring the production fixes to reside in branches.

A side-effect of this is that someone should always be able to build a production node using the head of the master branch.

If you plan to commit your own remote branches to the repo (if you're working for more than a day or two in a branch, this is recommended), please add a prefix with your initials, so that a casual viewer of the branches list can see who is responsible for the branch.

Coding conventions

  • 2 space indention (DO NOT USE TABS)
  • Avoid the use of acronyms and abbreviations in source code (i.e. in variable names) and file names unless it is standard abbreviation/acronym of the English language.

Testing methodology

Unit tests in the C++ source code are used as first-level tests.

Python-based API tests are used to verify the functionality of API functions that are exposed to outside processes.

A reindexing test verifies that hived is able to process existing blocks in the blockchain. Currently this is a simple pass/fail test (the test fails if the node isn't able to process all the blocks in the blockchain). As this is a computationally intensive test, it's also a performance test.

Future testing will combine reindex testing with the generation of state files to verify that blocks are correctly processed. These tests will compare the state files generated by new versions of hived versus the state files of old versions of hived.

Clone repository
  • Test coverage with tested cases
  • Home