There are key articles available here to manage branching, this is a companion article which covers some core concepts to underlie understanding in support of the functional material
Key concept: changes made in the trunk automatically flow into branches
The concept of flow is one way to understand the relationship between trunk and branch but the alternate way to consider this is, once a branch is created then changes made there are a "layer" over the trunk's default flow settings.
These are all updates to the trunk which would impact the branch:
- change of a value in a property
- change of a property display name
- addition of a new property
however, once changes are made at branch level, where corresponding changes have been made in the branch , the 'layer' that is implied by the branch will take precedence over subsequent 'flow' from the trunk.
Key concept: properties and reports belong to the trunk, not to branches
- If a user has 'view' access to a trunk dataset (as well as branch:user) and 'edit' access to a branch from that trunk, these users are unable add new properties to the branch: properties are tied to the trunk dataset, there is no concept of a branched property
- It is not possible to pin a report from a branch, it would only possible to reference those reports built directly in the trunk which users (in branches) have access. Permissions for a report are the same as for datasets
Key concept: pushback applies to the entire branch
- A group of nodes can be accepted for change by creating multiple branches from a single trunk dataset; these branches would be a filtered view of the nodes and then only those nodes will be pushed into the trunk.
- Outside of this there is currently no way to push some of the changes within a branch apart from the potentially lengthy task of reverting changes not wanted within pushing, saving, repeating the reverted changes and then saving again.
Key concept: when reverting, data will be reverted to the trunk
- When reverting, data will be reverted to the trunk (rather than any other given branch) data for those reversions that we make.
- When reverting, it is possible to select any set of nodes and for those nodes, you can revert any one set of properties at a time.
If the requirement is to revert a particular property, drag all nodes onto the revert button, then select the properties that you want to revert.
If the requirement is to revert all data for a particular group of nodes, drag the set of nodes that are to be reverted onto the revert button
Key concept: running a delta on a branched data set
If wanting to do a delta on a branched data set, e.g.
- I have my original structure (A),
- I make a branch (B) and make some changes on B,
- then I want a chart showing the delta of head count by department from A to B
- clone the original structure (A) to make dataset C,
- then create a branch (B) off dataset C and delta B against A.
What happens next depends on the desired behaviour; if pushing the branch into C now makes it the baseline structure, C would have to be manually merged into A.
Note that if you make a branch off a data set, and make changes to the branch, you would have to copy + paste from one dataset to another to keep up to date.
Key concept: Changes Report currently does not support evaluated/generated properties.
- The Changes Report currently does not support evaluated/generated properties.
- (Please note that depth, outgoing_count etc are correctly named calculated properties, not metadata properties.)
- The setproperty method, combined with on-demand, is an effective method to address the use case for calculated properties.
- It is possible to create hard copies of these properties using a setproperty expression and on demand evaluation mode in order for them to appear in the dashboard controls.
Contributors: Tom Simpkins and El No