Introduction

SnapshotCM is a configuration management solution designed to simplify the task of managing change. SnapshotCM offers the standard features you have come to expect from CM products: version control of files, change locking, branching and merging. In addition, SnapshotCM provides fast, simple and error-free project release management as well as sophisticated team coordination.

Most CM tools focus on versioning files and perhaps directories. SnapshotCM goes beyond this by providing project level versioning. In project versioning, a complete hierarchy of files and folders is versioned together--simply and efficiently. SnapshotCM provides the means to instantly branch a project, quickly compare versions of a project, and easily copy changes from one version to another. In SnapshotCM, a version of a project is called a snapshot. Understanding snapshots is key to understanding SnapshotCM. Understanding how snapshots and the other SnapshotCM objects solve common CM problems will enable you to make effective use of SnapshotCM. And that is the purpose of this document. Read on!

This document covers the following materials:

• Understanding Key Objects
  • Projects
  • Snapshots
  • Project Snapshots
  • Development Snapshots
  • Snapshot Relationships
  • Workspaces
  • Working Sets
• Understanding Key Operations
  • Workspace Operations
  • Snapshot Operations
• Understanding Development Models
  • Sequential Development
  • Patch Development
  • Parallel Development
  • Modified Sequential Development

Key Objects

Projects

Projects are the overriding organizational tool for SnapshotCM. Projects contain a collection of snapshots, each representing a unique version of the project. A project organizes and graphically depicts the relationships between the snapshots. Some snapshots reflect past project releases while others reflect current or future releases. Some hold intermediate states, some serve as containers for integration of changes, and others isolate individuals or groups from changes being made by others.

SnapshotCM stores a project in a SnapshotCM database managed by a centrally located SnapshotCM server. A SnapshotCM server can manage multiple projects, but a project cannot be split across multiple servers. SnapshotCM clients access the server remotely using the TCP and IP protocols.

When defining projects, consider that they are independent and complete elements. Each project is separate from other projects and data cannot be passed from one to another. Release management is much easier when a project manages all elements that will be released together. Depending on what type of environment you work in, a project can manage anything from a released product to a set of internal documentation.

SnapshotCM allows flexibility in the way you structure the snapshots in your project depending on the complexity of your project and the size of your team. Figure 1 shows four snapshots, plus two workspaces.

Figure 1. To organize your work, a project contains a project release road map (above the dotted line) so you can graphically see your releases and their relationships. It also contains a development hierarchy to help coordinate team changes.

Examples

1. If you are working on a team that releases an external product, you use a project to organize product releases and product development. The project release road map organizes your releases and any patches you may create, and the development hierarchy organizes your teams and development structure. Also, you can name the project after the product you are working on for easy recognition. For example, if your product’s name is HiTech Editor, then you can name the project HiTech Editor.

2. You might be working on a team that releases only internal products. For example, you maintain a web site for your division or company. You then use a project to maintain phases of enhancements and fixes (your project road map). The organization of your development work (development hierarchy) is also organized under the project and is flexible enough that it can grow with your team. You can name the project Cool Web Site for easy recognition.

3. Maybe you are working on a team that never releases an external or internal product but has many projects to organize. For example, you are developing prototypes for customers. You can use projects to organize your development and manage different phases of your projects. Give each project an appropriate name, such as Government Prototype or Customer X Prototype.

Snapshots

A snapshot stores a malleable parts-list or state of the files, folders and attributes that represent a particular instance of your project. As changes are applied (through check in or other attribute changing operations), the snapshot also changes. Whenever a snapshot state becomes something with meaning that you want to preserve, you simply create a copy of the snapshot (an instantaneous operation). You can then freeze that copy by setting the freeze flag on the snapshot and/or use the access control mechanisms of SnapshotCM to prevent further changes to the snapshot.

In order to adequately support versioning complete project states, SnapshotCM stores the following types of attributes for each file or folder in a snapshot:

• Contents of the file, whether large or small, text or binary.
• Name of the file or folder.
• Directory in which the file or folder resides.
• Existence or deletion of the file or folder.
• Mode (rwxrwxrwx on Unix) of the file or folder.
• I/O mode (text or binary on Windows) of the file.
• Keyword expansion setting for the file.

