The ABCs of Software Version Control

Software version control (SVC), also called revision control, source control management, and versioning control, is a management strategy to track and store changes to a software development document or set of files that follow the development project from beginning to end-of-life. Following the logical and recorded development trail can aid in finding problem origins, bugs, or even better versions of the build. In software development, many of the systems allow different levels of collaboration and communication for a team of developers while writing the code. At its core, SVC is a data repository (or repositories) that tracks changes made to a file, who made the change, and when the change occurred. This information tracks all input to create a reliable historical record of the entire project. The SVC system is a complete view of changes and revisions, and can move the project forward in a collaborative manner while also preserving valuable work to revert to an older version if necessary.

According to Ryan Ostrom, Software Architect of Praxent, “Version control is the DevOps practice of ensuring each technology across a given product is using a chosen and reliable version of the technology that’s compatible with each component within the product ecosystem.”

He continues, “We recommend a holistic approach that leverages best practices across the following domains within a given product:

• Product: Define and implement a policy for ensuring version compatibility among all applications within a given product.
• Application: Determine a strategy for batching, branching, and deploying versions within a given application: (a) prior to the first upstream merge and (b) for all workflows throughout the development stream.
• Package: Specify a practice for reviewing and updating all packages within a given application.”

Today, a team of developers is responsible for most software builds. The importance of code version control is that it provides a constant communication vehicle for the team, whether they are in the same room, or around the globe. The system provides a logical method that preserves the individual contributions of team members without overwriting another developer's work, and then merges and reconciles changes and updates. The system is also a failsafe for finding and supporting issues that are in conflict. The historical record produced can be used to track down problem origins or archive versions for later use. Even if a developer is working alone, the system provides the defensive record keeping of progress and process. The preservation of valuable information and past work is possible with a sound VCS.

Rachel Jia is the Marketing Manager at Dynamsoft. “Version control is the most important method to ensure your software development projects are progressing in a timely fashion,” she says. “It’s essential to commit changes and also have the ability to revert to a previous milestone, review comments from other developers, and of course, access the latest version and avoid conflicts.

Software version control systems support an overall Agile development plan by providing a “proof” mechanism for how the code was constructed, when it was changed, and by whom. A well-managed system has version numbering conventions that are easily identifiable by the entire team. The system manages the directories, files, and individual changes made over time, which allows users to find root causes for mistakes or bugs, or revert to an earlier version. The ability to prevent overwriting is another important benefit of a strong VCS because it preserves all versions for recall and analysis at any stage. Since the changed information is kept over the life of the software solution, developers can “go back in time” to a version that may be stronger or better suited. 

Additional business benefits include the following:

• Improve team productivity and enable collaboration.
• Enhance team communication with a reliable solution.
• Reduce development errors and conflicts.
• Improve customer satisfaction with reliable software versions.

Regardless of business type or practice area, technology, healthcare, government, legal, financial, and so on, VCS are part of everyday software development. Developers, coders, designers, and software engineers are the primary users of a design and build software version control system. Project managers involved in development may also monitor version control practices. Users have several code or version control options that provide both opportunities for appropriate document control and document collaboration. Some options provide strict authorization access controls, while others utilize enhanced control capabilities that foster concurrent collaboration. Each of these configurations has its challenges. Current solutions grapple with the issues of overwriting, appropriate user access, and automated merge capabilities. Whether the team uses a first-come, first-serve system or one that allows multiple user access at one time, each system has pluses and minuses for the team to consider before adoption. 

When choosing a version control system, the first steps include knowing what access you need and how the team is expected to collaborate. How the document is controlled, edited, and merged is also of central importance. Some systems have a one-user-at-a-time lock-edit-unlock protocol, others allow multiple team members to have concurrent access, and still others allow a developer to “own” their version and “branch” their work until they are ready to merge with the main version. The difference in the systems comes down to decisions that aim to balance appropriate file control and access with issues that can enhance productivity through the use of either a centralized or distributed system.
The basic setup of a VCS includes the following components:

• Repository: The main database that stores the metadata for the project files (the main data set is called the trunk).
• Server: The computer that contains the main repository.
• Client: The machine the developer uses to connect to the repository.
• Working Copy: The copy of the project file that the developer edits.

