Checking In a Member
|
|
si ci
|
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.
|
Interface
|
Procedure
|
||
|---|---|---|---|
|
GUI
|
From a Sandbox view, select one or more members to check in, and then select > .
|
||
|
Web
|
From a Projector Member History view, select a member to check in by clicking the corresponding check box. From the Projectview, select > . From the Member History view, select > .
|
 |
The maximum size for members is 2 GB for Oracle or SQL Server. To find out the type of repository used on your server, see your administrator.
|
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.
Resynchronizing Before Checking In
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.
Assigning Revision Descriptions
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.
Using Change Packages
If change package reviews are mandatory, a pending revision is created when the change package is submitted.
Updating the Member Revision
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.
Assigning Revision Numbers
By default, when you check in a member, PTC 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 PTC 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:
• is greater than the last revision number (you cannot use previously “skipped” revision numbers)
• has no leading zeros (zeros as complete revision numbers are acceptable)
• starts a new branch based on an existing revision (optional)
If you check in a revision using an already existing revision number,PTC RV&S attempts to add one to the revision number and check it in as that revision. If that revision already exists,PTC 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:
• 1.8 (greater than head revision)—if you check in a revision as 1.7, which already exists,PTC RV&S assigns it 1.8
• 1.10 (greater than head revision)
• 1.72 (none of the numbers between 7 and 72 may be used afterwards)
• 2.0
• 1.7.1.1 (if it starts a new branch)
• 1.7.0.1 (leading zero as the branch number)
The following numbers are invalid:
• 1.3 even if there was no revision 1.3 previously (PTC RV&S branches the archive and assigns 1.3.x.1, where x is the first available branch number)
• 1.08 (leading 0 in last portion)
• 02.1 is considered the same as 2.1 (leading zero in branch number)
Starting a Branch When Checking In a Member
PTC 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.
Deferring a Check In
In some situations, you cannot check in a member. For example, you cannot check in a member if:
• there are revision conflicts on the member that you do not yet want to resynchronize
• there is an exclusive lock held by another user on the member revision and you do not want to force the creation of a new branch
• the member revision is frozen
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.
Maximum Size of Text Working Files in Store-By-Delta Archives
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 PTC RV&S server when PTC 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.
Specifying a Source File in the Web Interface
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:
• PTC RV&S confirms if you want to proceed. Click Yes if you want to check in a source file different from the member.
• PTC RV&S cancels the checkin operation because the file names do not match.
• The member is checked in.
Related Topics