The Source Integrity Professional Edition User Guide - MKS

Understanding Source Integrity
Changing
States
Often, the same files are shared by more than one component, and
entire components may be part of several larger modules. Source
Integrity’s projects let you define development objects and the
relationships among them. Source Integrity handles both simple and
complex objects—files, components, modules, or complete
applications—and automates the intricate weave of their
relationships.
What Are Development Objects?
Source Integrity lets you define objects and establish their place in the
development hierarchy at every stage of the development process.
Source Integrity can help you organize your resources into
meaningful, easy-to-manage units, so you can work with confidence
in a stable environment. This ability to group objects into logically
and functionally related projects, and to define relationships between
objects, provides a foundation for good development practices.
If building a software application were like building a house, Source
Integrity’s archives and projects—the building blocks—would be all
you would need. But software development is not a static process.
Imagine trying to build a house when the bricks and timbers keep
changing shape.
Unlike bricks and timbers, the objects used in software applications
change over time: files are updated and code modules are expanded
or broken down into smaller components. Software building blocks
change even after they are put into place.
Dealing With Constant Change
Source Integrity handles this problem by letting you take “snapshots”
of any object at every stage of its development. This snapshot—or
revision—then becomes a static building block that you use to build
your application while the object continues to evolve.
When a file or code module reaches a milestone, you can check in the
object to preserve its current state as a revision. When you need that
object to build your application or compile another module, it can be
recreated automatically, in precisely the same state as it was saved.
Using this technique, different revisions of the same object (that is,
the same object in different states) can be used to build various
components of an application. You can recreate components—or an
entire product release—if post-release fixes become necessary.
12 Source Integrity Professional Edition