Sharing and Cheap Copies

Over time, you will have a lot of artifacts, especially files, and some files will have a lot of branches. Consider the effect of containers: if you have a lot of teams, software components, and releases, you will need a lot of independent projects, subprojects, or other containers to support parallel development and separate maintenance. Often the same files will be needed in each of these containers. How do you get the files you need to each of these containers? Forcing every file to branch in order to get a unique branch in every possible container could be a lot of branching, which is expensive.

StarTeam systems addresses this problem with a technique known as cheap copies. This involves creating references to files in a new container. Similar to UNIX links, this happens without actually copying the files themselves (that is, their content or their history). Unlike UNIX links, however, the first time a file is modified via a new reference, it is branched. For this reason, cheap copies are also referred to as “copy on write” sharing. Cheap copies support efficient branching with large projects.

In StarTeam, the folder hierarchy and the contents of each folder are specific to each view. Artifacts can belong to (or more properly be exposed through) any number of views and projects. Items are objects that select specific artifacts, connect them to a specific view, and organize them into a hierarchy. The diagram below shows how this works.

Every view has a root item, which always points to a folder artifact. In this example, the root folder name is foo. We can make any artifact in the repository belong to this folder by creating an item that points to the artifact we want and the root item as the parent. In this example, the files a.txt, b.java, and c.jar and the folder bar are all child elements of the root folderfoo. As you can see, the concept of path name is formed by concatenating the names referenced by the item structure. In this view, there is a file whose path name is /foo/bar/d.doc because we can get to this artifact via the item path: folder foo to folder bar to file d.doc. If we want to change the folder in which d.doc appears, we change the parent of its associated item, the artifact itself is not modified. Notice that two items reference the file c.jar. This means that this file is contained in two different folders. We say that the file is shared in two places. This is analogous to UNIX links that reference the same file, causing it to appear in multiple directories. Sharing allows any artifact to be shared in multiple places. Since artifacts are “heavy” (they contain all the properties) and items are “light”, this is how “cheap copies” are made: we just create items pointing to existing artifacts.