the element. A new version may be created (implementation dependant).
Source Management Strategies
This is the simplest strategy. When an element is checked-in, it is locked as read-only for all users. When a user checks-out an element, that element is locked in read-only mode for all other users until the original checking-out user performs a check-in or a rollback.
Many modern SCM tools allow multiple users to edit an element concurrently. The first user to "check-in" their changes will always succeed. All subsequent "check-in" actions on the same element will trigger a "merge" - the onus is on the user performing the "check-in" to ensure that their changes are merged with all previous users' changes and any conflicts are resolved.
A Glaring Omission - the database development environment
These Change-Management mechanisms have been around for a long time and the various strategies have proven to be very effective in allowing large teams to concurrently develop large software projects.
One discipline which has not been included in the automated handling of SCM operations is the management of database schema-objects and data. This arena is still a wild and hairy place where each organization must develop a set of manual (or semi-automated) policies and procedures to facilitate Database Change-Management of schema objects and data. Considering the strategic role databases play within organizations, one would assume the database development environment would be a highly focused area for disciplined SCM practices.
In most organizations, this involves exporting the DDL (Data Definition Language) of the schema-object to a text-file and then checking-in that file into the SCM. When a change needs to be made to a database element, the DDL is checked-out, edited in a text editor or database change tool, then the change is applied to the database, and then the new DDL is checked-in to SCM.
The challenge organizations face with the current situation is that there is a two-step process when checking-in and checking-out the database object DDL. This often leads to the wrong DDL being check-in or the wrong DDL being applied to the database. These issues can be worked-around procedurally, but they will always exist to some degree. There is no validation that the right DDL is being checked-in to SCM or applied to the database.
Also, the database object itself is never locked and can be changed at any time without a corresponding change in the DDL of the object that is stored in the repository. This can lead to discrepancies and loss of synchronization between the object in the database and the DDL in the repository. This change is also not logged or audited in any standard fashion, so repeatability, accountability and auditing are also hampered.
The Natural Progression
Database development needs to become an integral part of the disciplined SCM process, same as source code. With the ever increasing demand of doing more with less, tight deadlines, frequent business needs for application updates, code quality and compliance - which are all the reasons source code SCM was adopted at impressively high rates, database development is the next discipline for development VPs and Directors to concentrate on. There is a rewarding outcome for development organizations that treate both Database development and source code development equal from an SCM perspective.
Source-code developers have enjoyed the use of SCM facilities for over 20 years. It's time to bring Database Change Management processes up to modern SCM standards and allow database developers and DBAs to enjoy the same level of simplicity and process-security.
Integration with existing, traditional SCM products would facilitate a homogenous development process across source-code