Using Version Control System in Eclipse

Version Control System is an important component of Source Configuration Management (SCM). Using it, you can record the history of sources files, and documents. One such utility which Eclipse supports out of the box is CSV (Concurrent Versions System).

Most of today's applications are developed by a team of people. Even small projects that involve only a few developers require tight control over changes in source code. This is a task for source-code management software. Two core features must be supported by source-code version-control software:

• A way to coordinate and integrate changes into the source code
• A history of the work submitted by the team

As team members produce new work, they share this work by committing those changes to the repository. Similarly, when they wish to get the latest available work, they update their local workspaces to the changes on the repository. This means the project repository is constantly changing as team members submit new work. In the other words, the repository should represent the current state of the project. At any point, team members can update their workspaces from the repository and know they are up to date.

Maintaining history is also important so you can compare the current work against previous versions, and if needed, revert to the older work. Coordinating the team's work so that there is only one definition of the current project state, and containing the integrated work of the team are also essential to managing version control. This coordination is probably the hardest goal to achieve.

An optimal model is one where any member of the team can make changes to any resource he has access to. Because two team members can commit changes to the same resource, conflicts can occur and must be dealt with. This model assumes that conflicts are rather unique. Unfortunately, no source code exists in isolation; it typically contains implicit or explicit dependencies on other resources. Source code has references to artifacts described in other source code resources. And this is the point where source-code management software ends its work because it isn't a substitute for project management. Project managers must do their work: coordinating others' work, and looking after schedules, project phases, and release dates. Further, source-code management is not a substitute for developer communication.

How the Eclipse Platform supports code management

The Eclipse Platform offers the capability to share code and work as a team on a software project. Eclipse supports a wide range of code-management solutions, thanks to its plug-in architecture (however, CVS support comes out of box). The focal point of the Eclipse Platform architecture is the workspace. The workspace maintains everything necessary for building and testing a software project. It contains the objects (source code and resources). It also holds the configuration settings for the project, the IDE, and the plug-ins. The workspace is locally maintained on a developer's machine, and teams collaborate through external repositories that are meeting places for code parts from different developers. Repositories are accessible through the client-server architecture via the Internet.

The Eclipse Platform offers support for team development operations directly from the workspace. This support allows a developer to concurrently interact with several separate repositories and versions of code or projects. Resources within the workspace allow the team support component to deal with version and configuration management issues. Of course, single workspaces can access different types of repositories simultaneously. The Eclipse Platform does not provide its own code-management solution; it always depends on external systems. The Eclipse Platform has built-in support for only one (albeit the most popular) source-code management system: Concurrent Versions System (CVS).

What is CVS?

CVS started out as a collection of shell scripts in 1986, but it has evolved into the most popular source code version management solution for software developers. CVS is the open source client/server solution for code versioning and is available for variety of platforms, including Linux® and Windows® NT/2000/XP. See Resources for download links for CVS clients, servers, and source code.

In general, the primary function of CVS is to record the history of source files. When a group of developers work on the same project, CVS insulates them from each other. Every developer works separately, in his own directory and merges (from time to time) the results of the work with the CVS repository.

Eclipse has a built-in CVS client that is deeply integrated with the Eclipse Platform IDE, which is implemented as a separate perspective (CVS Repository Exploring Perspective) for interacting with CVS. General Eclipse settings for CVS are located under Window > Preferences window > Team. After switching to the CVS Repository Exploring Perspective, all CVS operations become available (go to Window > Open Perspective > Other > CVS Repository Exploring menu).

The first step is to set up a repository location that defines connection parameters for the selected CVS server/repository.

Source-code workflow with Eclipse/CVS

In the CVS team cooperation model, team members do all of their work on their own workbenches, isolated from others. Eventually, they will want to share their work. They do this via CVS repositories. CVS uses a branch model to support multiple courses of work that are isolated from each other, but still highly interdependent. Branches are where a development team shares and integrates ongoing work. A branch can be thought of as a shared workbench that is updated by team members as they make changes to the source code. This model allows individuals to work on a CVS team project, share their work with others as changes are made, and access the work of others as the project evolves.

A special branch, referred to as head, represents the main course of work in the repository (a head is often referred to as the trunk). As resources are committed to the branch, these dependencies can be affected. Ensuring the integrity of the dependencies is important because the branch represents the current project's state. Of course, at any point, a team member could make use of the branch contents as the basis for new work.

Those rules apply not only to the CVS: there are common steps for source-code management within team projects no matter what version-control software is in use. Below is an example workflow that uses Eclipse's built-in support for CVS:

1. Starting a new team project

Each new, empty Eclipse project can be shared through CVS (or any other supported source code management system). Developers can also share their existing code by migrating it to the repository. To do this, use the Team > Share Project option located in the context menu that displays when you click the project main folder.

Another option is to create a new workbench project by importing code from the selected branch of the CVS repository. Simply select the appropriate branch (or head), then select Checkout As Project from the context menu in the CVS Repository Exploring Perspective.

2. Working with code and making changes

Developers work with code locally via the Eclipse workbench, creating new resources, modifying existing ones, writing commentaries, and saving locally as they go.

3. Synchronizing local changes with the CVS repository

If a developer on a project is ready to commit his work, the first step is to perform the update operation. This will check the repository for incoming changes and add them to that developer's local workbench. This ensures that the developer knows the changes that might affect the integrity of what he is about to commit. Compare a local version against code stored in the repository using the Compare With option in the project context menu.

The next step is to resolve any conflict that eventually appears and try to compile the code again. If everything works, then perform the commit operation using the Team > Commit option from the project context menu, as shown below. This will integrate all changes into the repository.

4. Managing repositories

CVS allows developers to isolate changes into separate lines of development, known as branches. When one developer changes files on a branch, those changes do not appear on the main trunk or on other branches. Those branches are named subversions or code forks. Later, moving changes from one branch to another branch (or the main trunk) is performed by the merging operation. Then revisions are committed. This effectively copies the changes onto another branch. Eclipse makes it easy to move between development branches using the Team > Branch option from the project context menu.

Of course, when a development team maintains a large repository, it is necessary to have a control over commit and merge operations within projects. Eclipse/CVS integration offers a special view: the CVS Repository History. It gives a quick preview on changes in the repository performed by team members.

The Eclipse Platform comes with a few utilities that support code management. The most useful is the patch function. It compares code from two sources, such as a local workbench and the repository, then creates a UNIX®-like patch file containing code differences. This file can be sent to developers to upgrade source code to the newest version.

5. Disconnecting a project from CVS

When the project development has ended and the team wants to freeze source code, the final version of the project can be removed from the head repository. Disconnecting a project from CVS disables the repository operations that can be performed on the project and its resources, and optionally removes the CVS information associated with the project.

Disconnecting operations can be performed from the Team > Disconnect option in the project context menu. By choosing this option, the Confirm Disconnect from CVS dialog opens. When the project is disconnected from the repository, the team must then decide what to do with the CVS information. The first option is "Delete the CVS meta information," which disables the CVS team menu operations and removes the CVS folders and their contents from the file system. The second option is to use the "Do not delete the CVS meta information," which disables the CVS team menu operations, but leaves the CVS meta information.

Source of the above post: http://www.ibm.com/developerworks/library/os-ecshare/