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.
