Partial File Versioning: An Incomplete Solution

If your bank credited only a portion of your deposits, you'd quickly find a different bank. Yet what if you found out that your version control tool only versioned part of your file? Suppose you found out it assumed, for example, that the first 10 or 100 lines of every revision would always be the same? What if you couldn't access previous versions of those lines? Sound scary? It ought to, because this type of problem actually exists in the many common version control tools in use! In the following paragraphs, we examine this problem and its origin, we discuss some existing solutions with their strengths and weaknesses, and we then present details on how SnapshotCM solves this problem.

Problem History

The partial file versioning problem became pervasive with the advent of SCCS and RCS, both of which version a file's content, but not its attributes. This shortfall was then further propagated into many tools derived from SCCS and RCS, including CVS. The assumption made in SCCS and RCS, and propagated in the newer tools, was: 1) that the attributes of the version-controlled files would remain constant across all revisions of a file; or, 2) that if the attributes changed, the old values would not be important.

Of course, this is frequently not true. Who doesn't want to delete obsolete files (note the CVS .attic directory), restructure their folder/directory hierarchy, and, less often, change a file's mode without destroying the integrity of older versions of their system? Large teams or teams with large sets of files require the ability to perform these operations. And even for smaller, more agile teams, refactoring requires the flexibility to make these types of changes without corrupting baselines and parallel development efforts.

What file attributes are of concern? The most common attributes of concern are a file's name, its directory, and its existence (i.e., Is it visible in a given product version?). Other relevant attributes often include a file's Unix mode and its text/binary storage mode. Systems that support keyword substitutions in file content during check-in or check-out usually possess an attribute to control how that substitution occurs. Such an attribute is also a candidate for versioning.

Partial Solutions

Several tools provide partial solutions that go a bit beyond storing only one attribute value for all revisions of a file. CVS, for example, uses an attic directory to store deleted files without actually deleting them. When a file can't be found in the normal location, the attic directory is also checked. That way, old configurations are not broken by a deletion.

A similar process is frequently employed during a rename operation. The original file is first copied to the attic directory and then moved to the new name. This action preserves the old name for old configurations. The downside is that the link between the old and new names is lost, making easy comparison of the changes between the old and new revisions difficult. This poses a particular problem if the old revision is eventually patched and the patch changes need to be copied into the current file name. Why? Because the tool has lost that link.

At least one popular tool versions file names in the directory rather than with the file. As a result, you have to look at the directory history to see rename and delete changes to a file. You can't obtain a complete picture of a file's changes from the file history alone. Furthermore, user understanding of the version control model is complicated by the differing approaches taken for names and other file attributes.

SnapshotCM's Solution

SnapshotCM records changes to all relevant attributes in a file's history. What's more, every snapshot (logically anyway) has its own copy of all file attributes. In fact, no change to any versioned attribute in any snapshot will affect the attributes in any other snapshot. The following attributes are versioned for all files and, when appropriate, for all directories:

In addition to the versioned file and directory attributes, SnapshotCM stores the author, the content size, the date of change, a comment describing the change, relationships with other revisions, and the snapshot to which the change was originally applied in each history revision.

Your Solution

How does your solution compare? Do you have problems making patches to old releases because renames or deletions in the current release have corrupted the old release state? Are you prevented from renaming your files or directories because you know that doing so will corrupt other versions of your code? Can you add, rename, or delete files in a branch without affecting your main-line development? How easily can you copy such changes into the main line when ready for release?

SnapshotCM delivers a complete versioning solution by versioning all file and directory attributes. Check us out by taking advantage of our free evaluation. Go to http://www.truebluesoftware.com/ for all the details.