Advanced Version Control Software with Change Sets
By Ed Taekema in CM, Collaboration on September 3rd, 2008
Following a track back from my post “Is Branching the Answer?“, I found this article on an Accurev blog that largely agreed with my misgivings about using branches in version management software to manage the flow of changes through an organization’s development process. The post mentioned that like Telelogic Synergy, Accurev also follows a change set oriented approach to managing what changes go into a given stream or step in the process. That got me thinking about the different different ways change sets are supported in version controls tools and how they could be categorized. Here is my first shot at it:
- Documentation – In this initial level, the change set really serves a documentation role only. It is basically a glorified comment and doesn’t play significantly in the testing and release of the software. Typically, the change set itself is only used at check in time and any further promotion of the work leads to new change sets obscuring the original change set.
- Process Enabling – In this level, change sets tend to be the primary wrapper around a set of versioned changes to the software artifacts. The change set it what gets promoted, tested, merged, and ultimately (in some form usually) released. In this level, the change set is created once in its original development work area / workspace and then does not change further as it follows through the rest of the development process. The goal for this level is to trace from code in a release to the change set that originated it and is thus very interesting for environments where validation of the code is important (think Military, Aerospace, Medical).
- Dependency Tracking – The next level takes the impact of routing the change sets around the development process and realizes that a great deal of flexibility could be had if it were possible to select the change sets that should go into a build or release of the software. The problem with this is that it is easy to miss dependencies between change sets. This level of change set tool or solution, has developed the capabilities to understand the relationships between change sets, and thus allows for great flexibility when choosing the change sets that should go into a build.
- Distributed Process – This is the farthest that I have seen change set thinking go, namely to allow routing of change sets outside of their home repository. This is similar to distributed version control, only with much greater control of what gets shared. In this level, the software tools are able to export a single change set (and possibly its dependencies) to another repository without sending all of the changes in the first repository. This type of solution fits well with many overseas software development shops that are concerned about intellectual property and security. Only the changes that are necessary are should between sites.
There are many tools that are able to easily handle Level 1 either through native support or through plugins . A concern I have seen though, is that without the deeper integration that further levels offer, level 1 ends up not having much value because it isn’t clear what the extra information offered in the change set is used for. Level 2 makes great practical use of change sets, and level 3 starts to really show the value for careful change set oriented version control. My experience with Telelogic Synergy (a tool that has been in the change set oriented version control for many years) shows that using a level 4 tool is very worth while.
