Traditional revision control systems use a centralized model, where all the revision control functions are performed on a shared server. If two developers try to change the same file at the same time, without some method of managing access the developers may end up overwriting each other’s work. Centralized revision control systems solve this problem in one of 2 different “source management models”: file locking and version merging.
File locking
The simplest method of preventing “concurrent access” problems is to lock files so that only one developer at a time has write access to the central “repository” copies of those files. Once one developer “checks out” a file, others can read that file, but no one else is allowed to change that file until that developer “checks in” the updated version (or cancels the checkout).File locking has merits and drawbacks. It can provide some protection against difficult merge conflicts when a user is making radical changes to many sections of a large file (or group of files). But if the files are left exclusively locked for too long, other developers can be tempted to simply bypass the revision control software and change the files locally anyway. That can lead to more serious problems.
Version merging
Most version control systems, such as CVS, allow multiple developers to be editing the same file at the same time. The first developer to “check in” changes to the central repository always succeeds. The system provides facilities to merge changes into the central repository, so the changes from the first developer are preserved when the other developers check in.The concept of a reserved edit can provide an optional means to explicitly lock a file for exclusive write access, even though a merging capability exists.
0 comments:
Post a Comment