Checking in updated files

Check in updates files with changes, removes the lock on the files, makes changes available to other users, and increments the version number by one.

If multiple users can check out files, you may want to check in and merge files frequently. Checking in regularly reduces the complexity of these merges, making it easier to resolve conflicts. Checking in often also allows other users to access changes.

1. Select the files or repository and choose Activities > Check In.

The Check In Files dialog box opens.

2. Enter any Comments, such as changes made to the files.

3. Select Apply comments to all to use the same comments for all files.

If you clear this option, the Check In Comments dialog box opens after the first file is checked in. You can enter a separate comment for each remaining file to check in or select Apply comments to remaining files to apply a comment to all remaining files.

4. Select Recursive to check in files from the selected repository and all subrepositories.

5. Expand and select any additional check in options.

Select changelist options to check in files as part of a changelist. See Adding file actions to changelists.

  • Check in as part of the following changelist adds the files to a selected changelist. Select a changelist from the list or select <New changelist> to create a new changelist.
  • View pending changelists after check in opens the Changelists dialog box to display pending changelists.

Select Add new version to code review to add the updated file versions to a code review. Select a code review from the list or select <New code review> to create a new code review. See Creating code reviews. Click Select to view code review details and determine which review to add the files to. See Selecting code reviews.

If you are checking in files as part of a changelist, the files are added to the code review after the changelist is committed.

Select local file options to indicate how to handle local files after the check in.

  • Get file after check in retrieves a read-only copy to the working directory. You may want to get files if keyword expansion is turned on, changes are auto-merged, or files are not checked in from a working directory. 
  • Keep checked out checks in changes and keeps the files checked out.
  • Leave local copy as is checks in the file and leaves the working directory copy as is.
  • Remove local copy checks in the file and deletes it from the working directory.
  • Make files writable leaves a read-write copy of the file in the working directory.

Select advanced options to change workflow states, label files, skip the merge process, and update version numbers when files are checked in.

  • Change state when version updated changes the workflow state to the selected state. Select the state to set on the files. You may also want to select the Update version even if no change is made option. If you do not select this option, the check out operation is canceled for files that were not modified. Attach actions are not performed, check in triggers do not run, and the file state does not change. If you are checking in the file as part of a changelist, the state changes after the changelist is committed.
  • Label applies the selected label to the files. Select a label from the list or select <New label> to create a label. See Creating labels. Click Select to view label details or search for a label. See Selecting labels. Optionally select Update label with selected version to remove the label from earlier versions when applying it to the new version. If you are checking in the file as part of a changelist, the file is labeled after the changelist is committed.
  • Skip server auto-merge checks in files without merging changes. The checked in file becomes the new version even if another user changed and checked in the file after you checked it out.
  • Update version even if no change is made increments the version number even if no changes were made. You may want to select this option if you are working with related files and want the version numbers to always match. This can help you and other team members visually confirm that the files are in sync and changes were not missed. For example, you work with two related files: WysiWrite.cpp and WysiWrite.h. Both are currently version 29. You make changes to WysiWrite.cpp. WysiWrite.h does not have changes. If you select this option when you check the files in, both files are updated to version 30. If this option is not selected, WysiWrite.h remains at version 29. If this option is not selected, the file is unchanged, and you are labeling the file, the label is applied to the file version in the working directory.

6. Click Differences to view differences between the file you are checking in and the working directory copy. See Viewing file differences.

7. Click Attach to attach files to an item in Helix ALM or an external issue tracking tool. See Attaching source files to Helix ALM items or Attaching source files to external issues.

8. Click OK to check in the files.

Surround SCM automatically merges changes when files are checked in. If there are conflicts, the merge application opens. See Merging files.

If you changed the workflow state for the files, you may be prompted to enter an electronic signature and reason. See Entering electronic signatures. You cannot set a state that requires an electronic signature on files if a merge is required. If you need to change the state, clear Change state when version updated, check in and merge the files to resolve conflicts, and then manually change the state. See Changing workflow states.