Since any of these attributes may change between snapshots, SnapshotCM supports comparing and copying changes to any of these attributes between snapshots. That is, you can safely delete obsolete files and directories, and rename or change whatever attributes are necessary for on-going work without losing either the old names or the association between the old and new names. This means that if a defect is fixed in a patch to the old named file, that change can be propagated to the current work easily.

Snapshot Types

Just as projects provide an overriding organizational tool, snapshots provide a way to organize your development hierarchy. You can structure your snapshots in a variety of ways to support the size of your team, whether one person or many. Also, snapshots allow you to set up how your team coordinates changes and how files will be managed during development.

SnapshotCM offers two types of snapshots for your project structure:

• project snapshots – graphically arranged to show relationships
• development snapshots – hierarchically arranged to show change propagation relationships

Project snapshots are the top level of the development hierarchy and allow teams to maintain a stable code base. Project snapshots allow you to organize past product releases and plan for future releases.

Development snapshots are the basis of your development hierarchy and allow development teams to isolate and coordinate changes until the code is stable enough to move up into the project snapshot that anchors a hierarchy of development snapshots.

Both types of snapshots contain virtual copies of all project files. You can think of a snapshot as a particular view into the archive. The archive is located on the SnapshotCM server and is where the archive files (along with all revisions for each file) are permanently stored. Both project snapshots and development snapshots keep track of the specific revisions that are used to make up the unique view of the archive that a snapshot maintains.

Figure 2 shows a sample development hierarchy with three project snapshots and three development snapshots. While workspaces can be attached to, and modifications made to any snapshot, even project snapshots, there are situations where a development hierarchy can be advantageous.

Figure 2. SnapshotCM uses two types of snapshots: project snapshots and development snapshots. Project snapshots are the top, stable areas where changes are moved after being tested in the development snapshots. You can use development snapshots to isolate and coordinate team changes. Notice that each snapshot contains its own virtual copy of all files for that release.

Project Snapshots

Project snapshots form the top level of your project structure, providing an organizational tool for project releases (see figure 3). You use project snapshots to manage:

• stable instances of your project that are no longer changing (such as completed product releases, completed patches and other completed milestones you want to save)
• current instances of your project that are somewhat stable but may continue to change (such as patch or beta snapshots of the project that you plan to continue working on)
• new or future releases for your project
• patches and other branch development
• investigations

Project snapshots contain a virtual copy of all files for a particular version of your project, and maintain a view of which archive files and revisions are contained in each project snapshot. They also organize your project structure by providing a top-level structure from which to coordinate development snapshots and personal workspaces.

Figure 3. The project browser graphically depicts the project snapshots and relationships. The four project snapshots represent two project releases, one patch release, plus current development.

Using Project Snapshots Instead of Tags

If you are an experienced user of CM tools, you are probably familiar with using tags (or symbolic names) to keep track of branches in your development. With SnapshotCM, tagging is not necessary since all files for a version of your project are contained in a snapshot. That snapshot acts as the tag. For example, all appropriate files and folders, together with associated attributes to be used for Release 2.0 of your project, are contained in the project snapshot named Release 2.0.

By using SnapshotCM project snapshots, you eliminate the risk of losing or incorrectly tagging files. You can create as many project snapshots as you need to maintain your project and the correct file revisions and attributes will always be in the snapshots you have defined. Because creating new project snapshot is equivalent to tagging all files in the source snapshot, you will never need to tag and re-tag individual files again.

Examples

1. You may be on a team that wants to save many instances of your project. With SnapshotCM, you can create as many project snapshots as you want, naming them appropriately. For example, you may have project snapshots called Beta (02-12-00), Checkpoint (05-13-00) and Patch 1.7 (12-13-01).

2. If you are on a team that releases once a year or once every six months, project snapshots can organize your releases also. For example, you may have project snapshots called Release 1.0 Beta, Release 1.0, and Release 2.0.

