Getting Started with Source Code Management (SCM) for Small Teams
Published on AgileConnection (https://www.agileconnection.com)

[article]

Getting Started with Source Code Management (SCM) for Small Teams

Summary:

Your developers and designers often work on projects simultaneously from around the world. They need to modify the same files, make updates, and deploy multiple versions of the website or code across different sites. All the while, you hope they won’t cross wires, lose track of versions, or overwrite each others’ changes, any which scenario might set your upcoming release or project delivery date back by days. Sound familiar?

Why You Need Version Control
Having a version control or source code management (SCM) system provides a safety net against corruption or accidental overwrites. Version control systems like Subversion and Git are the central (or distributed) repositories where your team compiles a complete history of changes and natural restore points. Versioning systems let you do the following:

  • Roll Back Changes: When you identify a bug, go down the wrong path, or need to revert to a previous version of your work, you’ll want to roll back to previous changes. Just like Apple’s Time Machine backup application, version control for your files lets you roll back to any point in time and restore it if needed.
  • Quick Undo: We’ve all been perpetrators of the accidental post-midnight commit, when we’re not thinking clearly or running on autopilot, yet resulting in downstream trouble. If you commit a quick change, then realize you made a mistake, a version control system allows you to quickly undo the last change(s).
  • Merge Changes Seamlessly: What happens when one developer is working on a file, makes a change, then tries to save it just as another developer is doing the same? Now you’ve got two different versions needing to be resolved (the “split brain” effect). Version control allows teammates to merge changes seamlessly, which is critical when you have multiple developers working on the same project.
  • Track Changes and Ownership: As files are created or modified, you can annotate changes with comments and commit logs that are tracked as your repository evolves over time. The version control system tags each change with the name of the person who made it, making it easy to associate changes with those who are responsible (for better or for worse), and to link them to tasks in your issue tracking system.
  • Branching and Merging: You can break off a piece of your codebase (branch) into a separate area and modify it in isolation. Typically, developers use branches when developing a new feature or fixing a bug – to avoid polluting the main branch. Later, you can merge the code back into the common area.
  • Provide visibility and insight: By monitoring commits and activity usage, you can extract detailed metrics and gauge the performance of your development team. There are many third-party tools you can plug into an SCM to provide useful metrics concerning code quality, duplication & replication reporting, and productivity.
  • Support for multiple file types: You can track changes made to source code (text files) as well as binary files, such as Word documents, media files, and presentations or spreadsheets. And, by using popular clients like TortoiseSVN, it’s easy for non-developers to version media files or business documents in the same repositories.

Choosing the Right Type of Version Control System

With the abundance of free (open source) and commercial version control systems in existence, how do you choose which to use? Most professional developers today prefer open source options, which, according to a recent Forrester survey, are closing in on 50% market share. The two most common today are Subversion and Git.

Subversion
Subversion (SVN), the most widely used version control system today, is a centralized version control system. With SVN, you check out (download) the latest version of the central repository (“trunk”) to your local workstation, make changes, and then merge (upload) those changes back in to the trunk. The centralized nature of the Subversion repository is intuitive to use, encourages collaborative coding behavior, permits fine-grained (sub-directory level) user access control, and is easy to secure and back up.

Pros

    • Centralized control, meaning it’s easier to keep one official history. Good for backups, accountability and security

    • Security: Native subdirectory-level user access restrictions

    • Branches are easy and stored centrally

    • Gentlest learning curve for newbies, and operations like branching become quite intuitive as you progress

    • Ability to lock files, ensuring that others don’t work on the same binary files assets like documents and media files simultaneously

    • Widest adoption among developers

    • History of changes can’t be modified

Cons

    • Working offline means you can’t commit changes to the centralized repository until you have Internet connection, although this does not prevent developers from working on their local copies

    • Generally slower than Git, since most operations need to synchronize with the central server, especially when merging large branches

    • Possible to revise history and preserve only successes, not failur

Git
Built for development of the Linux operating system, Git is a distributed version control system that has an emphasis on being fast. Git projects lack a central repository; rather, every working directory is a full-fledged repository of its own, and is not dependent on network access or a central server. Git is convenient if you want to code offline or have many developers collaborating independently on a single branch, which is why Git is favored in many open source projects.

Pros

    • Decentralized model means many operations are faster and makes offline work more practical

    • More merge options, which are generally faster than Subversion

    • Branching is easier and faster

    • Comes with many tools like ‘bisect’ that can partly automate the process of finding where a bug was introduced

Cons

    • The local copy model means you need to be more careful of backing up your own workstations

    • The large set of commands can be esoteric and present a steeper learning curve

    • There is no file locking, which can cause issues with binary files

    • History can be changed, and being able to edit past commits might not leave the strong paper-trail you’d prefer

About the Author Guy Marion is former CEO of Codesion.com, now VP & General Manager of the Codesion Cloud Services Business Unit at CollabNet Inc. CollabNet provides hosted SCM and developer tools for distributed workgroups and enterprises –try it free for 30 days.

About the author