Effective product development requires coordinating the activities of multiple developers who are changing multiple files that are in multiple states of readiness and being changed for multiple purposes, and, in the midst of all these dimensions of change and direction, keeping everything straight. When the multipliers get larger, the complexity is overwhelming.
The solution is two-fold:
Effective toolset support simplifies handling the multiple dimensions of complexity in mid-sized projects, and benefits smaller projects as well. Effective toolsets allow users, managers and administrators to focus on high-level abstractions while the toolset handles the myriad details. Effective toolsets present the "what" of what you want to know or accomplish rather than the "how" of how you go about it. In this article, we present key abstractions we believe are critical to the successful CM that is Complexity Management.
SnapshotCM allows you to graphically and interactively preserve your project release in seconds. All the details of preserving a project state are taken care of for you. Your project state is preserved, every file, every attribute. You see the preserved state visually. And you don't have to craft any commands to get it done.
By contrast, the old and still common file-based approach to preserving a consistent state of a set of files is to set a symbolic name (or tag) on the appropriate revision of each file. This approach is flawed for several reasons, including performance (every control file must be edited to set the tag on that file), frequently only the file content is preserved (not name or other attributes), and most importantly, you, as administrator or user, must perform the operation on each file. You must craft a command to do what you want on just the appropriate files.
Some may object that this really isn't so bad - just tag all files recursively to the latest revision. Yet such an approach assumes that you can correctly identify all the files you care about, that you don't set a tag where it should not be set, that the latest version is really, truly what you want, and that you don't make a mistake. In other words, that there is only one project of interest and that no one will make changes before you've done your magic.
Typically, the old, file-based approach results in files being frozen around the time of a release, and folks not able to check in work until things are loosened up again. Hours or even days of delay are common. Certainly, parallel work is not allowed as it is too costly or complex.
With SnapshotCM, tagging is simple and done in seconds.
SnapshotCM allows you to graphically and interactively branch your project in seconds. All the details are taken care of for you. In fact, branching uses snapshots just like tagging. In fact, branching and preserving state are identical operations in SnapshotCM. Both are presented visually and you don't have to craft any "how-to-do-it" commands, just perform the operation directly.
By contrast, the common file-based approach to branching requires either that every file have a null-delta created to hold the branch point, or complex use of tags be imposed on users who need to select anything other than the default branch. These operations distract from getting the job done, are error prone and complex.
With SnapshotCM, branching is simple and done in seconds.
SnapshotCM visually displays the branches of your project where work can be performed. Project branches are specific objects that can be directly selected and manipulated. With just a few clicks of a mouse, a user can open their workspace attached to the appropriate branch and be all set up to work.
By contrast, the rule-based branching approach requires specifying complex rules for determining which revision of each file to use. The rules often must be interpreted at run-time, a relatively slow process, especially if each file must be consulted to do the evaluation. Because they are run-time interpreted, the results can vary from time to time as the files themselves change. It is not unusual for competent engineers to mess up when specifying a rule-based branch. Simply put, with rule-based branches it is hard to udnerstand what you are selecting.
With SnapshotCM, branches are visible objects, and your focus becomes using your branches rather than how to specify or create the correct branch.
When two users make changes to the same file at the same time, there is potential for one set of changes to be lost. For this reason, many strategies to serialize changes have been devised. Some operating systems provide for exclusive access to a file, which keeps the second user from accessing the file until the first one is finished. This works assuming the same physical file is being used, but doesn't work when separate workspaces are in use.
Another solution is known as the lock-edit-check in model. He who gets the lock is allowed to modify and check in without fear of their changes being overwritten. However, others are prevented from making changes until the first user has finished. Even small, quick changes must wait.
When it is practical to merge changes made by multiple users, as is common in software development, the edit-merge-check in model can be used. In this model, all users can make changes in parallel and the version control system prevents check in without needed merges being performed first. In the simplest case, no one else has done any check in since your last retrieval, so no merge is needed. To warn other users about pending changes so they can knowingly choose whether to begin parallel activity on a file, many systems also provide a means to set an advisory lock on a file.
SnapshotCM supports both serialization models, and with the View Files Needing Action Recursively filter of the Workspace Browser, a user can easily monitor the status of files they are modifying.
A logical change often affects more than one file. When comparing branches or release states, three useful levels of reporting and comparison can be provided.
The most common is file-level compare - what has changed in a particular file. Reporting can include a file content comparison, or a summary of the check in comments between the revisions, who made what changes, when they were more or all of the above.
Another level of comparison and reporting is at the project level - which reports the set of changes applied to one or the other version of a project, but not both.
The third level of reporting is at the task or change set level - which abstracts multiple file changes into a single logical change or task. Task-level reports include understanding specific details of what went into a task. Perhaps more importantly, task-level reporting of differences between project versions provides the higher-level abstraction to directly answer the questions a user or manager will typically ask, such as "Is this change in this release?"
With SnapshotCM, all three levels of reporting are supported. File history and snapshot compare directly provide file and project level change reporting, while the sorted-by-date merged history reporting makes it straightforward to see the task-level changes across a set of files.
SnapshotCM ships wanno, a script to display annotated source files, which helps one quickly determine when a particular change was made, and who made it.
By contrast, without a tool like wanno, one has to examine older revisions, one at a time, until you find the revision where the change was made, then look at the history to figure out who did it and the intent of the change.
One more way SnapshotCM handles the details so you don't have to.
This article discusses how SnapshotCM helps users understand their workspace state, focus on their task, eliminate distractions and get their version control tasks done accurately and efficiently. How does your tool compare? If your solution is coming up short, we invite you to give our free trial a spin. Go to TrueBlueSoftware.com for details on this trial offer.