CSC/ECE 517 Fall 2009/wiki1a 4 co

From Expertiza_Wiki
Revision as of 15:28, 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

Blah

Advice on Using an SCM or SCCS

Blah

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=18034"