From Sense/Net 6.0 Wiki
[edit] Overview
| 1.0 Approved
|
| 1.1 Rejected
|
| 2.0 Approved
|
| 2.1 Draft
|
| 3.0 Approved
|
|
Typical content version history
|
Versioning, also known as revision control, is the management of changes to documents and other information stored in a file system or repository.
The main goal of versioning is to prevent information from being overwritten or deleted during everyday work with documents. Changes are kept track of, and a mechanism is offered to restore a particular document to a previous version.
The versioning system of Sense/Net 6.0 also provides mechanisms for keeping the published version of a document under heavy editing visible to outside users, while you continue to work on the latest, draft version.
[edit] Versioning in Sense/Net 6.0
In Sense/Net 6.0, versioning is disabled by default. It can be enabled for folders or content lists, by setting the value of the Versioning Mode field. Subfolders inherit versioning settings by default.
Versioning Mode settings for folders:
| None
| The default setting of the Root folder, no versioning.
|
| Inherited
| The folder inherits its versioning mode from its parent. This is the default setting for all other content.
|
| Major only
| Only major versions (1.0, 2.0,...) are preserved.
|
| Major and minor
| Every version is preserved (1.0, 1.1, 1.2,...).
|
When a new Content is created in the Content Repository with versioning enabled, it is assigned the initial version number, depending on the versioning mode. Changes made to the document will result in a bump of the version number, with old versions tracked for possible rollbacks.
[edit] Approval
Sense/Net 6.0 also introduces a basic approval functionality. Regardless of the versioning mode in use, approval can be enabled to control changes.
If approval is required for a certain Content, after changes has been made to the document, the system creates a version pending for approval. This version is visible only for administrators and users who have permission to Approve or Reject it. If the Content is approved, its version number is bumped according to the versioning mode, and gets the A ("approved") flag.
This method provides an extra line of defense for keeping mission critical content error free.
[edit] Content states
Content in the Repository can have several non-numeric version states:
| A
| APPROVED
| Only a major version can be in approved state: 1.0A or 2.0A. The last approved version of the content is that users with low level permission can see.
|
| L
| LOCKED
| When a content is locked, only the user who locked it can modify it.
|
| D
| DRAFT
| A draft version is only visible to users who have permission to see minor versions of a content. Any other user will see the last public version.
|
| P
| PENDING
| When approval is enabled in a folder or list, then contents cannot be published without approval. After sending a content for approval it remains in pending for approval state, until somebody with sufficient rights approves it.
|
| R
| REJECTED
| If a content is not correct, the user with approving rights can reject it. This means it is not published and should be refined.
|
[edit] Content behavior if versioning is enabled
[edit] Major only mode
After a user finished editing a Content, the major version number is bumped by default: eg. 1.0 becomes 2.0. This means the new version is automatically published, and will be served to all users requesting the content in question.
[edit] Major and minor mode
In this mode, saving a Content bumps its minor version number. Content with minor version (for example 1.2, 3.5, anything but x.0) are considered working versions, and aren't served to guest users - they get the latest major version instead. (Eg. if a document's latest version is 5.4D, guest users will be served 5.0A, the latest public version.)
In this versioning mode, bumping the major version and thus publishing the changes can be done by pressing the Publish button.
[edit] Check out and Check in
You may have already had trouble with scenarios where both you and a colleague were making changes to the same document on a corporate file server. If you saved first, and your colleague second, all your changes were overwritten and lost. The Check out / Check in locking mechanism is intended to prevent such problems.
Before making changes to a Content, you can - and indeed, should, if you are working in a multi-user, production environment - Check the Content out. This acts as a write lock, enabling other users to access it for reading, but not for modifications.
You may save several times during work, and Check in when you are done, lifting the lock.
In None and Major only versioning modes, Checking out also provides a way to separate the working version of a Content from the public version. Guest users will see the Content's previous state (before it has been Checked out), until the changes have been Checked in.
[edit] Undo changes
If you checked out a content, edited it, but decide to drop your changes, you can do so by pressing the Undo changes button. This reverts the content to the state before you checked it out.
Administrators can have a force undo changes permission. This means they can drop changes to a locked content made by any other user. This is useful when somebody checked out a content and she cannot check it in for some reason, but the content needs to be edited by somebody else.
[edit] Examples
In this section you can see examples of how content version numbers changing if you work with the content. If you want to see the actions you can perform in particular state of a content, visit the enabled versioning actions page.
[edit] Versioning: None, Approving: Off
|
| Check out
|
| Check in
|
|
[edit] Versioning: Major, Approving: Off
|
| Check out
|
| Check in
|
|
[edit] Versioning: Major and minor, Approving: Off
|
| Check out
|
| Check in
|
| Check out
|
| Publish
|
|
[edit] Versioning: None, Approving: On
|
| Reject
|
| Check out
|
| Check in
|
| Approve
|
|
[edit] Versioning: Major, Approving: On
|
| Approve
|
| Check out
|
| Check in
|
| Reject
|
| Check out
|
| Check in
|
| Approve
|
|
[edit] Versioning: Major and minor, Approving: On
[edit] Changing Versioning or Approving mode
[edit] Related pages
