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 #1
.
When a user adds an existing asset to a project, the VersionManager
checks out the appropriate asset version—typically, 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 context of a project, users can modify this asset’s workspace version, or delete it from the version 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 main.
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 A 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.
User A modifies version 3 within project A.
Step 2: User B 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.
User B modifies version 4 within project B.
Step 3: User B completes project B. The VersionManager
checks in version 4 of foo.html
. Version 4 is now the head version on main.
Step 4: User A completes project A. The VersionManager
cannot check in out-of-date version 3, and alerts the user about the conflict. User A decides to merge his version into head version 4. The VersionManager
assigns version number 5 to the merged version. When user A completes the project, version 5 becomes the new head version of foo.html
on main.