3. Project snapshots can be used for bug fixes or enhancements to code. With project snapshots, you do not have to search for all the files you need because they are already located in the proper project snapshot. You simply make a copy of that project snapshot, thereby creating another project snapshot for your fix or enhancement work. You can name the project snapshot Patch 1.6 or Enhancement 2.0. Be sure to make changes in the copy rather than directly in the base line snapshot in order to preserve the baseline snapshot.

Development Snapshots

Development snapshots represent the team change coordination model of your team. It is an organizational tool that allows you to:

• isolate development of specific project components, such as GUI or database development
• isolate changes until they are tested and ready for wider distribution
• maintain project versions with varying states of stability and functionality
• coordinate changes between multiple teams
• test and approve changes before moving them into more stable snapshots

You create development snapshots by copying a project snapshot so that all files in the project snapshot are also contained in the new development snapshot. This way, work can be tested and approved in the development snapshot with full access to all files. The project snapshot remains stable because the development snapshot is used for changes and testing.

Development snapshots let you make changes to your project and test how these changes perform without affecting other teams working on the same project (see figure 4). Depending on how you plan to use the development snapshot and how your project structure is organized, a development snapshot is either linked to a project snapshot or to another development snapshot. Every development snapshot is part of a development snapshot hierarchy rooted with a project snapshot. Every project snapshot can have its own development snapshot.

Figure 4. Use development snapshots to isolate team changes and to coordinate changes within teams. Development is completed and tested in the development snapshots before affecting the more stable project snapshots.

Using Development Snapshots for Integration

Using development snapshots to organize your project structure can provide flexibility and protection for your development teams. You can use a development snapshot as a place to integrate and test the changes from all teams before affecting release files. As figure 4 shows, this integration development snapshot can be placed below a project snapshot so that no changes can be moved into a stable snapshot of your project without passing through the integration snapshot for testing.

Examples

1. If you are working on a project that has many teams (for example, GUI team, DBA team, Editor team), you can set up your development hierarchy to isolate each of these teams. Each team can have its own development snapshot so that they can coordinate changes before the other project teams see them. In this case, you will probably want one or more integration snapshots to coordinate all team changes.

2. A small team may have only four people on it. In this case, you may want only one development snapshot to coordinate and test changes between the four team members.

Snapshot Relationships

Relationships between snapshots allow you to perform operations between them, such as moving changes from one snapshot to another. Relationships also give you a view of your project structure, graphically representing the relationship between one snapshot and another. You create a relationship by copying one snapshot to create another snapshot. In the figures in this document, the arrows represent the relationships between snapshots.

SnapshotCM uses two types of relationships:

• Sequential relationships are between project snapshots and connect the project releases in the road map.
• Hierarchical relationships are between snapshots in a development hierarchy.

Sequential Relationships

Sequential relationships refer to connections between project snapshots and are automatically established when one project snapshot is copied to create another project. Relationships can also be manipulated manually to reflect new or modified relationships. Sequential relationships are part of the road map of your project releases and they allow you to move changes between one project snapshot and another.

Example

After your team has completed Release 1.0, a customer calls to report a defect in your product. From your project snapshot Release 1.0, you can create a new project snapshot called Patch. The arrow between Release 1.0 and Patch shows the relationship. By adding an additional relationship from Patch to Current Development, fixes applied to the patch can easily be propagated into the current work. See figure 5.

Figure 5. Three sequential relationships between project snapshots and three hierarchical relationships are shown. Changes made in one snapshot can be copied to other snapshots connected by a relationship. Copies occur in both directions of a hierarchical relationship. Copies occur unidirectionally in sequential relationships.

Hierarchical Relationships

A hierarchical relationship is a parent-child relationship between two snapshots. A parent snapshot is above a child snapshot (closer to the root) in the development hierarchy (see figure 5). Hierarchical relationships allow operations to be performed between the two snapshots in either direction.

Example

Once the GUI and Database teams have reached some stability, they get the latest changes from Integration, resolve any problems and then promote their changes into the Integration snapshot. Once all teams have promoted and testing is completed, the stabilized set of changes in Integration is promoted into Current Development, making Integration available for the next round of changes.

