CSC/ECE 517 Fall 2009/wiki1a 4 co

From Expertiza_Wiki
Revision as of 19:07, 7 September 2009 by Catowner (talk | contribs)
Jump to navigation Jump to search

Best Practices For Source-Control Management With Version-Control Systems

  “Tip 23: Always Use Source Code Control” 
         – Hunt and Thomas, The Pragmatic Programmer [HT 00]

In software development, change is almost always inevitable [P 05] . Using a source configuration management (SCM) system (also known as a Source Code Control System (SCCS) or version-control system) can help individuals and teams manage the changes that occur during the software development process [D 90]. This article will provide the reader with basic information, and direct the reader to additional reading for more in-depth consideration.

Why Source Code Control is Necessary

According to Pressman, “Change is inevitable when computer software is built. [P 05]” He suggests four primary reasons for change:

  • New business or market conditions
  • New customer needs
  • Reorganization, business growth, or downsizing
  • Budgetary or scheduling constraints

Each of these reasons can cause changes in project requirements, in project priorities, or in the resources available to create or enhance a project. Managing the change with an SCM enables engineers to focus on technical work, and enables project managers to control changes which can affect project outcomes.

Links and Resources

These links and resources can help the reader further understand the need for source code control:

Understanding Basic Concepts

For the reader new to SCM, there are a few basic terms and concepts that should be understood before best practices are considered:

  • Check-in or Commit – Writing changes to the source code repository
  • Lock-Modify-Unlock Model: An SCM model that requires a developer to reserve or lock a source file before making changes to the file. This lock prevents other developers from modifying the file.
  • Change-Modify-Merge Model: An SCM model that allows multiple developers to make changes to a source file. Upon commit, if the source file has been updated by another developer, a merge of the updated file with the developers change is necessary in order to preserve all the updates. Depending on the SCM and the nature of the change, the merge operation may be performed by the SCM or by the developer.
  • Revision – The version identifier of the source file (e.g. v1, v2, v2.1, etc). Each commit of a source file will produce a new revision value.
  • Baseline – The root of a development stream, where changes that are intended to be integrated into the main project will eventually migrate.
  • Branch – An offshoot from the baseline where prototype, testing, or other work can be performed that does not immediately affect the baseline. Eventually, a branch may be merged back into the baseline.

Links and Resources

These links can provide the reader with additional information on SCM vocabulary:

Advice on Using an SCM or SCCS

There is differing advice on using an SCM to manage projects, but there are some consistent messages:

  • Use a source configuration management product.: When working on teams, there is a general consensus that an SCM will greatly help the team manage changes. Further, Hunt and Thomas [HT 00] suggest that even an individual should use an SCM to manage their work, even if their team does not, because of its ability to archive work and to "undo" mistakes.
  • Commit code changes frequently.: Much of the advice suggests that source code should be integrated on a regular basis, some even suggesting checking-in code every few hours.
  • In a Lock-Modify-Unlock model, check-out only what you need.: This advice is probably obvious, but in the Lock-Modify-Unlock model, source files will be unavailable for others to update in the Lock phase, so keeping that number of files to a minimum reduces programming team "deadlocks". For development teams that have the maturity or tooling, a Change-Modify-Merge model reduces the concern about reserving files, but does not eliminate the potential issues (in particular, dealing with merge conflicts).
  • Store tooling as well as source code in the SCM.: Actually, much advice suggests storing even more artifacts, but in particular, if a software team wants to recreate a specific version of the software, it will likely be crucial to have access to the original tools that created that version, as well as the source code. See section 6 of the white paper High-level Best Practices in Software Configuration Management by Laura Wingerd and Christopher Seiwald at Perforce Software.
  • more:

Links and Resources

Blah

References

Additional References

  • [P 05] Pressman, Roger S., Software Engineering: A Practitioner’s Approach, pp. 739-768, McGraw-Hill, New York, NY, 2005
  • [HT 00] Hunt A. and Thomas D., The Pragmatic Programmer: From Journeyman to Master, pp. 86-89, Addison-Wesley, Boston, MA, 2000
  • [D 90] Dart, S. “Spectrum of Functionality in Configuration Management Systems, Software Engineering Institute, 1990, available at http://www.sei.cmu.edu/reports/90tr011.pdf.
Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2009/wiki1a_4_co&oldid=18138"