Today’s version control systems work to finding effective collaboration methods rather than a “first-come, first-served” or local-only file protocol. Allowing concurrent access is thought to facilitate the productive collaboration that moves a project forward faster, which is a common element of Agile development. Because version control enables many Agile practices, Agile development teams are proponents of version control. Agile teams tend to favor models that allow merging rather than lock features in order to keep a project moving forward and the team working together. 
G2Crowd provides reviews from version control system users and rates solutions based on customer satisfaction and market presence. The site’s currently ranked products include:

• IBM Rational ClearCase (proprietary)
• Microsoft TFS (proprietary)
• Subversion (open-source)
• Helix VCS (proprietary)
• GIT (open-source)
• Mercurial (open-source)

The G2 Crowd Version Control Systems Grid® is broken down into four categories as follows:

• Leaders: Rated highly by users and have extensive market presence. (Microsoft Team Foundations Server, Helix VCS, and Subversion)
• High Performers: Rated highly by users, but do not have the market presence of the leaders. (Git and Mercurial)
• Contenders: Rated below average in user satisfaction or do not have enough reviews to validate, but have extensive market presence.
• Niche: Lack the market presence of leaders, but don’t have enough user reviews to validate (IBM Rational ClearCase).

When searching for a version control system, consider the following abilities:

• Initialize or create a new and empty repository for each project
• Add a file (import) to the main repository to begin managing version control
• Easy-to-understand naming conventions
• Consistent mechanism for tracking and making changes, commits, synchronization, and merges
• Smooth reversion, backup, and restoration capabilities
• Historical record of who, when, and what changes were made (viewing the differences in two files)
• Concurrent file sharing with automated merge capabilities
• Identifies conflicts for cooperative resolution
• Make improvements by branching individual work before merging files 
• Revert to a previous state
• Provide unique revision with each commit
• Deliver automated and regular updates to team on changes
• Sandbox capability in order to test large changes before committing
• Short- and long-term undo or revert (in order to restore the last version in the event of a mistake)
• Check-in/check-out 
• Include a check-in message to notate changes

A centralized system maintains a central copy of the software project in a single repository, and commits changes to that central version or copy. One of the most well-known centralized version control systems is concurrent version system (CVS). First developed in 1986, the system follows a check-out (export), edit, and check-in procedure. While users can accomplish concurrent work, the system only publishes the most recent version of the file. Problems can occur if two or more developers simultaneously make changes. One can “overwrite” another’s work before others can view it.   

The popular Subversion (SVN) solution offer more flexibility in collaboration options and works to prevent the overwrite challenges of CVS. Many open and closed source providers have subversion models to foster multi-developer usability in a more flexible system. Some of the solutions that use subversion include high-value proprietary performers such as Helix VCS, Microsoft Team Foundation Server, and numerous offerings from big vendors such as IBM. CVS and SVN continue to lead in the category of open sourced, centralized systems.

Distributed open and closed sourced version control systems have different functional elements for collaborative editing and sharing. A key element is that there is not one centralized repository for change information. Instead, each developer has their own historical record and their own repository. This approach is often credited with moving a project along faster than its centralized counterparts. Distributed version control systems (DVCS) allow each developer to work out challenges before adding to the master document in the main repository; these multiple “working copies” are in process for eventual merge or rejection. This style is often cited as a good system for large-scale projects. Like the centralized system, DVCS works to avoid the problems of stepping on or overwriting others’ work, and provides document history preservation and reversion capabilities. Key open source solution providers are Git, GNU, and Mercurial, which replaced BitKeeper in 2005. Of note, BitKeeper was one of the main open source systems that supported a local-only model of one file system for all users.

Best practices for version control run the gamut from the simple to the more complex. Here are other best practices to consider:

• Save changes and back-up code consistently and frequently. 
• Use a comprehensible naming convention.
• Manage appropriate controls to allow proper, productive access.
• Ensure developers can easily pull up necessary documents.
• Define team, individual, and read only access to streamline document availability and allow users to perform their functions in a timely manner. 
• Mitigate problems with file lock out or check out systems that hold a file hostage when a developer calls in sick, or keeps the file too long. 
• Expedite timely merges, especially when numerous working copies are outstanding. 
• Support Agile teams with the ability to work simultaneously toward the overall team goals and timeline in order to quickly move a project towards success and maintain the goal of Agile development. 

