mirror of
https://github.com/XRPLF/clio.git
synced 2025-11-04 20:05:51 +00:00
chore: Unify how we deal with branches (#2320)
This commit is contained in:
4
.github/workflows/build.yml
vendored
4
.github/workflows/build.yml
vendored
@@ -2,9 +2,9 @@ name: Build
|
|||||||
|
|
||||||
on:
|
on:
|
||||||
push:
|
push:
|
||||||
branches: [master, release/*, develop]
|
branches: [release/*, develop]
|
||||||
pull_request:
|
pull_request:
|
||||||
branches: [master, release/*, develop]
|
branches: [release/*, develop]
|
||||||
paths:
|
paths:
|
||||||
- .github/workflows/build.yml
|
- .github/workflows/build.yml
|
||||||
|
|
||||||
|
|||||||
3
.github/workflows/pre-commit.yml
vendored
3
.github/workflows/pre-commit.yml
vendored
@@ -3,8 +3,7 @@ name: Run pre-commit hooks
|
|||||||
on:
|
on:
|
||||||
pull_request:
|
pull_request:
|
||||||
push:
|
push:
|
||||||
branches:
|
branches: [develop]
|
||||||
- develop
|
|
||||||
workflow_dispatch:
|
workflow_dispatch:
|
||||||
|
|
||||||
jobs:
|
jobs:
|
||||||
|
|||||||
6
.github/workflows/upload_conan_deps.yml
vendored
6
.github/workflows/upload_conan_deps.yml
vendored
@@ -11,8 +11,7 @@ on:
|
|||||||
default: false
|
default: false
|
||||||
type: boolean
|
type: boolean
|
||||||
pull_request:
|
pull_request:
|
||||||
branches:
|
branches: [develop]
|
||||||
- develop
|
|
||||||
paths:
|
paths:
|
||||||
- .github/workflows/upload_conan_deps.yml
|
- .github/workflows/upload_conan_deps.yml
|
||||||
|
|
||||||
@@ -24,8 +23,7 @@ on:
|
|||||||
- conanfile.py
|
- conanfile.py
|
||||||
- conan.lock
|
- conan.lock
|
||||||
push:
|
push:
|
||||||
branches:
|
branches: [develop]
|
||||||
- develop
|
|
||||||
paths:
|
paths:
|
||||||
- .github/workflows/upload_conan_deps.yml
|
- .github/workflows/upload_conan_deps.yml
|
||||||
|
|
||||||
|
|||||||
@@ -20,8 +20,8 @@ if (BRANCH STREQUAL "")
|
|||||||
set(BRANCH "dev")
|
set(BRANCH "dev")
|
||||||
endif ()
|
endif ()
|
||||||
|
|
||||||
if (NOT (BRANCH MATCHES master OR BRANCH MATCHES release/*)) # for develop and any other branch name
|
if (NOT (BRANCH MATCHES release/*))
|
||||||
# YYYYMMDDHMS-<branch>-<git-rev>
|
# for develop and any other branch name YYYYMMDDHMS-<branch>-<git-rev>
|
||||||
set(GIT_COMMAND show -s --date=format:%Y%m%d%H%M%S --format=%cd)
|
set(GIT_COMMAND show -s --date=format:%Y%m%d%H%M%S --format=%cd)
|
||||||
execute_process(
|
execute_process(
|
||||||
COMMAND ${GIT_EXECUTABLE} ${GIT_COMMAND} WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} OUTPUT_VARIABLE DATE
|
COMMAND ${GIT_EXECUTABLE} ${GIT_COMMAND} WORKING_DIRECTORY ${CMAKE_CURRENT_SOURCE_DIR} OUTPUT_VARIABLE DATE
|
||||||
|
|||||||
@@ -6,7 +6,7 @@ To support additional database types, you can create new classes that implement
|
|||||||
|
|
||||||
## Data Model
|
## Data Model
|
||||||
|
|
||||||
The data model used by Clio to read and write ledger data is different from what `rippled` uses. `rippled` uses a novel data structure named [_SHAMap_](https://github.com/ripple/rippled/blob/master/src/ripple/shamap/README.md), which is a combination of a Merkle Tree and a Radix Trie. In a SHAMap, ledger objects are stored in the root vertices of the tree. Thus, looking up a record located at the leaf node of the SHAMap executes a tree search, where the path from the root node to the leaf node is the key of the record.
|
The data model used by Clio to read and write ledger data is different from what `rippled` uses. `rippled` uses a novel data structure named [_SHAMap_](https://github.com/XRPLF/rippled/blob/develop/src/xrpld/shamap/README.md), which is a combination of a Merkle Tree and a Radix Trie. In a SHAMap, ledger objects are stored in the root vertices of the tree. Thus, looking up a record located at the leaf node of the SHAMap executes a tree search, where the path from the root node to the leaf node is the key of the record.
|
||||||
|
|
||||||
`rippled` nodes can also generate a proof-tree by forming a subtree with all the path nodes and their neighbors, which can then be used to prove the existence of the leaf node data to other `rippled` nodes. In short, the main purpose of the SHAMap data structure is to facilitate the fast validation of data integrity between different decentralized `rippled` nodes.
|
`rippled` nodes can also generate a proof-tree by forming a subtree with all the path nodes and their neighbors, which can then be used to prove the existence of the leaf node data to other `rippled` nodes. In short, the main purpose of the SHAMap data structure is to facilitate the fast validation of data integrity between different decentralized `rippled` nodes.
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user