When you are satisfied with the changes you made to a member, you should check in the member to preserve those changes as a new revision in the member’s history. Members should be checked in on a regular basis.

Checking in a member creates a new revision of a member and adds it to the member history. When a member is checked in to a revision other than the head revision or a branch tip revision, a new branch is created.

In the GUI, you can click the Differences button on the Check In dialog box to view the differences between your working file and the revision you checked out.

If you use a non-exclusive locking policy, other users besides yourself may have the same revision checked out. If another user checks in their changes first, they get the next sequential revision on the current branch (if the revision is the tip of the current branch). When you try to check in your changes, you are prompted to resync and merge the previously committed changes into your working file before you can complete the check in. For more information on your locks policy, contact your administrator.

A revision description is text that becomes a permanent part of the archive’s metadata. It allows you to provide a record of the changes you made and why you made them. This can be of great value to you or other team members if it ever becomes necessary to revise or update the member.

Once a new revision is checked in, its revision description cannot be changed. You can, however, append new information to a revision description.

If your administrator has set the feature for enforced revision descriptions, you must enter a revision description.

If change package reviews are mandatory, a pending revision is created when the change package is submitted.

You can use the Update Member Revision option when you are checking in a member to ensure the most recent revision of each member is added to the list of members in the project. If the option is not enabled, the project list might not reflect the most current revision of each member’s history. For example, if the current project member is revision 2.7 of an archived file, but a newer revision 2.8 has been added to the member’s history, you can update the member to the new revision.

By default, when you check in a member, Windchill RV&S automatically assigns a unique revision number to the new revision. It does this by incrementing the current revision number by one. For example, if the previous revision is 1.3, the new revision is assigned number 1.4. For best practices, PTC recommends letting Windchill RV&S generate revision numbers for you—do not use revision numbers to record milestones (use labels or checkpoints). The ability to specify a specific revision number is supported for legacy purposes, but is not recommended.

You can choose the revision number of the changes you are checking in, so long as your revision number:

If you check in a revision using an already existing revision number,Windchill RV&S attempts to add one to the revision number and check it in as that revision. If that revision already exists,Windchill RV&S then chooses the next available branch number and creates a new branch.

For example, if you are checking in a new revision to an archive where the head revision is 1.7, the following numbers are valid:

The following numbers are invalid:

Windchill RV&S usually places a new revision at the top of the main trunk. There are times, however, when you do not want your work to be checked into the trunk. You may be pursuing a line of development that will not be included in the finished product, or you may be doing post-release maintenance while development for the next release continues on the trunk. Divergent lines of development in the same archive are managed through the use of branches.

In some situations, you cannot check in a member. For example, you cannot check in a member if:

When you cannot check in a member, but still want to record information about the check in (for example, the revision description), you can defer the check in.

When a revision conflict occurs on a check in, a deferred check in is created automatically. In other situations, you can select the Defer Check In option.

Your administrator may set the policy that determines the maximum size of text working files that can be stored in a store-by-delta archive. The policy is useful in preventing out of memory issues on the Windchill RV&S server when Windchill RV&S attempts to difference large text files. If the file exceeds the maximum size during a check in, you are prompted to cancel the operation or convert the store-by-delta archive to store-by-reference.

In the configuration management Web interface, because Sandboxes do not exist, you specify a source file (working file) for the member, which is checked in as the new revision.

If the name of the source file you specify is different than the member name, depending on how you have the Different Member/Source File Name option set, one of the following occurs: