Basic Work Cycle

Lock-Edit-Commit Style

The simplest method of preventing concurrent access problems is to lock files before edit, so only one developer can modify the file at the same time. This method allows to avoid content merging problems, but the work becomes uncomfortable when several developers need to modify the same files frequently. Usually, this method is used by small teams.

This mode can be activated by turning the "Lock all files before edit" option on.
When working in this style, the typical work cycle looks like this:
  1. Developer tries to modify some file; Unified SCC gets latest version of the file and tries to lock it automatically
  2. If lock was obtained successfuly, developer can modify the file
  3. When modification is finished, developer needs to perform "Check in" operation, which will submit modifications to the server and release lock

Edit-Merge-Commit Style

Each file can be modified by any amount of developers simultaneously; developers never have to wait to obtain file lock; however, when file is to be committed to the repository, it may be necessary to merge changes from another developers manually.

This mode is turned on by default.
When working in this style, Unified SCC plugin still performs "Check out" operation before allowing editing a file; however, this operation is rather informal and only needed to indicate what files were edited.
The typical work cycle looks like this:
  1. Modify a file
  2. Perform "Get latest version" command for modified files. This will initiate changes merging, if some other developer made changes to the same files.
  3. Resolve merging conflicts. This can be done in one of two ways:

Unified SCC, Copyright © 2008 Aigenta
Converted from CHM to HTML with chm2web Pro 2.8 (unicode)