Wednesday 25 January 2012

Source Control HOWTO by Eric Sink


Please have a look at the web link http://www.ericsink.com/scm/source_control.html

Website gives detail explanation about Source Control. Click on the link to read the content.

Chapter 0: Introduction
Our universities don't teach people how to do source control.  Our employers don't teach people how to do source control.  SCM tool vendors don't teach people how to do source control.  We need some materials that explain how source control is done.  My goal for this series of articles is to create a comprehensive guide to help meet this need.
Chapter 1: Basics
Our discussion of source control must begin by defining the basic terms and describing the basic operations.
Chapter 2: Checkins
In this chapter, I will explore the various situations wherein a repository is modified, starting with the simplest case of a single developer making a change to a single file.
Chapter 3: File Merge
Many software teams have discovered that the tradeoff here is worth the trouble.  Concurrent development can bring substantial gains in the productivity of a team.  The extra effort to deal with merge situations is usually a small price to pay.
Chapter 4: Repositories
A file system is two-dimensional:  its space is defined by directories and files.  In contrast, a repository is three-dimensional:  it exists in a continuum defined by directories, files and time.  An SCM repository contains every version of your source code that has ever existed.  The additional dimension creates some rather interesting challenges in the architecture of a repository and the decisions about how it manages data.
Chapter 5: Working Folders
The repository is the official archive of our work.  We treat our repository with great respect.  In contrast, we treat our working folder with very little regard.  It exists for the purpose of being abused.  Our working folder starts out worthless, nothing more than a copy of the repository.  If it is destroyed, we have lost nothing, so we run risky experiments which endanger its life.
Chapter 6: History
There is nothing endearing about a development team that can't find something when they need it.  A good SCM tool must do more than just keep every version of everything.  It must also provide ways of searching and viewing and sorting and organizing and finding all that stuff.
Chapter 7: Branches
A branch is what happens when your development team needs to work on two distinct copies of a project at the same time.
Chapter 8: Merge Branches
Successfully using the branching and merging features of your source control tool is first a matter of attitude on the part of the developer. No matter how much help the source control tool provides, it is not as smart as you are. You are responsible for doing the merge. Think of the tool as a tool, not as a consultant.
Chapter 9: Source Control Integration with IDEs
Instead of selecting one of each kind of tool, we select an Integrated Development Environment (IDE), an application which collects all the necessary tools together in one place. Microsoft's Visual Studio Team System takes this trend to a higher level than we have previously seen.  Mainstream IDEs in the past have provided base operations such as editing, compiling, building and documentation.  Now Visual Studio also has unit tests, visual modelling, code generators, and work item tracking.  Furthermore, the IDE isn't just for coders anymore.  Every task performed by every person involved in the software development process is moving into the IDE.

No comments:

Post a Comment