Some might consider Source Control to be the backbone of any SDLC solution. Without a robust source control solution the integrity of your source code and the validity of your historical data are both at stake. As we continue our discussion of new features introduced in Rational Team Concert (RTC) 6.0 we should mention some of the changes that have been made to the source control functionality in the product.
Conflict resolution of moved projects
Conflict resolution is one of the most critical aspects of source control management and possibly also one of the most troublesome. It’s a task that can be tediously difficult to get correct while also being mission critical to code function. In RTC you can move a project folder from one component to another by using the Teamà Move In Repository context menu. This can be problematic when another user with the moved component added to their workspace then makes subsequent changes to the contents of the project folder. They will obviously get a conflict, but the conflict shows these changes as being Deleted—which, while conceptually is partially correct, could be misleading. If handled incorrectly this could easily lead to a lost update issue.
In version 6.0, providing users with an “Apply to Component” menu option from the conflict resolution editor mitigates this risk. Under the covers this applies a patch to the project in it’s newly parented component and resolves the issue as a with the gap editor. While this may on the surface seem to be a trivial addition this type of problem can be catastrophic from a functional standpoint and resolving the conflict can be cumbersome. By providing this shortcut the resolution is more direct and understandable.
Configuring default workspace names
One seemingly minor improvement in 6.0 is the ability to configure a pattern for workspace names in your project area. While this may not provide a big functional spark, it certainly has workflow efficiency implications. For avid users of RTC, creating workspaces is a task that happens often. Depending on the particular organizational workflow, users may be working on several workspaces simultaneously or even creating several workspaces each day for their work.
The high volume nature of workspace creation can lead to inconsistency in naming convention and difficulty finding/locating workspaces in the project area. By establishing a workspace name pattern as part of the project area configuration standardization of workspace names can be implemented and workspaces names can be more meaningful.
Expanding custom attribute functionality
Customization is King! It’s nearly impossible to create a one-size fits all product that will give every organization exactly what it needs in every situation. Therefore, the ability to be customized is a more valuable quality in an SCM solution than sheer option volume. RTC has customization built into its core. With version 6.0 the ability to define custom attributes has been expanded to include source control artifacts like baselines, snapshots and streams.
The major advantage of this change lies in the ability to enhance visibility, traceability and communication about version control artifacts. By defining a custom attribute on a snapshot, for instance, that describes the purpose or target of that snapshot (for example, “FVT Deploy Snapshot” to indicate this snapshot was intended as a functional test target) the team can then define queries that use this attribute to communicate across the wider organization. Additionally, since custom attributes in version 6.0 can be queried by the CLI, this function has far reaching impacts and applications beyond the eclipse or web client.
Component Hierarchy Organization
In the upcoming release of RTC, IBM has added support for many-to-many parent-child relationships for components. This means that a component can have subcomponents and a single component may be shared by multiple parent components. This is a relatively fundamental change in how source control behavior manifests itself in RTC and has some compelling use cases:
- Codifying dependencies – In current versions of the product, component dependencies are loosely defined. While there are ways to organize your artifacts that can mitigate this issue, component hierarchies gives users a straight forward way to indicate that one component depends on another and this dependency is broadcast across the project area fostering better cross functional knowledge.
- Traceability – Since changes to this structure would be tracked like any other artifact change in RTC, changing dependencies would be visible in the artifact history. This additional level of traceability has tremendous value for organizations with audit concerns.
- Large-scale reusability – For organizations with many components that follow a nested function approach, the ability to communicate and understand functional pieces at different levels is important. By having the ability to define component hierarchies in a nested fashion, you also gain the ability to understand and add function to workspaces at each of those levels.
One obvious downfall of the many-to-many nature of this change is the capability to introduce a circular dependency. These dependencies are allowed, but marked in the product for potential resolution. One additional note about this function—while it is fully functional and available in version 6.0, because it is not yet supported for Visual Studio Clients it is disabled by default. You must manually enable the function to use it until it is available on all platforms.
Again, by no means is this a comprehensive list of Source Control modifications made in version 6.0. It does represent a list of impactful changes, however, that consumers should plan for and incorporate into their evaluation of this release.