 | Level: Intermediate Pawel Leszek (pawel.leszek@ipgate.pl), Independent consultant
13 Mar 2003 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.
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.
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.
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).
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
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.
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.
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
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 | | | Pawel Leszek, a Studio B author, is an independent software consultant and author specializing in Linux/Win/Mac OS system architecture and administration. He has experience with many operating systems, programming languages, and network protocols, especially Lotus Domino and DB2. Pawel is also the author of series of articles for
LinuxWorld
and a Linux columnist for the Polish edition of PC World. Pawel lives in Warsaw with his wife and sweet little daughter. Questions and comments are welcome; you can contact Pawel at pawel.leszek@ipgate.pl. |
Rate this page
| |