Workspaces

A workspace is an area on your local machine where you do project development without affecting the rest of the project. While project and development snapshots give you views into the archive, your workspace contains local copies of some or all of the archive files from a snapshot.

Every workspace must be associated with (or mapped to) a snapshot (project or development). The snapshot that a workspace attaches to is its mapped snapshot and the mapped snapshot contains the archive files that you will use (see figure 6). Files in workspaces can be modified and new files created, but the snapshot is not affected until check in. Other attribute modifying operations, such as rename and delete, are performed on the snapshot and the workspace together. In figure 6, Amy's and Joe's workspaces are mapped to the GUI snapshot, while Tim's and Meg's workspaces are mapped to the Database snapshot.

SnapshotCM associates a file structure in the workspace that corresponds to and mirrors the complete file structure in the mapped snapshot. The folders and files in your workspace will have the same hierarchical organization as in the mapped snapshot. In other words, there always will be a place in a workspace for every file in a snapshot.

As with snapshots, workspaces are important organizational tools that help you control and maintain your project. But more importantly, workspaces are where you perform the actual work of project development.

Figure 6. Each person working on a project has one or more workspaces. All the snapshots above the dotted line are views into the archive. The workspaces below the dotted line contain copies of the archive files, but are not part of the archive.

Examples

1. Let’s say that you have just been assigned to work on the GUI. You would then attach your workspace to the project snapshot labeled GUI.

2. You may be working on a project where several people will be working closely together. Attaching multiple workspaces to a snapshot allows all team members to see changes immediately after check in (through a workspace update) and facilitates close coordination of changes. Once the team changes are ready, they can be copied to the parent snapshot. In figure 6, Amy and Joe share the GUI snapshot in this fashion, as do Tim and Meg share the Database snapshot.

Working Set

Most SnapshotCM operations act upon a subset of files and folders selected by the user for that particular operation. SnapshotCM also supports operations that operate on a working set. A working set is a pre-defined subset of the files and folders in a snapshot. Workspace-wide operations use the working set to restrict action to just the files and folders you need for your particular tasks. And since only changes within your working set will be updated during workspace update, your workspace will not be cluttered (and disk space used) by files you don't need, and the operation will be much faster.

Each entry in a working set specifies a file or folder to add to the working set. Folders also have a flag indicating whether the folder should be operated on recursively, or if only the items directly within the folder should be operated on.

Key Operations

If you work on a small project, you can operate effectively with a single project snapshot per release. Larger teams have complex environments that need more powerful operations supported by multiple snapshots. Whether you work on a small or large project, SnapshotCM allows you to work effectively by providing operations to fit your needs.

The operations that SnapshotCM offers can be divided into two categories:

• workspace operations
• snapshot operations

Workspace operations are performed between a project or development snapshot and a workspace. These operations include checking in a file, checking out a file and updating your workspace (Figure 7).

Figure 7. Workspace operations allow you to perform operations on files and folders that affect the workspace and the snapshot.

Snapshot operations are performed between two snapshots. These operations include comparing snapshots, promoting or copying changes between snapshots, creating new snapshots, manipulating snapshot relationships and changing snapshot properties (see figure 8).

Figure 8. Snapshot operations allow you to copy changes between snapshots in a team environment.

Workspace Operations

Checking Out Files
Checking out a file from a parent snapshot into your local workspace gives you a copy of that file on your local machine so that you can work with it. Any changes you make to the workspace copy will not affect the file in the snapshot until you check the workspace file back in.

You can check out a file with read-write (locked) or read-only (unlocked) permissions. Use the locked option when you want to make changes to the file, and use the unlocked option when you simply want to read the file from your local system. SnapshotCM allows you to check out multiple files in one operation.

Checking In Files
Checking in files incorporates the changes that you have made in your workspace into the mapped snapshot. By checking in your modified files, you apply your changes to the mapped snapshot. Your changes then are available to any co-workers who have workspaces mapped to the snapshot, and also become available for copying to other snapshots.

