Checkout and check-in operations

Read this topic to learn about the checkout and check-in operations.

To modify an existing object, you must create a modifiable version of that object. You can create a modifiable object using the checkout operation, which creates a version of an object from an existing version. The new version includes copies of all properties from the existing version.

The checkout operation is like the PVCS get -l command (Windows) or RCS co -l and SCCS get -e commands (UNIX). However, in Rational Synergy, you need to check out an object only if you plan to modify it. If you want to view or use it, you do not need to check it out. You can check out any type of object (files, directories, symbolic links, executable files, and so on).

The check-in operation normally preserves the object version by making it non-writable. When the object is checked in, it is available to other users. Checking in an object changes the state (or status) property, which defines who can modify and use it. The check-in operation is like the PVCS put -u command (Windows) or the RCS ci -u and SCCS delget commands (UNIX).

With Rational Synergy, rather than checking in a file once, you can check in the same version multiple times. For example, you can check in a file when you are ready for testing. You can check it in to a different state when you are ready to release it.

Using the example of our developer Jane, we know that Jane is going to modify files to fix the scrolling bug. Jane checks out files, such as gui.c and lines.c, that Jane needs to modify to complete the task assigned to Jane. After modifying the files and fixing the bug, Jane completes the task so that these files can be used in the next product build.

The checkout and check-in processes are an important part of change control during the development cycle. When a developer checks out an object to modify it, the developer becomes the owner of a personal copy of that file for use. By default, Rational Synergy allows another developer to check out an own version of the same file for modification. This process is known as parallel development, and the different versions of the same file are called parallel versions. The work process is not delayed because one version of the file is already in use.

At some point, parallel versions need to be merged. Use the Rational Synergy merge feature to blend information from two parallel versions of a file. When you merge two object versions, a third version is created. Rational Synergy uses the most recent common ancestor to suggest which changes the new version must contain. If there are no conflicts in the files, the new version is ready to use. If conflicts exist, you must choose which lines of the conflicting code to use in the merged version.


Feedback