GeneXus Server enables collaborative editing and sharing of the GeneXus knowledge base via a central repository. Since more than one user may need to modify the same objects at the same time, GeneXus Server needs to oversee this process so as to make sure users don't accidentally step on each other's feet.
GeneXus Server provides two different versioning modes for team collaboration:
-
Merge Mode (reccommended)
-
Lock Mode
Both strategies have to solve the same fundamental problem: how to allow users to share and edit information, while preventing them from overwritting each other's changes in the central repository.
Merge Mode
In this mode, users are allowed to modify any object in their respective working copies of the knowledge base. However, automatic merging tools are used to ensure that changes from different users to the same objects are merged before being allowed to enter the repository.
When two or more users modify the same object, only the first of them will be allowed to commit. Other users attempting further commits of their work will be instructed to first perform an update of that object. The update will merge the local copy with the changes already on the server's version. Only after this update and merge will the user be allowed to commit the object.
The merge process is automatic in most cases, although the user may (and should) always check the results before committing.
For example, if one user added a rule in a Transaction and another user added an attribute to the structure, the resulting merged Transaction will contain the new rule and the new attribute. After reviewing the results, the user may simply commit the automatically merged changes.
There are are small number of cases in which a merge can't be done automatically, though.
For example, if both users modified the same line in the source code of a procedure, there's no way to know what should be the result: should changes from either user prevail, or should an entirely new line be used?
In these cases, the update operation will default to the server's version as the result of the update (without any merging to the local changes), and will alert the user of the situation. Since the local knowlege base still has the previous revision of the object in its revision history, it's easy for the user to compare both and revert to his own version should he decide to do so, or manually make any needed integration of changes. Again, once the integration is complete, the user is allowed to Commit to GXserver.
When using the merge mode a typical sequence of operations for two users trying to modify the same object is as follows:
|
User A |
User B |
Comments |
|
modify |
modify |
Users may freely modify their respective copies of the object. |
|
|
|
At this point, either user may commit the object. |
|
Commit |
|
Commit from first user is accepted. |
|
|
Commit (failed) |
At this point if User B tries a commit, it will fail because it won't be up-to-date. User B will need to first update the object, so as to receive the changes that were made by User A. |
|
|
Update |
Changes made by User A are merged in B's working knowledge base. B's copy now contains changes made by both A an B. |
|
|
Commit |
The commit is accepted and GXserver now has the integrated changes from both users. |
|
Update |
|
After User A does an update, both KBs are synchronized with respect to each other and to the one in GXserver. |
Lock Mode
The Lock mode is an alternative strategy by which GeneXus Server allows only one user to be changing an object at the same time. When using this mode, GeneXus sets all objects in the working knowledge base as read-only. In order to modify any object, the user must first obtain a lock from the server, which is only granted one user at a time, thus preventing simultaneous modifications.
When using the lock mode the sequence of operations for two users trying to modify the same object is as follows:
|
User A |
User B |
Comments |
|
|
|
At the starting point, the object in each working knowledge base is read-only, so neither user can modify it. |
|
Lock |
|
The lock request from the first user is granted. |
|
Modify |
|
Since a lock was obtained, GeneXus allows the user to modify the object. |
|
|
Lock (failed) |
Any lock attempt is denied until the first one is released. |
|
Commit
(or Release)
|
|
A successfull commit automatically releases the lock. |
|
|
Lock (failed) |
Since the object in B's knowledge base is not up-to-date, the lock is denied and the user is instructed to update the object. |
|
|
Update |
The object is updated in B's knowledge base to the latest version. |
|
|
Lock |
The object is up-to-date and nobody else has a lock, so this request is granted. |
|
|
Modify |
After obtaining a lock, the user is allowed to modify the object. |
|
|
Commit |
The commit succeeds and the lock is released. |
|
Update |
|
After User A does an Update, both KBs are synchronized with respect to each other and to the one in GXserver |
Merge Mode vs Lock Mode
The Lock Mode is usually easier to understand and many people tend to see it as more safe. However, both are equally safe in that they both effectively prevent users from accidentally overriding each other's work. The merge mode makes use of the statistical fact that work from different users has an actually low probability of collision, and of those collisions, most can be resolved with an intelligent merging tool. Thus, the freedom and flexibility of the Merge Mode is usually preferred and recommended over the more bureaucratic and restrictive Lock Mode.
That being said, there may be special situations, projects or organizations, for which the Lock mode may be preferred, so teams are allowed to choose the mode for each knowledge base.
See Also
|