Email this Page Log Support Call Send Feedback Print

Previous Topic

Next Topic

Book Contents

Book Index

Version Control - An Explanation

The purpose of Version control is to allow you to create new versions of an object, but still retain the original. How and when you use them is really up to you. The most common use for them is probably to keep track of revisions, but they are ideal for creating proposed changes to an object - you can create a new version of an object, and then when you're happy with it, make that version active. You can revert back to an old version at any time, by making the "redundant" version active again, but only one version of an object can be active at any one time.

Probably the biggest factor to consider, is whether an old "version" of a document will change. For example, let's say you're a software company and you release a new version of your application. Do you continue updating the documentation for the older release? If so, it'd generally mean you'd need to have two "versions" of the documentation active at the same time – and so would need to use two separate objects.

Note: Version control is only available in the multi-user (Workgroup and Enterprise) editions. As an alternative approach to version control, if you wanted to retain a full "read only" copy of a Book, you could archive the old Book by creating a backup of the library and/or the published output, and store this separately. It is then still available for future reference.

The other important thing to note, is how the version status of an object affects its ability to be involved in relationships with other objects. The order objects are made active/redundant also plays a major part. Only the active version of an object can be involved in a relationship where it is the child, as when it is made active, Author-it automatically replaces the child relationship with the active version.

When you make a version of an object active, several things happen:

  • The previous version becomes redundant (read-only).
  • Any child relationships that the previous version was involved in are replaced with the new version, but only where the parent in that relationship is not already Redundant.
  • The new version becomes active.

Let's look at an example where you have already produced version 1 of a Book and that Book contains a number of Topic objects which are also version 1. You now want to create a new version of the Book, but only a few of the Topics need to change. You still want the ability to publish the old version of the Book as it is.

First you create a new version of the Book object, and make that new version active. This makes the old version redundant (and read-only).

Next, you create a new version of the Topic you want to change. After making the changes to the new version of the Topic, you make that new version active. Just like for the Book, the old version of the Topic becomes redundant. Additionally, the relationship that the new Book has with the old version of the Topic now changes to be with the new version of the Topic. However, the relationship that the old version of the Book has to the old version of the Topic is retained, because the parent in the relationship (i.e. the old Book) was already redundant.

When you're using version control in Author-it, that version has an object status of either: Active, Inactive, or Redundant.

  • Active - The current active version of an object. There can only be one active version of an object.
  • Inactive - A proposed version of an object. When you create a new version of an object it is created as inactive. You can have many inactive versions of an object, and these versions can all be edited.
  • Redundant - An old version of an object. When an inactive version of an object is made active, the earlier version becomes redundant. There can be many redundant versions of an object, and these versions are always read-only.

You can revert back to an old version of an object at any time, by making the "redundant" version active again. When doing so, the later version is made inactive - not redundant. This means the later (and now inactive) version can still be edited. Remember though, that only active objects can be included as a child in a relationship – so inactive topics cannot be added to a book.

Top of Page Email this Page Log Support Call Send Feedback Print