Sharing source code within a team project

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.

Back to top

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). Other repositories are supported using the third-party plug-ins described in Support for third-party code management applications.

Back to top

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 — see Figure 1 and Figure 2).

The first step is to set up a repository location that defines connection parameters for the selected CVS server/repository. Be sure to use SSH tunneling (extssh).

Back to top

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, as shown below.

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, as shown below.

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 (see below).

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 (see below). 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 (see below). 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.

Back to top

Support for third-party code-management applications

CVS has a few crucial limitations: it is unable to determine simultaneous changes within a single file or across a whole collection of files, and it is unable to detect logical conflicts between files. Its concept of a conflict is purely textual, arising when two changes to the same base file are near enough to spook the merge command. CVS also doesn't offer any interactive collaboration tools like messaging. Fortunately, CVS isn't the only source code management software supported by the Eclipse Platform. Developers can extend the Eclipse Platform's functionality with plug-ins, and as of 4 Mar 2003, there are 16 plug-ins for team development software. All were created by the Eclipse community or by commercial software vendors. Most of these plug-ins add support for a third-party commercial source-code management system. The most valuable plug-ins are those supporting popular enterprise code management systems like Merant PVCS and Rational® ClearCase. The CVS-SSH2 plug-in, for example, allows access to CVS through an SSH2 session, and the Microsoft Visual SourceSafe (VSS) team provider plug-in adds support for the MS VSS product (also available on non-Windows platforms, such as Linux).

However, my personal favorite plug-in is Koi (see Resources). Even though it isn't strictly used for source-code control, this innovative tool adds many additional activities to collaborative development. The current version supports workbench-to-workbench messaging, shared markers, conflicting change notification, shared calendar, and event notification. Koi uses XML-RPC as the communications model in its client-server architecture. The clients are individual Eclipse Platform instances that communicate with a collaboration server that is also an Eclipse plug-in. Koi uses a JDBC-accessed relational database as data storage. A link to the full, categorized registry of Eclipse plug-ins is available in Resources.

Resources

Learn

• Join the Eclipse Platform community at Eclipse.org. The Eclipse Platform source code is licensed under the Common Public License. Eclipse.org also has a glossary of terms and descriptions of Eclipse projects, along with technical articles and newsgroups. The Eclipse Platform whitepaper (at Eclipse.org) describes in detail the major components and functions of Eclipse.
  
  
• Check out the full categorized registry of Eclipse plug-ins.
  
  
• For background on the Eclipse Platform, see the developerWorks article "Working the Eclipse Platform."
  
  
• For an introduction to using the Eclipse Platform and using Eclipse plug-ins to edit, compile, and debug an application, see the developerWorks article "Getting started with the Eclipse Platform."
  
  
• Read "Using the Eclipse GUI outside the Eclipse Workbench" Part 1, Part 2, and Part 3.
  
  
• Check out "Plug a Swing-based development tool into Eclipse," "Create native, cross-platform GUI applications," "Internationalizing your Eclipse plug-in," and "Testing your internationalized Eclipse plug-in."
  
  
• For an introduction to developing Eclipse plug-ins, see "Developing Eclipse plug-ins."
  
  
• Check out the "Recommended Eclipse reading list."
  
  
• Browse all the Eclipse content on developerWorks.
  
  
• Users new to Eclipse should check out Eclipse project resources' Start Here.
  
  
• Expand your Eclipse skills by checking out IBM developerWorks' Eclipse project resources.
  
  
• To listen to interesting interviews and discussions for software developers, check out check out developerWorks podcasts.
  
  
• For an introduction to the Eclipse platform, see "Getting started with the Eclipse Platform."
  
  
• Stay current with developerWorks' Technical events and webcasts.
  
  
• Watch and learn about IBM and open source technologies and product functions with the no-cost developerWorks On demand demos.
  
  
• Check out upcoming conferences, trade shows, webcasts, and other Events around the world that are of interest to IBM open source developers.
  
  
• Visit the developerWorks Open source zone for extensive how-to information, tools, and project updates to help you develop with open source technologies and use them with IBM's products.
  
  

Get products and technologies

• Download CVS clients, servers, and source code from CVS or LORIA.
  
  
• Check out the latest Eclipse technology downloads at IBM alphaWorks.
  
  
• Download Eclipse Platform and other projects from the Eclipse Foundation.
  
  
• Download IBM product evaluation versions, and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
  
  

Discuss

• The Eclipse Platform newsgroups should be your first stop to discuss questions regarding Eclipse. (Selecting this will launch your default Usenet news reader application and open eclipse.platform.)
  
  
• The Eclipse newsgroups has many resources for people interested in using and extending Eclipse.
  
  
• Participate in developerWorks blogs and get involved in the developerWorks community.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Sharing source code within a team project
• How the Eclipse Platform supports code management
• What is CVS?
• Source code workflow with Eclipse/CVS
• Support for third-party code-management applications
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Open source on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers