User Guide - MKS

Chapter 6: Member Operations
Checking In a
Member
172
When you are satisfied with the changes you have 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.
The author name is the name you associate with revisions upon check in. By
default, your author name is your user name.
In the Source Integrity Web interface, because sandboxes do not exist, a
source file (working file) for the member is specified and checked in as the
new revision.
Starting a Branch When Checking In a Member
Source Integrity usually places a new revision at the top of the trunk,
assigning it a two-part revision number, such as 1.15. 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. For information
on branching, see “Branching and Merging Revisions” on page 305.
Divergent lines of development in the same archive are managed through
the use of branches. A branch is an independent revision line that uses an
existing revision as its starting point. Members of a branch revision are
identified by their revision numbers. Whereas revisions on the trunk are
characterized by two-part revision numbers (for example, 1.2 or 3.5),
u s e r g u i d e