Cloud CMS automatically creates and maintains the state of the individual changesets that compose your branches as you work with content. A changeset is like a transparency for a visual projector. When you write content into a branch (via a create, update or delete), the content is written onto a changeset (or transparency). That way, the things you worked on before are never affected. They new updates are just overlaid on top.
In this sense, a branch can be thought of as a stack of changesets. There is a root changeset (where the branch starts) and a tip changeset (where the branch ends). Everything in-between constitutes the changeset history of the branch.
This portion of the API therefore is largely for advanced users. The Cloud CMS API lets you dig in and poke around at the changeset history of branches to do things like discover what changes were introduced on which changeset in the branch.
You probably don't need to do this unless you're building some really cool authoring or curation tools. Cloud CMS provides applications out-of-the-box that hopefully let you do most of the heavy lifting from an authoring viewpoint. So most of these APIs are cool but probably not very commonly used.
Changeset IDs
Most of the _doc identifiers for objects inside of Cloud CMS are GUIDs (globally unique IDs). Changesets are a bit different. Changeset IDs are stored in the _doc field but they have a special structure which looks like this:
{revision}:{guid}
As you write nodes into your branch, new changesets are layered into the branch. One at a time. Each new changeset has an incremented revision and a brand new GUID. Thus, the revision number always goes up one integer at a time. The changeset ID ends up looking something like this: 452:4b5b685c980c10f98beb
Transactions
Changesets play an important role in transaction handling for writes onto branches. When a transaction begins, a new changeset is created. All of the writes (creates, updates and deletes) which occur as part of the transaction are committed to the database and flagged with the changeset. Only once all the writes have succeeded is the changeset flipped to an 'active' state.
If a transaction fails, the changeset is not flipped to an 'active' state. Instead, the transaction rolls back and the database state is cleaned up.
Only one changeset in a branch can be written to at a time. Thus, if a transaction is started and another thread running in your application attempts to write to the branch, it will be blocked and forced to wait until the first thread completes.
Note
Drop in one of our language drivers to accelerate your development. Here are links to some of our popular Cookbooks to help you get started!