Two states are used only in shared projects: shared and visible. Where these states are used depends on the type of object.
The shared state is used for shared projects. The shared state is between the working and prep states in the lifecycle of a project and allows all users to work in shared projects. By default, working objects are not used in shared projects.
The visible and shared states are used for checked-out objects in shared projects.
The visible state is used for shared development of regular (non-product) objects. Only the owner of the object can change the object. However, all users can use it by adding it to their working projects or to a shared project.
The shared state is used for shared development of product objects. All users can change and use a shared object.
Any user can create shared projects. However, it is better to make the build manager responsible for shared projects because the build manager is familiar with project administration (such as creating, setting update properties, and performing updates). However, in an environment where all users are familiar with projects, team leaders also can be responsible for shared projects. Making individual developers responsible for shared projects might also work well in a small team in which the developers work together closely.
Although the project lifecycle starts at the working state, you can check out a project directly to the shared state by setting the project purpose to Shared Development in the Copy Project dialog box. To check out a shared project from the command line, use the ccm copy_project command with the -purpose shared option. Alternatively, you can check out a project to the working state and then change the project purpose to Shared Development.
In the Rational® Synergy GUI, use the Create Project dialog box and select Shared Development.
In the Synergy CLI, use the ccm create -t project command with the option -purpose "Shared Development".
When you work in shared projects, you must perform check-out and check-in operations differently than in standard projects.
In shared projects, all commands that check out a directory also automatically check in the directory. This feature makes the shared directory available to all users so that they do not need to wait for a change to a directory member to be completed before making their own changes to the directory.
For example, if a user creates a file in the web directory, the directory is automatically checked out as a result of the create command. Because the directory is checked in automatically, other developers can make changes while the user is changing the file. If the directory is not checked in automatically, the directory remains checked out (and unchangeable) until the user completed the changes.
Turn off the automatic directory check-in feature by entering the following line in the ccm.ini file in the CCM_HOME/etc installation path of the server:
shared_project_directory_checkin = FALSE
You cannot check out from a checked-out, visible object. However, in a shared project, you can replace a checked-out object by using a different version of the object (ccm use command or Use dialog box). If you do use a different version of a checked-out object, you are unusing the checked-out object of another user.
Edit only the files checked out to you. Avoid changing permissions of files to make them writable.
When you work in shared projects, you must perform project update operations differently than in standard projects.
If only one version of a shared project exists (no user has a working version of the project), a shared project requires almost no maintenance. The shared project is always up-to-date and updates are not required. Create the shared project and allow users to update the project using basic Rational Synergy commands. For example, set the current task, check out, create, edit, and compete a task.
If working versions of a shared project exist, the build manager must update the shared project to gather the changes made in the working projects. The update properties must contain one folder, set up to query for all tasks for the current release. The folder must be writable and usable by all users.
Updates can cause many objects to change, which affects the developers using the shared project. Therefore, perform updates when few users are using the project. Also, following an update, the build manager must review the update log for unexpected results and for parallel versions that must be merged.
Users can sync a shared project. However, users can discard only object changes that are in a static state or checked out to them. Objects checked out to another user cannot be changed using the sync operation.
Use the ccm reconcile command to sync a single object.