Project Orientation

 

The source control system must be project-oriented. File-oriented systems are not able to understand the big picture of all the activity that is happening in the project as a whole. Managing a development project involves understanding all the logical changes that are being made to the entire project. These often involve changes to a variety of components across the enterprise. When you release a new version of your product, you think of the changes contained in that release at a high level, such as the new features and enhancements that went into that release. You aren't particularly concerned with the changes that were made to individual files that implement those features. Of course the source control system has to be able to show you the line-by-line changes that were made to the individual files, but source management activities are concerned with the project as a whole. The files simply comprise the low-level details of the information you are really interested in when managing your project.

 

Branch Support

 

Not every organization has the same workflow. Whether you use traditional waterfall or more short-cycle processes, the source control system has to support the branching strategies that make the most sense to use in your environment. Most organizations use some hybrid of strategies including sub-team, task-oriented, and release branching. Regardless of the purpose assigned to the branches, the system must properly manage the branches themselves and the content contribution between them. Some systems go further and provide formal management of task-oriented branches which ensures best practices are adhered to.

 

Integrated Merging

 

Merging is the process of contributing content from one branch to another. It is important that the source control system have a robust merge facility integrated into the UI. Merging must be atomic so that the entire merge content is contributed as a complete unit, and there should be some mechanism to undo a merge.

There are different levels of merge capability found in source control systems. Some systems do not have a formal merge process and simply perform inbound merging on individual files when they are checked in. This is usually found in file-oriented systems. Not having a formal merge process is very problematic and limited since the merge is not atomic and there is no method of controlling conflict resolution or testing the merged code before it is committed. Other systems have semi-formal merge processes that rely on third party components to perform the merge, which often makes the process tedious, cumbersome and awkward.

The merge process should be a formal client-side process that is tightly integrated into the UI. Only with client-side merging can you introduce other important concepts such as the testing of the merged content prior to committing it, and the resolution of merge conflicts as a whole. Even with atomic merge contribution, if you cannot test the merged content before it is committed to the database you end up with untested changes in your branches and risk breaking the code. That's not just bad form, it violates the basic tenets of software engineering best practices. The merge facility must also provide a way of tracking and managing all the conflicts involved in a merge to ensure all conflicts are resolved prior to testing and committing the merge.

 

Sandbox Development

 

Sandbox development is the idea of isolating developers from team members, and the team from individual developers. This eliminates issues like work stoppages caused when someone checks in code that breaks everyone else, and it creates a stable environment for team members. Also, your work is stored safely in the source control database rather than on your client computer. Sandbox development is usually implemented using workspaces or private branches in source control systems, and is crucial for managing change contribution and increasing developer productivity.

 

Remote Users

 

With the ever-increasing use of telecommuting and contract workers it is very important that the source control system support remote users. Setting up remote users and securing their access to data must be easy to do, and the performance of the system over WAN connections must be good. The network communications between the remote clients and the onsite system must be encrypted for security. Since many remote users are full time employees that telecommute, the features available to remote users must be the same features available to onsite users. If remote users have a diminished feature set, that can create problems when working remotely.

 

Security

 

Security has not always been a priority with source control systems. This was due in large part to development organizations not having formal security policies in place, and because the source control system was usually contained within the secured local network of the company. Now with the increased use of remote users and the increased threat from the internet, security has become essential.

Setting up security for users must be easy and intuitive, and maintaining that security must require the least amount of effort possible. Common mechanisms like security profiles should be available to allow groups of users to utilize a single security definition. The security features must allow you to specify who has access to the system and exactly what data they are allowed to see and what they can do with that data.

 

Analysis and Reporting

 

Analysis and reporting features provide the basis for allowing developers and project managers to understand the state of the development effort. It is critical that everyone on the development team understand the exact state of the project at all times. They must be able to track all changes made to all components enterprise-wide, and be able to quickly answer questions ranging from the enterprise level all the way down to file level. Some source control systems provide a portion of this functionality, but few provide a complete set of analysis tools.

These features include such things as graphically showing the relationships between the branches and the flow of content between them, as well as being able to query what changes have been made to the project for a specified time range. These features are used for everything from determining what changes were made to a particular file, to scoping the complexity of a merge, to merge verification and forensic analysis.

 

Productivity Features

 

Productivity features are often overlooked but in reality they can greatly increase the speed and efficiency of developers. These are simple features that make everyday tasks faster or easier, or provide information that would be difficult or time consuming to retrieve in other systems. When evaluating source control systems you should pay attention to the productivity features they have available.

 

Workflow Integration

 

The source control system is the center of your development universe, but it is not the only thing in the universe. The source control system must be able to integrate with your other workflow applications to enable them to take advantage of the data managed by the source control system. Different source control systems have different features, capabilities and data that they manage and they provide different levels of interface to that data. The most common methods of integration are command line interfaces and environment-specific APIs.

You should keep in mind how your existing source control system integrates with the other systems in your workflow, and how you would like the new source control system to integrate. Stepping up to a better source control system may give you additional integration options.

 

Ease of Deployment and Maintenance

 

It is expensive and time consuming if you have to figure out how to deploy and maintain your system. Any good source control system should install quickly and easily, and all interaction with the system must be done through a UI. With most open source systems you are pretty much on your own. Some have installation programs and some only have documentation. All commercial source control systems have automated installation programs.

With commercial systems usually the most time consuming part of the deployment is determining the topology of the system and creating standards for naming conventions, security profiles, etc. Open source systems usually require the creation of policies and procedures for the team members to follow to ensure best practices are adhered to since the systems don't provide those capabilities themselves.

 

Documentation

 

All aspects of the source control system should be documented. Any dialog or screen that you interact with should have its own in-product documentation. If there is no documentation at all, or there are dialogs or screens that have no documentation then you are left to have to figure it out for yourself and that is time you are wasting doing something you shouldn't have to do.