Updating Workspaces
Updating your workspace incorporates any file or folder changes in the mapped snapshot into the same files and folders in your local workspace. By updating your workspace, you ensure that you have the most current file revisions. After you have checked in your modified files, your co-workers can update their workspaces to reflect the changes you have made. Your co-workers can then continue their development using the latest file revisions.

Importing Files and Folders
Files and folders which only exist in the workspace can be added to the mapped snapshot by doing an import. Individual items or a whole hierarchy can be imported easily.

Changing Mode, Renaming and Deleting Files and Folders
Mode change, rename and delete operations are applied to the snapshot and workspace together. Any unlocked file or empty folder can be deleted, and any file or folder, even if locked, can be renamed, moved to a different folder or have its mode changed.

Changing Check In and Check Out Attributes
The keyword expansion and I/O mode attributes can be modified on any file. These operations have no effect on folders. If either of these attributes cause the desired local file contents to be different, the next check out or workspace update operation will update the file (unless locked locally).

Snapshot Operations

Updating Snapshots
You can copy changes from a parent snapshot into a child snapshot by selecting the child snapshot and choosing Snapshot -> Copy Changes From Parent. The copy incorporates any file or folder changes in the parent snapshot into the same files and folders in the child snapshot. If a workspace is selected and associated with the child snapshot, SnapshotCM will also update it automatically.

Promoting Snapshots
You can promote changes from a child snapshot into a parent snapshot by selecting the child snapshot and choosing Snapshot -> Promote Changes To Parent. You promote changes up the development hierarchy when changes in the child snapshot have been approved or have been tested enough to move into the parent snapshot. You cannot promote if conflicting changes exist between a child snapshot and its parent snapshot. You must first resolve the conflict during a Copy Changes From Parent operation, and then you can promote your changes.

Merging Snapshots
The merge operation involves resolving conflicts between snapshots so that a promotion or copy can be performed. Since a merge involves conflicting changes, you may need to attach a workspace to the child snapshot to resolve the conflicts. Once the conflicts are resolved, SnapshotCM can automatically complete a copy or promote for you.

If you promote or copy changes from one snapshot into another, your changes affect the rest of your team. Therefore, you perform a merge to resolve any conflicting information within the files before promoting or copying those changes.

For example, if two team members made conflicting changes to the same file, a merge between the two files will need to be completed before any copy or promote involving that file can be performed. To resolve conflicts, you need to attach a workspace to the target (child) snapshot and manually resolve the conflicts.

Comparing Differences
SnapshotCM provides an automatic and quick way to view differences between individual files or entire snapshots. The differences displayed include anything from file or folder property differences to content differences. If you want to see the differences between two or more files or file revisions, you use the compare operation, and the differences are quickly displayed to you. Viewing the differences between two entire snapshots with SnapshotCM is simple and fast because SnapshotCM directly accesses the differences between the two snapshots.

Creating A Snapshot
A new snapshot is created by copying an existing snapshot. The new snapshot is a virtual copy of the original, taking up no space until one or the other of the snapshots is modified. Therefore the operation is quick and efficient.

A new snapshot can be created as a New Development Snapshot, or, if the source is a project snapshot, as a New Project Snapshot. New project snapshots can be inserted before the existing snapshot, taking over any predecessor relationships, or it can be added as a successor of the existing snapshot.

Freezing a Project Snapshot
Freezing a snapshot prevents any modification to the contents and allows you to recreate the frozen snapshot at any time. While access control also can prevent changes, freezing a snapshot preserves the access control list for the snapshot should it need to be unfrozen again later.

To freeze a project snapshot, you first create a new copy of the snapshot, choosing the insert as predecessor option. Then you select Snapshot -> Properties and select freeze on the copy. It is important to make and freeze the copy so that your development hierarchy can continue to be used on the existing snapshots.

Development Models

Organizations often use several software development models during the life-cycle of their products. SnapshotCM supports any model you choose because it offers flexible project structures and powerful organizational tools. The following section gives you examples of how you can use SnapshotCM for different types of development.

Sequential Development

