You could, for example, be making fixes to Version 1.3 of a product in order to evolve to Version 1.3.1, while at the same time working on the Note: The support for Rational ClearCase an
Trang 1 Access control—This is normally done at the component level, and inherited
downward from parent components to children components Advanced systems support fine-grained access control policies, that go beyond simple read and write permissions
Process management—The above-mentioned functions are not
independent from each other They should work in a concerted manner At least, the functions should be embedded into a set of procedures to follow when applying changes to IT solutions Given the importance of this aspect, it calls for a tool that supports and enforces an SCM process while at the same time providing flexibility in this respect
To enable such features, Application Developer has a plug-in called Team Support It lets the environment take advantage of external SCM systems through the use of adapters Each SCM product requires a specific adapter, that should be supplied by the product vendor Application Developer includes an adapter for Concurrent Version System (CVS)
The choice of a particular SCM usually affects the users’ workflow, because the steps for retrieving files, comparing their content with local content, returning updated files to the repository, and so forth, depend on the product that offers these services For this reason, this chapter only covers the concepts relative to Application Developer’s support for SCM systems
Repository
SCM systems store software components in a persistent storage called a repository Repositories coordinate multi-user access to the artifacts shared by the development team Projects in a repository can be of two forms: a branch (modifiable) or a version (immutable)
Branches
A branch is a shared work area that lets team members release their work and use code updates from others Teams share and integrate their ongoing work in branches Thus, a branch represents the current state of a shared project
A repository can contain multiple branches, such as one for new development and another one for maintenance Projects may be developed in multiple parallel branches You could, for example, be making fixes to Version 1.3 of a product in order to evolve to Version 1.3.1, while at the same time working on the
Note: The support for Rational ClearCase and ClearCase LT is provided
through a separate plug-in, also included in Application Developer
Trang 2Resources normally do not exist in isolation but typically have implicit or explicit dependencies on other resources For example, Web pages have links to other Web pages, and source code has references to artifacts defined in other source code resources
As resources are released to the branch, these dependencies can be affected Ensuring the integrity of the dependencies is important because a branch represents a current valid project state At any point, a team member should be able to take the branch contents as a basis for new work
Synchronizing
Resources can be changed in the team members’ individual workspaces without affecting the branch Each developer must explicitly commit changed resources
to the branch, while taking care not to overwrite resources changed by other developers This process is called synchronization
In Application Developer, you may choose to synchronize your workspace with the branch in just one step, or by first updating your workspace and then
committing your changes to the branch
Updating is the process of copying changes other developers have made into your local workspace This ensures that you will have the latest work from the other team members incorporated in your work as well
During update, conflicts due to parallel changes may arise These conflicts must
be resolved in your local workspace Application Developer offers you the necessary tooling that makes this process easier Do not forget to do the appropriate testing before considering the update process successful
After you have updated your workspace with the latest resources in the branch, merging any conflicting changes and making the appropriate tests locally, you can safely commit your changes to the branch
When you commit your changes, they get copied from your local workspace to the branch As a result, these changes will be seen by other developers as incoming changes when they later update their workspaces
Important: If you do not resolve conflicts between your local workspace and
the branch before committing your work, you run the risk of overwriting
resources that were updated by other team members Application Developer will let you do that, because that might be just what you want to do Exercise special care when proceeding this way
Trang 3A version constitutes the baseline of a project at a particular point in time When
a resource is versioned, a non-modifiable copy of it is released to the repository
If you later change the resource in your workspace, the version you created will not be affected
It is possible to version a resource without versioning the project that contains it You would do that if you wanted to create temporary baselines that alone were not enough for a new project version Most of the time, though, you will version entire projects During the synchronization of a whole project, the contained resources are implicitly versioned
You may create versions of resources that are either on your workspace or on the branch When you version a set of resources from your workspace, their current state will be frozen and made a version This is the preferred method of
versioning because when you do so, you know exactly what will be released into the version
When you version set of resources from the branch, the current state of the branch frozen and versioned You should not do that unless you are sure what is currently committed to the branch
Concurrency strategy
Application Developer uses an optimistic concurrency strategy in the sharing of the repository resources This means that any member of the team can make changes to any resource he or she has access to Because two team members can commit to the branch changes to the same resource, conflicts can occur and must be dealt with This model is termed optimistic because it is assumed that conflicts are rare
Important: It is often preferable to synchronize resources with the repository
before versioning This will ensure that there are no standing incoming or outgoing changes that might be accidentally excluded from the version
Trang 4Figure 21-5 shows how two developers would work on the same resource at the same time:
Figure 21-5 Concurrency workflow
Note: The optimistic concurrency strategy is essential to the development of
J2EE applications Some resources, for example deployment descriptors, must be maintained by the whole team at the same time, because they contain information that pertain to the work of every developer on the team
Take an EJB module, for instance If the traditional pessimistic concurrency strategy were to be adopted, developers would have to take turns when creating and editing EJBs, because most of the time the process involves altering the EJB deployment descriptor The use of such model is a practical impossibility for J2EE
The secret to the success of the optimistic strategy is a good synchronization tool that eases the process of resolving conflicts that will certainly appear Fortunately, Application Developer offers such a tool
Developer 1
Developer 2
Branch
Time
commit
update
Initial Project Load
or Development
Change #1
Change #2
commit
commit update
update
Trang 5The ideal workflow is one in which the stream integrity is always preserved and change conflicts are detected and dealt with Such a work flow should follow these steps:
Start fresh—Before starting to work, the developer should update his or her
workspace with the content of the branch If there is no local work that has to
be preserved, the fastest way to achieve this is to select the whole project on the branch and add it to the workspace This will overwrite any local copies of the project resources with those from the branch
Make changes—The developer can now work locally in the workspace New
resources can be created and existing ones modified All changes are saved locally in the workspace file system
Synchronize your work in two steps:
– Update—The developer can examine all incoming changes and add them
to the local workspace In this way, it can be determined whether there are changes which might affect the integrity of what is about to be released The developer has to resolve conflicts, retest, then run integrity checks (for example check for broken hypertext links, ensure the code compiles, and
so forth)
– Commit—When the developer is confident that the changes are well
integrated with the latest branch contents, they can be committed to the branch To be absolutely sure, the update step might be repeated before the final release to check that there are no new incoming changes
Under some circumstances, this work flow may be simplified You may be confident that incoming changes do not affect you, and choose to commit without updating In general, however, team members should be encouraged to follow a flow similar to the one presented above to ensure that the branch’s integrity is not accidentally compromised
Application Developer team support
Application Developer delivers adapters for two SCM products: Concurrent Versions System (CVS) and Rational ClearCase LT Both adapters are included with the default installation, but neither of the SCM product servers will be installed automatically You have to install the desired server manually, either before you begin your Application Developer installation or after it has been completed
The diagram in Figure 21-6 shows a comparison of the functionality of the two SCM products for which adapters are shipped with Application Developer
Trang 6Figure 21-6 SCM tools: functionality comparison SCM adapters for other commercial SCM products are provided by the vendors
of these products To find a list of SCM products and adapters provided by IBM Business Partners, go to the SCM Adapters page on the Application Developer site:
http://www.ibm.com/software/ad/studioappdev/partners/scm.html
Terminology comparison
When working with Application Developer, you will use the terminology provided
by the team development environment When you use facilities of SCM systems outside of Application Developer, you also have to understand their terminology Table 21-1 shows the mapping between terms used in Application Developer, CVS, and ClearCase
ClearCase
Version control Parallel development Life cycle integration UCM out of the box Web Browser interface Promotion Model Baseline Comparison Snapshot views
Dynamic views Binary Sharing Auto build dependency Distributed builds Distributed servers Support for MultiSite
Freeware Open source community.
Included with Application Developer Low cost of adoption
Sold exclusively by Rational Software Upgrade for ClearCase LT
CVS Version control Parallel development Life cycle integration
ClearCase LT
Version control Parallel development Life cycle integration
UCM out of the box Web Browser interface Promotion Model Baseline Comparison Snapshot views
Trang 7Table 21-1 Application Developer, CVS and ClearCase terminology comparison
Summary
In this chapter we introduced version control, the local history, and the basic terms of team programming
In Chapter 22, “Using Concurrent Versions System” on page 701 we explore CVS in detail
In Chapter 23, “Using ClearCase” on page 747 we explore Rational ClearCase
LT in detail
Trang 8Chapter 22. Using Concurrent Versions
System
In this chapter we introduce you to Concurrent Versions System (CVS), a widely adopted open-source version control system It can be used by individual developers as well as by large, distributed teams We discuss how to set up a CVS server on the Windows platform and use it with Application Developer’s client interface
This chapter describes the following:
What is CVS?
How to install CVSNT on the Windows platform
How to create a new repository and configure it in Application Developer
CVS Resource History view
Branches in CVS
Working with patches
22
Note: To complete the steps described in this chapter, you need two instances
of Application Developer, one for each of the two simulated team members It
is much easier and more efficient to do so using two different machines, but you can also open two Workbenches on just one machine with two
workspaces Refer to the “Workspace basics” on page 23 for detailed
instructions
Trang 9Concurrent Version System (CVS) is a simple open-source software configuration management (SCM) system Of the SCM features listed in the previous chapter, CVS implements only version control It can be used by individual developers as well as by large, distributed teams
Some of the main features of CVS are:
Multiple client-server protocols over TCP/IP, that let developers access the latest code from a wide variety of clients virtually anywhere an Internet connection exists
It stores all the versions of a file in a single file using forward-delta versioning, which stores only the differences among the versions
It insulates the different developers from each other Every developer works in his own directory, and CVS merges the work in the repository when each developer is done Conflicts should be resolved in the process
It uses an unreserved checkout approach to version control that helps avoid artificial conflicts common when using an exclusive checkout model
It keeps your shared projects’ data in repositories Each repository has a root directory on your file system
CVS maintains a history of the source code revisions Each change is stamped with the time it was made and the user name of the person who made it It is recommended that developers also provide a description of the change Given that information, CVS can help you find answers to questions such as: Who made the change? When was it made, and why?
Note: Application Developer supports two communication protocols:
pserver (password server) and ssh The default is pserver The other protocols have to be manually configured through Window -> Preferences -> Team -> CVS -> Ext Connection Method
Important: CVS and Application Developer have a different understanding
of what a conflict is:
For CVS, a conflict arises when two changes to the same base file are close enough to be noticed by the merge command
For Application Developer, a conflict exists when the base revision of a modified file is different from the revision stored in the repository
Trang 10The CVS server code for Linux and UNIX platforms is available at the project’s site:
http://www.cvshome.org
Please refer to it for information about how to install and configure your CVS repository
Installing CVS on the Windows platform
Application Developer comes with a CVS client, but you still have to install the server Even though it is recommended to use CVS on platforms other than Windows for large-scale development, for simplicity we will use a Windows server throughout this chapter: CVSNT
You can download CVSNT straight from the server site:
http://www.cvsnt.org/
Follow these steps to install CVSNT Note that you must have Windows administrative rights to be able to follow these instructions:
Download and execute the installer, in our case cvsnt-2.0.0rc3.exe
Select the typical install and leave all the options at their default values
Reboot your machine, even if the installer does not tell you to do so This step will guarantee that the environment variables are properly set up
Creating a CVS repository on CVSNT
First you have to create a new repository Open your control panel by selecting Start -> Settings -> Control Panel Double-click the CVS for NT icon to open the service configuration dialog (Figure 22-1)
Important: CVSNT is not officially supported by the Eclipse platform
Depending on the version, different bugs may occur In our case, we used CVSNT 2.0.0rc3 without any problems
An important note about CVSNT support can be found at:
http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home /docs/online/cvs_features2.0/cvs-faq.html