When you initially import assets into ATG Content Administration, the VersionManager
creates version 1 of every imported asset. In the case of file assets, file names are appended with the string #1
.
When a user adds an existing asset to a project, the VersionManager
checks out the head version from the main branch by copying the asset and assigning the next available version number to this copy. The VersionManager
then adds the new version to the project’s workspace. Within the project, users can modify this asset’s workspace version, or delete it from the versioning system. When the user completes the project, its workspace assets are checked into main, and the workspace itself is marked as checked in.
The versioning system typically deals with one of the following scenarios:
A Single User Modifies an Asset and checks it in.
Multiple Users Modify an Asset at the same time.
Single User Modifies an Asset
The following diagram shows how an asset is modified in a project and versioned.
Step 1: The user adds version 2 of foo.html
to project A. The VersionManager
performs these steps:
Checks out version 2 by creating a copy.
Assigns it the next available version number: version 3.
Adds version 3 to the project’s workspace.
The user can now modify or delete version 3 of foo.html
.
Step 2: The user completes project A. The VersionManager
checks in the asset versions in project A’s workspace and marks the workspace as checked in. Version 3 is the new head version of foo.html
on the main branch.
Multiple Users Modify an Asset
The following diagram shows what happens when two users check out the same asset and the second user’s project completes first:
Step 1: User Angela adds version 2 of foo.html
to project A. The VersionManager
performs these steps:
Checks out version 2 by creating a copy.
Assigns the next available version number: version 3.
Adds version 3 to project A’s workspace.
Angela modifies version 3 within project A.
Step 2: User Bradley adds version 2 of foo.html
to project B. The VersionManager
performs these steps:
Checks copies version 2 by creating a copy.
Assigns the next available version number: version 4.
Adds version 4 to project A’s workspace.
Bradley modifies version 4 within project B.
Step 3: Bradley completes project B. The VersionManager
checks in version 4 of foo.html
. Version 4 is now the head version on the main branch.
Step 4: Angela completes project A. The VersionManager
cannot check in out-of-date version 3, and alerts the user about the conflict. Angela decides to merge her version into head version 4. The VersionManager
assigns version number 5 to the merged version. When Angela completes the project, version 5 becomes the new head version of foo.html
on the main branch.
For more about resolving asset conflicts, see Creating and Managing Assets in the Content Administration Guide for Business Users.