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 models for Team Collaboration:
Both strategies attempt to solve the same fundamental problem: how to allow users to share and edit information while preventing them from overwriting each other's changes in the central repository.
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.
If 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 performing a Commit operation.
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 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 GeneXus Server.
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.
Merge Mode vs Lock Mode
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.