Source code management of the CVS team

Share source code in team projects

Most of today's applications are developed by a team of multiple people. Even for small projects involving only a few developers, you must strictly control the changes to the source code. This is the task of source code management software. The source code version control software must support two core functions:

• Provides a way to coordinate changes to source code and integrate these changes
• History of the work submitted by the Team

When a team member completes new work, they share their work by submitting these changes to the resource library. Similarly, when they want to get the latest available work results, they can update their local Workspace Based on changes in the resource library. This means that the project resource library will change frequently because the team members submit new work results. In other words, the resource library should indicate the current status of the project. At any time, team members should be able to update their workspace based on the resource library and be sure they are up-to-date.

Maintenance History is also very important, so that you can compare the current work with the previous version, if necessary, you can also reply to the previous version. Coordinates the work of the team so that only the current project status definition exists and includes the work that the Team has integrated. This is also necessary for managing version control. Such coordination may be the most difficult to achieve.

The ideal model is that any member of the team can change any resources that they have the right to access. Because two team members can submit changes to the same resource, conflicts may occur and must be resolved. This model assumes that the conflict is unique. Unfortunately, no source code exists in an isolated manner. Generally, it contains an implicit or explicit correlation with other resources. The source code references the components described in other source code resources. However, the source code management software does not replace project management. Project managers must perform their duties: coordinate the work of other members and take charge of the progress, project stage and release date. In addition, source code management cannot replace communication between developers.

Back to Top

How does the eclipse platform support code management?

The eclipse platform provides teams with the ability to share code and work in software projects. Eclipse supports a wide range of code management solutions thanks to its plug-in Architecture (but support for CVS is now available ). The focus of the eclipse platform architecture isWorkspace. The workspace maintains everything necessary to build and test software projects. It contains objects (source code and resources ). It also saves configuration settings for projects, IDE, and plug-ins. The workspace is maintained locally on the developer's machine. The Team cooperates with each other through the external resource library, and the code of Different developers is collected in the resource library. You can access the resource library through the "client-server" Architecture over the Internet.

The eclipse platform provides support for team development operations directly from the workspace. This support allows developers to interact with several independent resource libraries and different versions of code or projects concurrently. Resources in the workspace allow the team to support components to handle version and configuration management issues. Of course, a single workspace can access different types of resource libraries at the same time. The eclipse platform does not provide its own code management solution; it always relies on external systems. The eclipse platform provides built-in support for only one (but also the most popular) Source Code Management System: Concurrent Versions System (CVS ).Third-party code management applicationsThis section describes how to use third-party plug-ins to support other resource libraries.

Back to Top

What is CVs?

CVS was born in 1986 and appeared as a set of shell scripts, but it has now developed into the most popular source code version management solution for software developers. CVS is an open-source client/server solution for code version management. It can be used on various platforms, including Linux and Windows NT/2000/XP. See the references at the end of this article, including the download links for the CVS client, server, and source code.

Generally, the main function of CVS is to record the history of source files. When a group of developers work on the same project, CVS isolates them from each other. Each developer works independently in his/her own directory, and then uses the CVS resource library (from time to time) to merge the work results.

Eclipse has a built-in CVS client that is closely integrated with the eclipse platform ide. It is implemented as a separate perspective (CVS Repository profiling perspective) for interaction with CVS. General eclipse settings for CVs are locatedWindow-> preferences window-> Team. After switching to the CVS Repository inserting ing perspective, you can use all CVS operations (goWindow-> open perspective-> Other-> cvs repository refreshing ingMenu-seeFigure 1AndFigure 2).

Figure 1. Switch to the CVS Repository indexing perspective

First, set the location of the resource library, which defines the connection parameters used to select the CVS server/resource library. Make sure that the SSH tunnel (extssh).

Figure 2. Browse the CVS resource library in the CVS Repository indexing perspective

Back to Top

Source code workflow of Eclipse/CVS

In the CVS team collaboration model, team members complete their work independently on their respective workbench. Finally, they want to share their work. They use the CVS resource library to achieve this. CVS uses the branch model to support multiple independent and highly dependent workflows ). These branches are the place where development teams share and integrate ongoing work. It can be consideredBranchIs a shared workbench, which is updated when a team member changes the source code. This model allows each developer engaged in a CVS team project to share their work with other Members when making changes and to access the work of other Members during project progress.

AHeadIs used to represent the main workflow in the resource library (head is usually calledTrunk). When a team member submits resources to the branch, these correlations are affected. It is important to ensure the integrity of relevance because the Branch represents the status of the current project. Of course, team members can use the branch content at any time as the basis for new work.

Those rules apply not only to CVS: No matter which version control software is used, the Team Project has some common steps for source code management. The following is a sample workflow supported by CVS built in Eclipse:

