arrow-down
    1. Widgets
  1. IAM
    1. Virtual apps
    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
      1. Field set
      2. Item set
      3. Option set
      4. Mixins
      5. Localization
    3. Content Types
    4. X-data
    5. Macros
    6. Custom styles
    7. Sites
      1. Regions
      2. Part component
      3. Layout component
      4. Text component
      5. Fragments
      6. Filtering
      7. Component indexing
      8. Visual editor
    8. Page templates
    1. Sandboxes
    2. Code
    3. Building
    4. Configuration
    1. Globals
    2. HTTP
    3. Controllers
    4. Filters
    5. Events
    6. Websocket
    7. Error handler
    8. ID provider
    9. Tasks
    10. Localization
    11. Mappings
    12. Components
    13. Processors
    14. Contributions
    15. Templating
    16. Main controller
    17. Java bridge
      1. Webapp Engine
        1. Image service
        2. Component service
      2. Admin Engine
      3. Asset service
      4. HTTP service
      5. IDprovider service
    1. Task engine
    2. Management Endpoint
    3. 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
    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
  2. Audit Logs
    1. Upgrade Notes
    2. Upgrading Apps

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

AI-powered search

Juke AI