Docs Developer Site
Enonic XP
arrow-down
    1. Widgets
    1. ID providers
    2. System ID provider
    3. Users and groups
    4. Roles
    1. Projects
    2. Layers
        1. AttachmentUploader
        2. Checkbox
        3. Combobox
        4. ContentSelector
        5. ContentTypeFilter
        6. CustomSelector
        7. Date
        8. DateTime
        9. Double
        10. GeoPoint
        11. HtmlArea
        12. ImageSelector
        13. Long
        14. MediaSelector
        15. Radiobutton
        16. Tag
        17. TextArea
        18. TextLine
        19. Time
      2. Field set
      3. Item set
      4. Option set
      5. Mixins
      6. Localization
    4. Content Types
    5. X-data
    6. Macros
    7. Custom styles
    8. Sites
      1. Regions
      2. Part component
      3. Layout component
      4. Text component
      5. Fragments
      6. Filtering
      7. Component indexing
      8. Visual editor
    10. Page templates
  4. Applications
    1. Sandboxes
    2. Code
    3. Building
    4. Configuration
    5. TypeScript
      1. Controllers
      2. Globals
      3. HTTP
      4. Events
      5. Error handler
      6. Filters
      7. ID provider
      8. Tasks
      9. Templating
      10. Localization
      11. Websocket
      12. Mappings
      13. Components
      14. Processors
      15. Contributions
      16. Main controller
      17. Java bridge
      1. Admin API
      2. Application API
      3. Auditlog API
      4. Authentication API
      5. Cluster API
      6. Common API
      7. Content API
      8. Context API
      9. Event API
      10. Export API
      11. Grid API
      12. I18N API
      13. IO API
      14. Mail API
      15. Node API
      16. Portal API
      17. Project API
      18. Repo API
      19. Scheduler API
      20. Schema API
      21. Tasks API
      22. Value API
      23. VHost API
      24. Websocket API
      1. Webapp Engine
        1. Image service
        2. Component service
      3. Admin Engine
      4. Asset service
      5. HTTP service
      6. IDprovider service
    2. Task engine
    3. Management Endpoint
    4. Statistics Endpoint
    1. Nodes and repos
    2. Properties
    3. Indexing
    4. Branches
    5. Queries (NoQL)
    6. Queries (DSL)
    7. Filters
    8. Aggregations
    9. Highlighting
    10. Editors
    1. Strategies
    2. Distributions
    3. Docker image
    4. Vhosts
    5. Configuration
    6. Backup & restore
    7. Systemd
    8. Clustering
  9. Audit Logs
    1. Upgrade Notes
    2. Upgrading Apps
Developer Docs Xp Stable Storage Branches

Repo branches

Contents

Inspired by Git, XP repos supports a concept called branches. All repos ship with a default branch called master. This means that the fully qualified location of a node consists of:

<repo> + <branch> + <node ID | path>

Any number of branches could be added to facilitate your data model. Branches are typically ideal for facilitating long running transactions.

As an example, XP’s CMS API makes use of two branches draft and master to support the editorial workflow, with previewing and bulk publishing of changes.

Pushing

XP provides advanced features such as diffing to see the changes between two branches. Additionally, the API provides features for "pushing" changes from one branch to another. The push operation automatically handles dependencies and and missing parent items to ensure the result is consistent.

From the CMS API, the push operation is known as "publish".

XP repos currently don’t offer conflict resolution or merging functionality. As such, conflict resolution must either be handled by the application itself, or the application must write data in a way that avoids creating conflicts.

Example usage

Consider the 'Oslo' and 'Enonic' nodes below:

nodes

There will be two node-versions in the repository, with data persisted in both blobstore and search index:

node versions

A node-version is a representation of a node’s properties. A node-version has no knowledge of name, parent or other meta-data: just the properties of a node. At the same time, the targeted branch (named 'draft' in this example) gets two entries:

branch initial

The node-versions are now a part of a tree-structure, based on the node’s name and parent. If we push the content of branch 'draft' to the default branch 'master', we end up with something like this:

branch push

At the moment, there are two branches pointing to the same node-versions. This means that a single node version can exist in several branches with different structures. Now, consider that the 'oslo' - node is updated and stored to the 'draft'-branch, resulting in a new node-version with the same id and an updated pointer from the branch:

branch diff

The two branches now point to different node-versions of the 'oslo' node. Again, doing a push-operation from 'draft' to 'master' will result in both nodes pointing to the same node-versions:

branch push 2

Contents

Contents