Get
an overview of how the Eclipse Platform supports source-code
version control in software projects. We begin with
a brief discussion about the ideas for team code development,
then see how Eclipse works with CVS code repositories.
We'll also look at some of the source-code management
software tools supported through Eclipse plug-in extensions.
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.
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.
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).
Figure 1. Switching to the CVS Repository
Exploring perspective
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).
Figure 2. Browsing CVS repositories
in the CVS Repository Exploring perspective
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.
Figure 3. Sharing a local project
with the CVS repository
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.
Figure 4. Creating a new project
from the existing CVS repository
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).
Figure 5. Comparing the local version
against the repository
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.
Figure 6. Committing changes to the
remote 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.
Figure 7. Viewing revision history
along with comments in the CVS Resource History window
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.
Figure 8. Creating a patch for source-code
distribution
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.
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.
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
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.
| 