1. Start a new Team Project
Every 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 resource library. To share, click the main folder of the project and useTeam-> share projectOptions, suchFigure 3.

Figure 3. Use the CVS resource library to share a local project

Another option is to create a workbench project by importing code from the selected cvs repository branch. Select the appropriate branch (or head) and select the "checkout as project" option from the context menu in the CVS Repository submit ing perspective, as shown in figureFigure 4.

Figure 4. Create a new project from the existing CVS resource library

2. Use and change the code
Developers use code locally through the eclipse workbench, including creating new resources, modifying existing resources, writing comments, and saving the content locally after they use it.

3. synchronize local changes with the CVS resource library
If a project developer is ready to submit his/her work, perform the update operation first. This checks the resource library for the introduced changes and adds these changes to the local workbench of the developer. This ensures that the developer knows that these changes may affect the integrity of the work he/she is about to submit. UseCompare...Option to compare the local version with the code stored in the resource library (seeFigure 5).

Figure 5. Compare the local version with the version in the resource library

The next step is to resolve any conflicts and try to re-compile the code. If everything works, useTeam-> commit...Option to perform the submit operation, as shown in figureFigure 6. This will integrate all changes into the resource library.

Figure 6. Submit the changes to the remote resource library

4. manage the resource library
CVS allows developers to isolate changes within some independent development paths called branches. When a developer changes a file on a branch, this change does not appear on the trunk or other branches. Those branches are namedSubversion)OrCode fork). Later, the merge operation will migrate the changes from one branch to another branch (or trunk ). These revisions are then submitted. This effectively copies the changes to another branch. Use the context menu of the projectTeam-> branch...Option. eclipse makes migration between development branches easy.

Of course, when the development team maintains a large resource library, it is necessary to control the submission and merge operations within the project. Eclipse/CVS integration provides a special view: cvs repository history (seeFigure 7). It provides a quick preview of changes performed by team members in the resource library.

Figure 7. View revision history with annotations in the CVS resource history window

The eclipse platform provides several utilities that support code management. The most useful is the patch function. It compares code from two sources (such as local workbench and resource library) and creates a Unix-like patch file that contains code differences (seeFigure 8). You can send the file to the developer to upgrade the source code to the latest version.

Figure 8. Create a patch for source code distribution

5. Disconnect the project from CVS
When the project development is completed and the team wantsFreezeYou can delete the final version of the project from the head resource library. Disconnecting a project from CVS disables the resource library operation on the project and its resources, and deletes the CVS information associated with the project (this operation is optional ).

You can useTeam-> disconnectOption. By selecting this option, the confirm disconnect from CVS dialog box is displayed. After disconnecting the project from the resource library, the team must determine how to process the CVS information. The first option is "Delete the CVS meta information". It will disable the CVS team menu operation and delete the CVS folder and its content from the file system. The second option is "Do not delete the CVS meta information"; it will disable the CVS team menu operation, but retain the CVS meta information.

Back to Top

Third-party code management applications

CVS has several important restrictions: it cannot determine the simultaneous changes made to a single file or the entire file set, nor can it detect logical conflicts between files. The concept of conflict is purely in the text sense. When two changes to the same basic file are very close to each other, the merge command is disturbed. CVS does not provide any interactive collaboration tool similar to message passing. Fortunately, CVS is not the only source code management software supported by the eclipse platform. Developers can use plug-ins to expand the functions of the eclipse platform. Currently, 16 plug-ins can be used by teams to develop software (as of March 4, 2003. All plug-ins are created by the eclipse community or commercial software vendors. Most of these plug-ins have added support for third-party and commercial source code management systems. The most valuable plug-ins are those that support popular enterprise code management systems (such as merant PVCs and rational clearcase. For example, the CVS-SSH2 plug-in allows access to CVS through SSH2 sessions, while Microsoft Visual sourcesafe (VSS) the team provider plug-in adds support for ms vss products (which can also be used on non-Windows platforms such as Linux ).

However, my preferred plug-in is koi (see references for links ). Although it is not strictly used for source code control, this innovative tool injects a lot of new vigor into collaborative development. In the current version, you can transfer messages, share tags, conflicting change notifications, sharing calendars, and event notifications from the Workbench to the workbench. Koi uses a XML-RPC as a communication model in its client-server architecture. The client is a single eclipse platform instance that communicates with the "Collaboration Server", and the Collaboration Server is also an Eclipse plug-in. Koi uses JDBC-accessed relational databases as data storage. You can find a link to the complete and classified Eclipse plug-in registry in the references.

 

Go to: http://www.ibm.com/developerworks/cn/linux/opensource/os-ecshare/index.html