During the life-cycle of your project, you may want to save certain stable instances of your project for future reference or use, such as beta releases or completed releases. By copying a project snapshot that you will freeze for future reference, you are creating a checkpoint snapshot. These checkpoint snapshots not only give you an archive of important releases, but they also provide you with a road map of the life of your project (see figure 9). SnapshotCM automatically creates these virtual copies for you when you create a new project snapshot and choose to insert it before the selected snapshot.

Figure 9. Checkpoint snapshots form a sequential set of important instances of your project. You can create as many checkpoint snapshots as you find useful.

Patch Development

SnapshotCM lets you easily create a patch snapshot from any project snapshot. The patch snapshot is an exact copy of the selected project snapshot, but is ready for modification. Patch snapshots are usually created as successors of existing snapshots (see figure 10).

Figure 10. A patch snapshot is created by copying a selected project snapshot (Release 1.0). You can use a patch snapshot to do bug fixes or add enhancements to your project.

You can use a patch snapshot when you want to make a change in your project that needs to be completed before the next major project snapshot is finished. After you create a patch snapshot and make the desired changes, you can, by creating a relationship from the patch snapshot to the current snapshot, merge the patch changes into the current work. Patch snapshots are useful for:

• bug fixes
• project enhancements
• customizations for particular customers

Parallel Development

You may want to create parallel project snapshots to work on multiple releases of your project simultaneously. By combining checkpoint and patch snapshots, parallel development is established, as well as a common baseline (see figure 11). As always, each new snapshot is an exact copy of the original snapshot when first created.

The checkpoint snapshot provides a snapshot of the state of the project snapshot at the time the parallel development begins. The patch snapshot provides an additional project snapshot where parallel product development can commence.

Figure 11. Parallel snapshots involve both a checkpoint snapshot and a patch snapshot. The Current and Parallel snapshots allow divergent development without affecting other snapshots, while Checkpoint preserves the common baseline (or branch point).

Modified Sequential

Frequently a team will want to start on the next project release before the current effort is completed. Figure 12 illustrates how snapshots can be used in this situation. Here, Release 2.0 represents the unfinished current work and Next Releasethe next release work. The relationship from Release 2.0 into Next Release allows changes made after the split to be propagated forward into Next Release. SnapshotCM automatically identifies all changes to Release 2.0, making the forward copy generally straightforward.

Figure 12. Modified sequential development allows starting the next release before the current (Release 2.0) is completed.

This model differs from the parallel and patch models in development intent. If you intend to perform divergent development, the parallel model is more appropriate. And the patch model is more clear if one is creating a patch to something that is frozen.

The presented models focus on use of project snapshots. Development snapshots can also be used for most of these purposes. However, since the relationships are much less natural and not graphically depicted, this use is not recommended. Development snapshots are best used for team isolation and coordination.

Summary

SnapshotCM represents a shift away from file revision focused CM tools. SnapshotCM takes care of the details of which revision of which files (and indeed which files) belong to a release and allows you to focus on releases rather than files. SnapshotCM automates the identification of changes between releases, and makes easy the propagation of changes from patches into on-going development. SnapshotCM provides a development model that fits well into the way development projects typically operate.

In summary, SnapshotCM provides advantages for all types of users:

• For the developer, SnapshotCM's powerful and advanced workspace operations simplify workspace management and the isolation inherent in snapshots allows a developer to both check in and remain isolated from other work until a task is completed. And the attribute versioning means one can rename or delete old files as appropriate for the current work.
• For the development team, the snapshot relationships support flexible coordination of changes.
• For the administrator, the graphical project snapshot view makes release preserving and comparing trivial.
• For the code builder, snapshot and workspace operations make getting the right code easier than ever.
• For the code maintainer, the easy and reliable access to old project snapshots allows a focus on the maintenance problem rather than the CM system.
• And for management, the improved productivity, reduced risk and complete solution provided by all of these features means that the team can focus more on their product and less on CM.

SnapshotCM, in all of these areas, strives to make software development just a bit less complex. And in the middle of a long day, wouldn't it be nice to know that

SnapshotCM handles the details so you don't have to.

For more information on SnapshotCM, please see http://www.truebluesoftware.com.