694 WebSphere Studio Application Developer Version 5 Programming Guide 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 development of Version 2. Note: The support for Rational ClearCase and ClearCase LT is provided through a separate plug-in, also included in Application Developer. Chapter 21. Version control 695 Resources 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. 696 WebSphere Studio Application Developer Version 5 Programming Guide Versions A 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. Chapter 21. Version control 697 Figure 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 698 WebSphere Studio Application Developer Version 5 Programming Guide The 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. Chapter 21. Version control 699 Figure 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 700 WebSphere Studio Application Developer Version 5 Programming Guide Table 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. Application Developer CVS ClearCase Workspace File system Work area Repository Repository VOB Branch Branch (tag) Stream and project Project Module View Resource File Element Commit Commit Check-in Update Update Compare with Version Version (tag) Version © Copyright IBM Corp. 2003. All rights reserved. 701 Chapter 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. 702 WebSphere Studio Application Developer Version 5 Programming Guide Introduction Concurrent 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. Chapter 22. Using Concurrent Versions System 703 The 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 . views 700 WebSphere Studio Application Developer Version 5 Programming Guide Table 21-1 Application Developer, CVS and ClearCase terminology comparison Summary In this chapter we introduced version. basics” on page 23 for detailed instructions. 702 WebSphere Studio Application Developer Version 5 Programming Guide Introduction Concurrent Version System (CVS) is a simple open-source software. 694 WebSphere Studio Application Developer Version 5 Programming Guide Access control—This is normally done at the component level,