COMP 310 Spring 2010	Lec11: Source Control and Ball Initializations

Using Subversion Source Control with the Subclipse Plug-in -- the Basics

What is Source Control?

Source control is a centralized repository for the code and other files associated with a software project.   Source control allows a developer to manage these files in a safe manner, especially when multiple developers are working on the same codebase.   Source control has a number of very useful features, of which these are the basics:

• Versioning:  A history of the changes that were made to the code is kept, allowing previous versions to be viewed and restored ("rolled back").   To "commit" a set of files is to create a new version of those files.

• Change reconciliation:  When multiple developers have changed the same file, a orderly process must take place to merge the multiple copies and to resolve any conflicts in the changes.

• Code Branching/Rejoining:  Sometimes development proceeds along two or more parallel tracks.   The source control system will maintain all the tracks and then merge back together when desired.

In addition, the source control system may contain or be supplemented by various ancillary functions such as

• Automatic builds:  The code may be compiled either on every commit or on a scheduled basis.   It is often possible to set the system up to reject a commit if the build of the new code fails.

• Automactic testing: Unit tests can be run automatically on the code, either on every commit or on a scheduled basis.  As with automatic builds, it is often possible to configure the system to reject a commit if the tests fail.

• Code analysis:  The code can be analyzed for errors and/or coding style issues.

• Bug/Issue tracking:  Bugs or other issues are logged and managed.

• Task management:  The system may be able to track and manage tasks that have been assigned to individual developers.

• Project quality metrics:  Using various measures, e.g. number of lines of code altered, number of bugs/issues, etc, reports can be generated to give the developers a better sense of how well their project is progressing.

Two Styles of Source Control:

1. Commit-and-merge:   In this style, anyone can work on any file at any time, but when they commit the file back to the repository, the system attempts to merge its code with any other changes to the same file that have already been committed.    These sorts of systems are easy to manage but can present some difficult merging issues.   Subversion is a commit-and-merge style source control system.

2. Check-out/Check-in:   In this style, only one person can work on any given file at a time.   That person checks the file out to work on it, gaining an exclusive lock on that file that prevents other people from modifying it while it is checked out.   When the person is done, they check the file back in, creating a new version and releasing it for modification by other people.   the advantage of this style is that it avoids the potentially messy merge process.   The down side is that it requires greater levels of synchronization between the user's local files and the repository plus excessively long check-out periods by other people can be frustrating.    Microsoft's Team Foundation Server which Visual Studio, is a check-out/check-in style of source control.

A word of advice:

One of the more difficult tasks of source control involves keeping the local files system properly synchronized with the repository.  In such, it is generally very dangerous to manipulate files that are under source control from outside of the source control system, e.g. renaming, moving or deleting files using Windows Explorer.  

Always manage files under source control from inside the source control system, e.g. from within Eclipse+Subclipse.  

Popular Source Control Systems and Ancillary Systems

• Concurrent Versions System (CVS):  The original open-source source control system.

• Apache Subversion (SVN):  The open-source source control system we are using.  SVN was designed to be a "better CVS".

• Microsoft Team System :  Microsoft's all-in-one solution for Microsoft, particularly .NET languages, that includes source control, Team Foundation Server (TFS) plus automated build, test, code analysis, bug/issue tracking, task management and project metrics.

• Hudson -- A Java source control system.

• Git: Another open-source source control system 

• Apache Ant -- an automated script that can be used to do automated builds and tests.  

• JUnit and NUnit: Unit testing frameworks for Java and .NET respectively.

Using Source Control

• Directions on using the Subclipse plug-in for SVN

• Directions on using Subclipse for assignment turn-in.

Ball Initialization

 Consider processes such as setting the intial velocity, radius and color of a ball.   Is this a variant or invariant process?  

Strategies may need to initialize their host ("context") ball, doing tasks such as

• Setting the velocity to zero if the strategy is supposed to create a stationary ("Rock") ball, 

• Connecting the movement system for a ball under user control ("Move" strategy)

• Connecting the  output display for a ball that updates the screen ("Score" strategy).

This all comes down to the addition of another method on the update strategy to initialize the host ball.  There are a few issues to be addressed however:

1. For dynamically composed, compound strategies, how does one insure that all initializations have been performed?   (Consider the effect on both the MultiStrategy and the SwitcherStrategy.)

2. Since strategies can be dynamically changed in a ball, e.g. with a Switcher strategy, how does one insure that the ball gets properly re-initialized?   What are the implications on the code of the ball's constructor so as not to duplicate code?

© 2010 by Stephen Wong