Check in
Check-in is a process of writing the changes made to the local working copy of a file back into the repository.Checking in an item releases the lock on it, allowing other authorized users to check it out and modify it as needed.
Before checking in an item, ensure that:
- Your TestArchitect Client is running and connected to the repository to which you want to check in the item;
- You are the user to whom the item is currently checked out.
To check in an item:
In the TestArchitect explorer tree, right-click the item, and then click Check In.
Fastpath: F11.
In the Check In dialog box, make the following selections, and then click OK:
- Keep Checked Out: The checked in item is immediately checked out again to the current user. Useful if you simply want to save the working copy to the repository and continue working with it.
- Recursive: This option is available when you check in a folder node that you had previously checked out recursively. Selecting this option causes all checked out items within the folder and all subfolders to be recursively checked back in.
- Comment: (Optional) It is highly recommended that you add a brief note explaining the changes that you made to the item before checking it in. This comment can be helpful when querying changes made at each check-in, or to view a general history of changes to the item.
Optional: When test modules or actions are checked in, TestArchitect checks for references to ambiguous entities. Ambiguous entities are named references to interface entities that exist in more than one interface. If any such ambiguous entities are found to exist during check-in, the Select Interface dialog box appears, allowing you to specify the correct interface for each ambiguous interface entity reference (see ambiguous entities for more details).
The purpose of this mapping is to ensure that each named interface entity in the action lines of a file references a unique, unambiguous interface. This, in turn, ensures that name change propagation can take place unimpeded, if and when required.
For example, your action line within a test module verifies the existence of an interface entity named welcome. But interface entities by that name exist in both of two interfaces: Car Rental and House Rental. When checking in, TestArchitect prompts you to create a one-to-one reference between welcome and one of the two interfaces.
Locked items (ones not immediately modifiable by you) take two forms:
- an item that has a WRITE-LOCK (black, closed padlock) is read-only, and is available for checking out;
- an item with a CHECKOUT-LOCK (red, closed padlock) is also read-only, but not available for checking out, as it is currently checked out to another user.
Related concepts
Related tasks
Check out
Tel:
Email: