User Tools

Site Tools


Source Code Management


Source Code Management (SCM) is the processes, procedures, policies and tools used in an orgainzation to ensure the integrity, confidentiality and accesibility of the source code developed by and/or for them. Most SCM involves the use of Version Control Software (VCS) the first such tools was the Concurrent Versioning System (CVS) available on most if not all early Unix systems. Modern tools include SVN, Mercurial and Git. GitHub is a “public” repository system and is free for Open Source projects, such as Linux. However, SCM is much more than a set of tools used. It is the procedures, processes and policies an organziation enforces to ensure the quality and availability of its code.

Cliche Guidance

Scott Mitchell in 2008 codified eight commandments of Source Code Control and they reflect well the intention of SCM and some of the tenants of how it should be used in an organizations daily work flow:

  1. You shall check in early and check in often. You anger your coworkers when you check out a file and insist on keeping it checked out until some future point in time that is measured using variables that exist solely in your brain.
  2. You shall never check in code that breaks the build. If you code does not compile, it does not belong in the source control repository.
  3. You shall not go home for the day with files checked out , nor shall you depart for the weekend or for a vacation, with files checked out.
  4. You shall leave a descriptive comment when checking in your code. You need not include your name or the date in the comment as that information is already tracked.
  5. You shall use the 'Undo Checkout' option if you check out a file and do not make any changes. It displeases your coworkers when you check in code that has not changed at all from the original.
  6. You shall not use comments to 'save' defunct code. Fear not, for the code you delete still exists in the source control code history and can be retrieved if needed.
  7. You shall use source control for more than archiving just code. The source code control repository makes an excellent storage for technical docs, SQL scripts, and other documents and files related to the project.
  8. You shall religiously backup your source code control database on a regular basis and store a copy in an off-site location.


There is a page started for Git. Currently this is the goto SCM tool. I have access to it from the command line, Eclipse via EGit and via GitLab on-line. Expect this section to expand in the very near future. The more I've used it the more I've realized it solves many of the reasons for the commandments above.


There is a page started for SVN but it is only there for historical purposes or in case I'm forced to use SVN again. SVN was the tool of choice (it was available and approved) at a previous job, the information on the page contains some information but was oriented for Python and SVN.


This series of Wikis will document the work flow, the policies and standard operating procedures to ensure the viability of the sections code as it goes through various research modes and into eventually into production. Several themes will dominate the discussion and will be a part of the final implemented solutions.

  1. It must be easy (at least understandable) to use.
  2. It must be usable on all systems: Desktops, Atlas3, cfdevsrv, etc.
    1. Tools should be available on all systems
    2. Documentation on how to use it on each system.
  3. It must be documented and enforcable.
  4. It must interface with the system used for maintaining the baseline.
  5. It must have accountability to ensure the integrity of the code and allow the ability to verify who changed which code and when.
  6. It must be language and project independent. Just working in Eclipse for Python or Java is not acceptable. It should work with SAS, SQL and any other documentation needed for any project in the organization including but not limited to PowerPoint presentations.

Learning SCM

Learning about SCM is a daunting process. Below are several resources to serve as a starting point for learning more about it. These are high level documents and for the most part, tool independent. A search for “source code management best practices” in Google led to a discussion at StackOverflow. This lead to several of the links below and started other searches.

  • BetterExplained – A overview of the general version control concepts
  • Practical Perforce – Chapter 7 of the O'Reilly book, provides a solid discussion of software evolution and how SCM fits into it.
  • Source Control HOWTO – A series of articles providing an introduction to source control using “centralized” version control tools such as SourceGear Vault. You may also be interested in the book, “Version Control by Example”. Its content is somewhat more oriented toward “decentralized” version control tools. Its home page is
  • How Bazaar does it – Descripes several workflows using the version control software Bazaar.
  • Eric Redmond's Take – Eric Redmond, of “The Catherdral and the Bazaar” fame and his take on version control.

Generic Version Control (& Misc.) Discussions

  • Best Practices for VC – Gives 7 rules for version control and disagrees with commandment 2 in Cliche Guidance above.
  • KDE's SVN Commit Policy – The K Desktop Environment (KDE) for li/unix systems and their policy for commits.
  • Technical Debt – A discussion of the metaphor “technical debt” as it applies to software development. However, it could be applied to system management as well and is recommended reading for all personnel. Martin Fowler has a discussion on his site as well, with references to other discussions including the one by Steve McConnell above.
software_engineering/source_code_mgmnt.txt · Last modified: 2015/07/27 13:54 by lowcloudnine