The core mission of a version control system is to enable collaborative editing and sharing of data. Different systems use different strategies to achieve this. There are two main versioning models namely “Lock-Modify-Unlock” and “Copy-Modify-Merge“.

Lock-modify-unlock

In this model, the repository allows only one person to change a file at a time. This exclusively policy is managed using locks. VSS and old style source controls use this approach where only one person at a time can modify a file. Lock the file, edit, then check in and release the lock. This model is only suitable for a small teams. For a bigger team with many developers, it would be inefficient to use this model as locking isolates a file to only one developer which delays the work among other team members who want to work on the file.

The lock-modify-unlock model (Ref #)

The problem with the lock-modify-unlock model is that it’s a bit restrictive, and often becomes a roadblock for users:

• Locking may cause administrative problems.
  if one developer forgot to unlock a file before he take a leave would cause others to delay working on the file unless an administrator to release the lock.
• Locking may cause unnecessary serialization
  if developers are to edit different part of the file, it’s is unnecessary to unlock and edit. It should be edited together then merge the file.
• Locking may create a false sense of security

(Ref: pp. 4)

Copy-modify-merge

In this model, each user’s client contacts the project repository and creates a personal working copy – a local reflection of the repository’s files and directories. Users then work simultaneously and independently, modifying their private copies. Subversion, CVS and a number of other version control systems uses this model as an alternative to locking. Early version of Subversion did not support locking at all, but this is no longer the case. You can now lock files, query files to see who has locked then, and even mark files as requiring locks before edits. This make sense for binary files where merging is impossible. (Ref: pp 5)

Copy-Modify-Merge model (Ref #)

NB: TortoiseSVN provides a good built-in diff tool; you can also install WinMerge (http://winmerge.org), which integrate itself into TortoiseSVN.

When Locking is Necessary

While the lock-modify-unlock model is considered generally harmful to collaboration, there are still times when locking is appropriate.

The copy-modify-merge model is based on assumption that files are contextually mergeable: ie. that the majority of the files in the repository are line-based text files(such as program source code). But for files with bonary formats, such as artwork or sound, it’s ofter impossible to merge conflicting changes. In these situations, it really is necessary to users to take strict turns when changing the file. Without serialized access, somebody ends up wasting time on changes that are ultimately discarded.

While Subversion is still primarily a copy-modify-merge system, it still recognizes the need to lock an occasional file and provide mechanisms for this. (Ref: pp 7)

Ref:
#Don’t Use Microsoft Visual SourceSafe!,
# subversion documentation | Online version

Related Posts:

• SDLC – Software Development Lifecycle