Versioning

Cloud CMS provides you with content repositories that are powered by a changeset versioning model.

Changeset Versioning

It has been around for awhile and has become extremely popular since it enables you to work unimpeded, fully distributed and without any of the headaches of file locking.

Changeset Versioning: The Basics

lot like a transparency (from the old transparency projector days). This is a see-through sheet of plastic that you write on with one of those Sharpie pens. The projector projects whatever you write up onto the screen.

The cool thing about transparencies is that you can layer them, one on top of the other. What ends up getting projected is the composite of everything layered together. So when you write content, the repository basically gets a new transparency and puts your content onto it.

If you make a change, it gets out another transparency, writes your change and layers it on top.

It also does this if you delete something. It gets out a new transparency, masks (or covers up) your content so that it appears deleted.

However, your content is not really deleted. It is safe and tucked away somewhere in the stack of transparencies. It is just been hidden by the top-most transparency!

You can write as many things onto a changeset (transparency) as you want. Gitana manages the changesets for you, keeps them in a nice stack and lets you roll back changes if you make a mistake anywhere along the way.

Changeset Versioning: Branches and Merges

changesets to the branch, the length of the branch gets longer (just like the stack of transparencies gets thicker).

A read operation simple pulls information out of the repository. A write or a delete adds a new changeset.
Consider the branch shown below. The reading operation just peeks at the branch looking down from the top.
The writing operation adds a new changeset.

With just a single branch, you can still get into the situation where two people want to change the same file at the same time. Gitana lets you lock the object and all that kind of thing if you want. Or, you can create new branches so that everyone can work together at the same time and on the same things.

Here we have two workspaces. Each workspace has its own branch which was stemmed off of the Master Branch at changeset V5. The first user works on Branch A and the second user works on Branch B. Both Branch A and Branch B have a common ancestor (changeset V5 in the Master Branch).

This allows both users to do whatever they want without stepping on each other’s toes. They can update documents, delete things and create new content. At any time, they can push and pull changes between their workspace and any other workspace. This gives them a way to preview what other people are working on and merge their work into their own branches. They can also merge back to the Master Branch.

Gitana provides an elegant merge algorithm that walks the changeset history tree from the common ancestor on up. It uses a JSON differencing algorithm to allow for JSON property-level conflicts (as opposed to document level conflicts). And it provides content model and scriptable policy validation for the merged result.

The result is a highly collaborative experience that encourages your users to experiment and take a shot at contributing without the worry of blocking others or messing up the master content.