Zane Bond, a seasoned Product Manager with Cisco, talks about how software versions and naming schemas can be indicative of a product’s maturity. He suggests thinking about the following products and versions:

• Software Blocks 0.89c
• Awesome 3D Studio 7.7 Enterprise edition
• Collection Manager 2014 R2
• Artificial Intelligence Manager 1.0

 When asked, What do those titles and versions mean to you? He replies, “To me, they are very telling:

• Software Blocks: This solution is likely on its 10th or more iteration. They probably have a small conservative development team with a specific goal they have not yet met. I’d bet you can see their entire changelog history in GitHub. As a consumer, I would be hesitant to implement, but if it perfectly solves my problem, I’d go with it.
• Awesome 3D Studio: The product has probably been around for 10+ years, and it’s probably an on-premise solution that solves a problem well. It may not be cheap, but it’ll probably work.
• Collection Manager: I hope this isn’t their current release… because if that’s on the website right now, I would run away screaming; this may be a dead product. Conversely, Collection Manager 2018, at this point, may indicate they are actively pushing and releasing their software.
• A.I. Manager: I’m going to guess this is more artificial than intelligent... I probably wouldn’t touch this product until 1.5 or 2.2. This 1.0 version is probably just a shell of a sales demo and a promise of something awesome to come later.

So, when it comes to software version control and version names, put yourself in the consumer’s seat and consider the following: What not only makes sense to your business, but is it accurately reflective of what you are doing? Then, think about how you will increment the versions over time, document it, and stick with it. Consistency - as long as it’s clear and understandable - is something customers much prefer to varying schemes. If you want a recommendation, I find the simplest to be the year and dot release (for example, 2017.1 and 2017.2). This breaks down many assumptions about the product or its lineage, and brings up other more meaningful questions like: What’s in this release, and do I want it? How far behind am I?”

The language of software version control includes some terms that work within the individual platforms. A branch is a private file separated from the mainline or trunk. Multiple branches can be merged through reverse integration and saved to interleaved deltas, which are more efficient ways to store the changes. Change itself can be called a diff or a delta, which shows the changes between versions. The changes can be merges, updates, or commits to the repository and kept indefinitely.  

Using a system that has a locking mechanism or protocol can lead to breaking the lock, which is an unauthorized system workaround that can generate its own set of problems. Commits, which are a series of changes, can be merged as a group or atomic commits or handled singularly. A file is in conflict when concurrent changes are not in agreement, leading developers to manually resolve the issue. All these functions which can include a shared database or repository, and tagging, baseline, and labels, synonyms that mean a point or snapshot of the project. Updating or revisions are all done within appropriate system specifications to support and move the project forward. 

The core mission of a good VCS is to enable collaborative authoring and data sharing while tracking all historical changes and revisions over time. You can achieve this simple mandate in a number of ways. Finding the appropriate mix of document security and team productivity is often a challenge. You’ll also have to make decisions on how to manage the flow of the files: For example, through increased concurrent editing, a more linear “one developer at a time” policy, or the new hybrids that enhance user access. Combating lost information via overwriting is often a mainline issue. However, how you define user access and structure it to allow appropriate availability of files is also at issue. Whether a team focuses on a centralized or decentralized approach, procedure issues such as file sharing, timely information saving, and proper back-up are essential to the success of any system. Finally, identifying the right balance of file control mechanisms and procedures, and access that promotes communication, cooperation, and productivity for a team is at the heart of deploying the right software version control system.

Today, development teams can work in a single location or multiple offices around the globe. As such they need a collaboration tool that can be accessed virtually anywhere, and that still provides the flexibility needed to move projects along quickly. Smartsheet is a work management and automation platform that enables enterprises and teams to work better. The world’s leading IT professionals rely on Smartsheet to help increase throughput and operate at maximum efficiency. 

Use Smartsheet to improve accuracy with real-time updates, increase collaboration with internal and external teams, and boost efficiency with resources centralized in one location. Track cell history and request automatic updates to keep all team members up to date, and to ensure that everyone is working on the same version. Quickly resolve reported issues, gain visibility into issue patterns, and maintain auditable records without additional work.

Learn More About Smartsheet for IT & Operations

Subscribe to the Smartsheet IT Newsletter for tips, strategies, and ideas focused on helping IT professionals increase their impact on their business.