6 Versioning Applications with Source Control

In addition to creating a repository for your source-controlled files, making sure that JDeveloper can connect to that repository, and importing files to the repository, it may be necessary to install Subversion client software under the following circumstances:

• You wish to create a local Subversion repository using the JDeveloper Subversion VCS extension.

• You wish to use a Java binding (helper library) other than SVNKit, which is the one supplied with the extension.

• You wish to connect to a Subversion repository through a proxy server

In all of the above cases, you will need to install separate Subversion client software. If you wish to use an alternate Java binding, you will additionally have to install the binding software.

To install Subversion client software:

This procedure assumes that the operating system is Windows. For non-Windows environments, consult the documentation for the operating system package management system to ensure the vendor-supplied Subversion client contains JavaHL.

To check the installation so far, open a command prompt and type svn help. You should see a list of subcommands. If not, check that the system path contains the bin directory of the location where the client software was installed (in this example, c:\subversion\bin).

Once you have completed installing the Subversion client software, you can check the Subversion Client installation.

Important: If you subsequently accept an update of the JDeveloper Subversion extension from the Update Center (Official Oracle Extensions and Updates), the client preference will be reset to SVNKit, even if you had previously chosen an alternate client.

To check the installation:

Before you can work with a Subversion repository through JDeveloper, you must create a connection to it. You can subsequently edit the connection details if they change for any reason.

Typically, you will obtain the details of your Subversion connection (server name, user ID, password, etc.) from your team or version control administrator. You will need to know those details before you create a connection to your Subversion repository.

To create a Subversion connection:

If any of the details (such as IP address, port, user ID, password, etc.) of your Subversion connection change, you can edit the connection in JDeveloper so that you can connect to it with the new details.

To edit a Subversion Connection:

You can export the details of your Subversion repository connections to a file. You can subsequently import the connection details from the file to recreate the Subversion repository connections. This can greatly simplify the process of connecting to a Subversion repository as new team members join, as the repository connection file can be stored on a server accessible to the team, then downloaded as required as new members join. Similarly, if new servers are added, the team leader or administrator can distribute new connection information in a connection detail file to be imported by all team members.

To export Subversion connection details to a file:

If you or your team have saved the details of your Subversion repository connection, you can import them into JDeveloper to simplify making the connection to your repository.

To import Subversion connection details from a file:

If you want to connect to a Subversion repository through a proxy server, you must first install separate Subversion client software.

Once you have installed the Subversion client software, you will have a Subversion subdirectory in your Windows Application Data directory. To find the Application Data directory, at the c:/ prompt type cd %APPDATA%. Then open the Subversion subdirectory. (On Linux, the equivalent subdirectory will be in ~/.subversion, where ~ is the home directory.)

In the Subversion subdirectory will be a file named servers. Open this file with a text editor and find the [global] section. Remove the comment marker (#) from the line http-proxy-host and overtype the placeholder proxy information with the details of the proxy server that you use. Remove the comment marker (#) from the line http-proxy-port and overtype the placeholder port information with the port number for the proxy server. If you wish to exclude certain URLs from using the proxy server, remove the comment marker (#) from the line http-proxy-exceptions and overtype the placeholder URLs with URLs that you wish to exclude.

Add additional http-proxy-host and http-proxy-port lines with details of any other proxy servers that you use.

It is important that the proxy server supports all the http methods used by Subversion. Some proxy servers do not support the following methods by default: PROPFIND, REPORT, MERGE, MKACTIVITY, CHECKOUT. If you experience problems with using a proxy server to access a Subversion repository, ask the server's system administrator to change the configuration to support these http methods.

You can export copies of JDeveloper files that are under Subversion control from either of two places: the Applications window, in which case the files will be exported from the Subversion “working copy", or the Subversion Navigator, in which case the files will be exported from the Subversion repository. Exporting the files means copying them to a local file system directory that you specify.

To export files from the Applications window:

This exports the selected files from the Subversion "working copy" of your local file system.

You can export copies of files under Subversion control from the Subversion Navigator. This ensures that the files will be exported from the Subversion repository (not from the "working copy"). In addition, exporting with the Subversion Navigator lets you specify which revision of the files to export.

To export files from the Subversion Navigator:

This exports the selected files from the repository to your local file system.

Before you can use CVS, you need to configure JDeveloper by setting preferences.

To configure JDeveloper for use with CVS:

Once you have installed the CVS extension in JDeveloper, you must create a connection to CVS before you can access the repository.

To create a CVS connection:

If any of the connection details change after creation, you can edit the CVS connection.

To edit a CVS connection:

You use the CVS Export wizard to export the revisions of files for a module, creating a deployment-ready file structure.

To use the CVS Export wizard:

The files are exported to the location you have specified.

You can copy the path of the CVSROOT from a node in the CVS Navigator to the Clipboard, for use in other applications.

To copy the CVSROOT path to the Clipboard:

The full path of the CVSROOT is copied to the Clipboard, from where you can paste it into another application.

If your installation uses a local CVS client, you need to choose a character set.

For each CVS repository connection, you can choose the character set to be used for the encoding of files. The default is to use the character set specified by the platform/operating system.

You can change to the IDE default or to a specific character set through the Set Encoding dialog.

To choose a character set:

Before you can configure JDeveloper to use Perforce, you must have installed the Perforce server and client software.

To configure JDeveloper for use with Perforce:

Once you have configured JDeveloper for use with Perforce, you can select Perforce as the version system. This will specify a number of default settings which mean that all team operations will default to Perforce as your chosen version system.

To select Perforce as the version system:

• Choose Team > Perforce.

You can change this default selection at any time if your team changes to a different version system at a later date.

Using Team System with JDeveloper requires a setup procedure that includes installing software, connecting to your server, and populating your workspace.

To set up Team System with JDeveloper:

Instructions for doing the above are given in the Team System online help.

Once you have set up Team System for use with Oracle JDeveloper, you are ready to configure JDeveloper to use Team System. In addition to the steps in Setting Up Team System for Use with , make sure you have already installed the JDeveloper Team System VCS extension (from the Official Oracle Extensions and Updates center).

To configure JDeveloper for use with Team System, carry out the following activities in JDeveloper:

• Connect to Team System as the JDeveloper versioning system.

• Set the workspace to use with JDeveloper.

• Create a JDeveloper project to hold the workspace files.

• Refresh the workspace folders in JDeveloper.

Connecting to Team System as the default versioning system specifies that Team System is the target for a number of actions from the Team menu.

To connect Team System as the versioning system:

• Choose Team > Connect to Team System.

This displays the Team System connection menu, from which you can select the available operations. Detailed instructions for this are given in the Team System online help.

Before beginning, you need to set your selected Team System workspace to use JDeveloper.

To set the workspace to use with JDeveloper:

Associating the JDeveloper project with the selected Team System workspace ensures that the files you create and edit will remain part of the workspace your team is using.

To create a JDeveloper project to hold the workspace files:

Once completed, refresh the workspace folders in JDeveloper by choosing Team > Refresh Workspace Folders.

JDeveloper lets you get (from the Team System server) a version of a file that is in the Applications window. You must previously have used the get command in the Team System client software to populate your workspace with source files.

You can use this procedure to obtain the following versions of files: the latest version; files from a previously saved named changelist; files with a particular date stamp; files from a previously created named label; files from a particular workspace version.

The version obtained from the Team System server will replace the version currently in the Applications window.

To get versions of files from the Team System server:

You can bring files under Team System source control. The files will be added to the Team System server and made available to other users when you next check in the file.

To add files to Team System Control:

In most cases, you will connect to your team's Subversion repository. As you develop your projects and applications, you will check files out from the Subversion repository, modify them, and check them back in. This is the typical, and recommended, practice for using Subversion.

Depending on your installation, however, you may find it necessary to create a Subversion repository on your local file system through JDeveloper. A connection to the repository will be created at the same time.

JDeveloper will try to use the file:/// protocol to access the newly created repository. SVNKit, the Subversion client installed with JDeveloper, supports the file:/// protocol. If you are using a Subversion client that does not support the file:/// protocol, you will need to use a different access method (http://, https://, svn:// or svn+ssh://). Consult the Subversion documentation for how to do this.

To create a Subversion Repository:

1. Choose Team > Create Local Repository.

   If your installation does not support local repository creation, you will see an error message. Otherwise, the Create Subversion Repository dialog will open.

2. Complete the Create Subversion Repository dialog.

   To obtain help while using the dialog, press F1 or click Help.

To browse a Subversion Repository:

If you have new files that are not already part of any existing Git repository, you need to initialize a Git repository.

You initialize a Git repository when you have a new project with all new files. This is typically done once per project, at the beginning. As an ongoing task, you are more likely to add new files to an existing Git repository (see Adding New Files to an Existing Git Repository), or check out files, edit them, and then commit the changes back to the Git repository (see Committing a Change to the Git Repository).

To initialize a Git repository:

If your team already has a central Git repository and you wish to make a local copy of it for your work, you can clone the Git repository as described here.

The following protocols can be used to clone Git repositories:

• Git (git://). The simplest way of connecting to the Git server. The connection is not authenticated.

• HTTP (http://). HTTP is another simple way of connecting to the server. http:// connections are insecure even with authentication as the files will be transferred in clear.

• HTTPS (https://). Connects to the server using password authentication. https:// connections are fully secure and will work through a web proxy.

• Secure Shell (ssh://). This uses public key authentication, and you will need to generate an authentication key using a utility such as ssh-keygen. This is the most secure way of cloning an existing Git Repository. However, it will require additional setup if you are trying to connect through a web proxy.

To clone a Git repository:

• Select Team > Git > Clone.

This opens the Clone from Git Wizard. Enter the information requested on each screen. You can press F1 or click Help at any time for more information.

Adding new files to an existing Git repository involves selecting, then adding the files, and finally committing them for the changes to be incorporated into the repository.

To add new files to an existing Git repository:

From within JDeveloper, you can create a new CVS repository on your local file system. This feature is available only if you are using external CVS client software, rather than the internal CVS client installed as part of the CVS extension to JDeveloper.

To create a local CVS repository:

Before you can start using your JDeveloper project with CVS, you have to import the project files into the CVS repository. This copies all your folders and files to the CVS repository and places them under source control.

You import your project files into the CVS repository using the Import to CVS wizard.

To use the Import to CVS wizard:

Before you can change any files, you have to copy them back to your machine, where you can work on them locally.

Perforce uses a local directory structure to receive files that are going to be placed under formal source control. This location is called the “Perforce client workspace". Files created in (or moved into) JDeveloper must be stored in this location. Once files are in your Perforce client workspace, you bring them fully under source control by submitting them to a central location called the “Perforce depot". Files must be submitted to the Perforce depot before they can be versioned and accessed by other users.

Files that you create within JDeveloper, or files that you bring into JDeveloper from outside, must be brought under Perforce control before you can use the JDeveloper Perforce versioning facilities with them.

If you have an existing JDeveloper project that you wish to bring under Perforce control, use the Import to Perforce wizard.

To put individual JDeveloper files under Perforce control:

1. Select the files in the Applications window and choose Team > Perforce > Open for Add.

   The files can be your work files, or they can be the application and project files used by JDeveloper.

   The Add Files to Perforce dialog is displayed with the files listed.

2. If you wish to lock the files, making them unavailable to others for editing, check the Lock Files box.

3. To add the files to Perforce control, click OK.

   The files are now shown in the Applications window with a red cross, meaning that they are stored in your Perforce client workspace but not yet in the Perforce depot. Files must be added to the Perforce depot before they can be versioned and accessed by other users.

4. To add files to the Perforce depot, select the files in the Applications window and choose Team > Perforce > Submit.

   The Submit Files dialog is displayed with the files listed.

5. Add your versioning comments in the Comments box.

   You will later be able to see these comments when viewing the list of versions of a particular file.

6. To submit the files to the Perforce depot, click OK.

   The files are now shown in the Applications window with a green dot, indicating that they are known to the Perforce depot and are up to date.

To bring files created outside JDeveloper under Perforce control:

Some types of connection to a CVS repository require you to log in independently of making the connection. If you cannot access any CVS features even though a CVS connection exists, you need to log in.

To log in to a CVS repository:

Before Perforce operations become available within JDeveloper, you must connect to it.

To connect to Perforce manually:

In some development environments, you may need to make more than one connection to Perforce. For example:

• Your organization uses one Perforce server for development and another Perforce server for test.

• You wish to connect using two different Perforce clients.

• You wish to use different Perforce user IDs.

The Perforce extension to JDeveloper permits all these operations. You begin by giving each Perforce connection a name as you create it.

To create a named Perforce connection:

Note that your Perforce changelist will display the connection that applies to each file in the changelist. For more information on changelists, see How to Use Change Sets and Changelists.

JDeveloper does not provide a direct way of using SSH Level 1 as an access method for the CVS repository. It is however possible to configure SSH Level 1 so that it can be used for remote shell access.

To configure SSH Level 1 to enable remote shell access:

1. Generate public and private keys using the command: ssh-keygen

2. Concatenate the ~/.ssh/identity.pub public key file with ~/.ssh/authorized_keys on the machine with the CVS repository.

Before running JDeveloper and attempting to use CVS with SSH Level 1, users should be explicitly authorized and the environment correctly configured. Follow the steps below to configure the environment correctly.

To configure the environment for SSH Level 1:

JDeveloper provides a direct way of using SSH2 as an access method for the CVS repository.

To use SSH2 for remote shell access:

If you are using an internal CVS client, you can generate SSH2 key files at any time by choosing Team > CVS > Administration > Generate SSH2 Key Pair. If you are using an external CVS client, this menu option is unavailable.

Editing and watching are available only when an external CVS client executable is used.

These procedures allow you to obtain and release an editor on a file, to know who else in your team is editing files, and to know who is watching for files to be edited. Two or more developers retain the ability to edit the same file at the same time.

To set up JDeveloper to use editing and watching:

1. Open the preferences page obtainable from Tools > Preferences | Versioning | CVS.

2. Ensure that External Executable is selected and that valid details are entered.

3. Select Run CVS in Edit/Watch Mode.

4. Open the preferences page obtainable from Tools > Preferences | Versioning | CVS | General.

5. Deselect Automatically Make Files Editable.

To obtain an editor on a file:

1. With the file selected in the Applications window, select Team > Edit.

2. Check that you want the operation to apply to all of the files highlighted in the file selection box.

3. To set up a watch for this file, select the Set Watch Actions checkbox and select a watch action from the drop-down list.

4. Click OK.

To release an editor on a file (to unedit a file):

This action reverses changes made in the current edit. Any local file modifications will be lost when the editor is released.

1. With the file selected in the Applications window, select Team > Unedit.

2. Check that you want the operation to apply to all of the files highlighted in the file selection box.

3. Click OK.

To turn on or turn off the file watching facility:

1. In the Applications window, select a project containing files about which you want to be notified.

2. Select Team > Watch.

3. In the Watch CVS Files dialog, choose Turn On Watching or Turn Off Watching from the Command Type drop-down list.

4. Click OK.

To add yourself to the list of people who receive notification of work done on files:

To remove yourself from the list of people that receive notification of work done on files:

• Follow the procedure for adding yourself to the list (above), but choose Remove File Watch from the Command Type dropdown list.

To see who is watching for changes being made to files:

• Select Team > Edit Notifications.

The Edit Notifications window is opened. The Watchers tab shows the files that are being watched and the user(s) who are currently watching for changes.

To see who is currently editing files:

• Select Team > Edit Notifications.

The Edit Notifications window is opened. The Editors tab shows the files that currently have editors on them and the user(s) who have obtained those editors.

Files that you created within (or brought into) JDeveloper before using Subversion control must be imported into the Subversion repository, and then checked out from it.

To import an existing JDeveloper project or application into Subversion:

You can also import an entire project into Subversion using the JDeveloper Version Application feature.

To import files using Version Project:

After you import files into Subversion using the Version Application feature, you will notice that Subversion creates two directories, one as your work area and one as a backup directory.

For example: after creating a new application called Catalog, select Versioning > Version Application > Subversion. Be sure to select the Perform Checkout from the Options page, then finish the wizard.

When the wizard completes, browse to the local directory that you have specified as the Source Directory for this application in Subversion. You will see two directories listed there: Catalog.svn-import-backup and Catalog.svn-import-workarea.

JDeveloper (and Subversion) will use the Catalog.svn-import-workarea directory for file access, checkout/checkin, and other activities. You should avoid editing, moving, or manipulating files in those directories outside of JDeveloper and Subversion.

When you create a new file in JDeveloper that is part of a local working copy (that is, an application that has been versioned and checked out of your SVN repository), you need to add and then commit the file to Subversion control before you can use the JDeveloper Subversion facilities with it. The preferred method is to set up JDeveloper to do this automatically, through the Preferences menu.

To add new files on commit:

You can also place individual files under Subversion control.

To place individual files under Subversion control:

While you use your local Git repository for changes made while editing, it is frequently necessary in a distributed team to work with remote repositories. Push, pull and clone are three concepts that apply to remote Git repositories.

Fetching and pulling are two different methods of obtaining content from a remote repository. When you fetch from a remote repository, Git loads all changes into your local repository but it does not change any of your existing branches. This way, you can inspect the changes and merge them as appropriate.

To copy from a remote repository without changing existing branches:

Pulling, on the other hand, copies files from the remote repository and updates the HEAD branch of your local repository.

To copy changes from your local repository to the remote repository, use the Push command.

Perforce uses a local directory structure to receive files that are going to be placed under formal source control. This location is called the “Perforce client workspace". Files created in (or moved into) JDeveloper must be stored in this location. Once files are in your Perforce client workspace, you bring them fully under source control by submitting them to a central location called the “Perforce depot". Files must be submitted to the Perforce depot before they can be versioned and accessed by other users.

Before you can start using existing JDeveloper project and source files with Perforce, you have to import them into your Perforce client workspace. Once they are in your Perforce client workspace, you bring them fully under source control by submitting them to the Perforce depot.

You import JDeveloper project and source files into your Perforce client workspace using the Import to Perforce wizard.

To use the Import to Perforce wizard:

The CVS update operation updates your local files with data in the CVS repository. Alternately, you can choose to completely replace your local files with those held in the CVS repository.

You can update individual files (including project files), or you can update the entire contents of a project folder.

You can view the contents of the CVS repository through the CVS Navigator. The nodes under CVS Server unfold to reveal the structure and file content of the CVS repository. You can open a read-only version of a CVS repository file by choosing Open from its context menu. This will let you see what changes have been made to the files in the CVS repository since you checked out or last committed your local versions.

To update an individual file (including a project file):

1. Select the file(s) in the Applications window, and then choose Team > Update.

2. Set the options as required. For information about these options, press F1 or click Help.

3. To update all the files listed, click OK.

To update the contents of a project folder:

1. Select the project folder(s) in the Applications window and then, from the context menu, choose Update Project Folders.

2. Set the options as required. For information about these options, press F1 or click Help.

3. To update all the files listed, click OK.

To update files shown in the Pending Changes window:

You must run a WebDAV server to use JDeveloper as a WebDAV client. The WebDAV server must be one of the following:

• Apache 1.3.19 (or above)

  Note:

  If the Apache server is version 1.x, the mod_dav module must also be installed.

• A server that conforms to the WebDAV 1.0 standard

If you'd like to find out more about WebDAV, see the following Web sites:

• http://www.webdav.org

• http://httpd.apache.org/docs-2.1/mod/mod_dav.html

WebDAV connections created in JDeveloper allow you to view files and folders as part of a JDeveloper project.

To create a WebDAV connection in JDeveloper:

If you access the internet via a proxy server you need to configure JDeveloper before accessing WebDAV-enabled servers on the internet.

To access a WebDAV-enabled server via a proxy server:

WebDAV connections are shown in the Application Resources section of the Applications window, listed under the Connections node.

Existing WebDAV connections can be modified.

To modify a WebDAV connection:

WebDAV connections are shown in the Application Resources section of the Applications window, listed under the Connections node.

To ensure that the folders and files accurately reflect the current contents of the WebDAV server, you can manually refresh the display of a WebDAV connection.

To refresh the entire contents of a WebDAV connection:

WebDAV connections are shown in the Application Resources section of the Applications window, listed under the Connections node.

Deleting a WebDAV connection from JDeveloper does not affect any of the files or folders on the WebDAV server itself.

To delete a WebDAV connection:

You can subsequently recreate the connection, in which case the files and folders that were part of it will be shown beneath it again.

To begin making edits and revisions to files in your project, you check out the files you will be working with. It is recommended that you check out the entire application from the Subversion repository, so that you will have access to all files in that application in your local work area. Subversion uses the term modules to refer to the application it is recommended you check out.

When you check out Subversion files, they are copied from the Subversion repository to a new location (specified by you) on your local machine. This location and the files within it constitute the Subversion "working copy."

To check out modules from the Subversion repository:

Checking out a file from your Git repository makes that file available for changes and edits. You can also specify the revision you wish to check out.

To check out a file:

Git checks out the files you have selected. They are now available for editing.

This is a configuration task you perform when you first start to use JDeveloper with files and folders that are under CVS source control. You perform this task once, after (if necessary) importing your JDeveloper project into the CVS repository.

To check out modules from the CVS repository:

Unlike some version control systems, Perforce does not require you to explicitly check out a file. To begin editing a file in Perforce, select Team > Perforce > Open for Edit. This opens the Open Files for Edit dialog, which gives you the option of placing the file on a changelist, locking the file so that other team members cannot edit it simultaneously, and more. topicid:f1_pfcopenfilesforedit_html

You can start editing a file under Perforce control just by opening it from the Applications window. While the Perforce server is being contacted, you may experience a delay before you can type into the opened file. If you would prefer files to remain closed until you manually open them for editing, set the Automatically Open Files for Edit preference to off.

Once your Subversion repository is set up, you typically update your local working copy with files from the repository. This ensures that the files you work on contain all committed changes that others on your team may have made to the same files.

It is recommended that you perform the update operation on a working copy.

When you use Update Working Copy, all the files in your checked-out working copy will be updated, regardless of which node you have active in your application in the JDeveloper Applications window. The alternative is to select Update. This will only update the folder or file (and any child folders and files) that you have selected in the Applications window.

To update a working copy (recommended):

You can also update individual files. However, this runs the risk of not updating all files that may have been modified by your team members since the last time you checked them out.

To update individual files:

If you wish to remove a file from Subversion control, use the JDeveloper Delete feature. This performs a “safe delete," which searches for usages of the file you are deleting and provides you with a dialog with options for proceeding.

To remove a file from Subversion control:

The source control status of an object is indicated in the Applications window by an icon overlay, as listed in Table 6-1.

If the status of an object is changed outside JDeveloper, for example by checking in an object using external source control software, the new status might not immediately be shown in JDeveloper. To ensure that the status indicated in the Applications window matches the true status of the object in the source control system, you can perform a manual refresh.

To refresh the status of objects in JDeveloper:

• In the Applications window or CVS Navigator, click Refresh.

You can add a file to CVS only if it is part of a project that is already under CVS version control.

When you create a new file, for example a new class, it has to be added to source control before you can use the other CVS operations on it. The file is added to source control locally, and the CVS repository is not updated. The file is identified in the Applications window by the icon +.

After completing setup, your work will revolve around the following:

• Updating your files from the repository

• Checking out the files you need to work on

• Editing them in JDeveloper

• Committing the modified files back to the repository

You may also need to resolve conflicts between changes you made and those made by others in your team. Files may also be moved in and out of CVS control as the project changes. Finally, you might use special properties of the files associated with specific versions for tracking bugs, customer requests, and other characteristics.

To add a file to CVS through the Applications window:

1. Select the file in the Applications window and choose Team > Add (or, if the file is binary, Team > Add as Binary). JDeveloper usually recognizes binary files and adds (Binary) after the file name in the Applications window. The Add to CVS dialog (or Add to CVS as Binary dialog) is displayed, with the file listed.

2. Click OK.

   The file will be added to the CVS repository when the next commit is performed.

To add files shown in the Pending Changes window:

1. With the Pending Changes window in Candidate Files mode, select the files that you want to add to source control.

   To obtain more information about the Pending Changes window, press F1 or click Help.

2. Click the Add button.

To remove a file from CVS:

When you remove a file from CVS it is removed from your local disk.

The file or files will be removed from the CVS repository when the next commit is performed.

To add a single file to your Git repository, use the Add command from the Git menu.

To add a file:

The file is added to your selected Git repository.

To add multiple files to your Git repository, use the Add All command from the Git menu. This command adds all files in a directory.

To add multiple file:

All files in the selected directory are added to your Git repository.

When you have made changes to a file, you can commit them to the Git repository.

To commit a change:

JDeveloper commits your changed file to the Git repository.

When you have made changes to multiple files, you can commit them all to the Git repository in one operation.

To commit a number of changed files:

JDeveloper commits your changed files to the Git repository.

Another person may edit a file through their Perforce client and submit their changes to the Perforce depot. This will cause your copy of the file to become out of date compared with the controlled version.

To test that your view is showing the latest file statuses:

• Choose View > Refresh.

  A file that is out of date with the controlled version is shown with an exclamation point icon.

To bring your files up to date compared with the controlled version:

The Perforce Navigator lets you browse the Perforce depot and update your working directory from content at the depot. Using the Applications window, you can select folders or files to sync to your client workspace, downloading content from the Perforce Server to your computer. If new files are detected in the depot, you have several options for handling them.

If you open a connection node and no connection has been made, Perforce displays the connection dialog.

To synchronize your files using the Perforce Navigator:

If you have a very large number of files in your Perforce depot, it can be much easier to navigate to the files you're working on by filtering files in the Perforce workspace. You can do this by setting things up in the Perforce client, and then displaying the filtered view in JDeveloper.

Filtering files in Perforce (specifically, p4v) requires making sure that you are viewing the Depot Tree, then select the Filter icon > Tree Restricted to Workspace View.

To filter files in JDeveloper:

• Version Navigator > Perforce > Connection name > Context menu - Filter by Client Workspace.

You will only see a difference in the JDeveloper Version Navigator if the Perforce client has a rule that restricts the Perforce workspace. (In p4v, the rules are shown and set in the View field of the Workspace dialog for the selected workspace.) You could restrict the workspace view in your p4v client with a rule like the following:

//depot/JDeveloper_1013/... //<client name>//JDeveloper_1013

In JDeveloper, if you select Filter by Client Workspace, the Applications window would be filtered so only //depot/JDeveloper is shown.

The source control status of a file is indicated in the JDeveloper navigators by icon overlays, as listed in.

If the status of a file is changed outside JDeveloper, for example by using a Perforce client application, the new status might not immediately be shown in JDeveloper. To ensure that the status indicated in the Applications window matches the true status of the file in the source control system, you can perform a manual refresh.

To refresh the status of files in JDeveloper:

• Select View > Refresh.

If you wish to delete a file that it is under Perforce control, you should do so using the Perforce facilities within JDeveloper or the Perforce client application.

If you need to retrieve a file that has been deleted, you will need to use the Perforce client. To do this, select Team > Perforce > Launch Perforce Client.

To delete a file under Perforce control:

You can choose to prevent other users working on a file while you are working on it yourself. This is not normally considered necessary, because CVS can usually reconcile differing versions of files as they are being committed to the CVS repository. The JDeveloper compare and merge facilities will reconcile differing versions of files automatically, or present you with a tool for doing so manually if there are serious conflicts.

You may want to ensure that a file is worked on only by you, until you have finished working on it. This might be because a file is in binary format and therefore inherently difficult to merge. In this case, you can lock the file that you want to work on. The file is locked in the CVS repository, and other users are prevented from accessing it. When you want to let others work on the file, you unlock it.

To lock files in CVS:

1. With the file or files that you want to lock selected in the Applications window, choose Team > CVS> Administration > Lock.

2. Check that you want the operation to apply to all of the files highlighted in the file selection box.

3. Click OK.

To unlock files in CVS:

By default, you can start editing a file under Perforce control just by opening it from the Applications window, without explicitly locking the file. While the Perforce server is being contacted, you may experience a delay before you can type into the opened file. If you would prefer files to remain closed until you manually open them for editing, set the Automatically Open Files for Edit preference to off. The following procedure works whichever way the preference is set.

To edit a file under Perforce control:

The changes that you made to the file are now saved in your Perforce client workspace. To add your changes to the controlled version of the file and make them available to other users, you must now submit them.

Use to check out files so that you can work on them. The files must already by under Team System source control.

To check out files:

You can check the status of a file that is under Team System source control. See also Refreshing the Status of Files in Team System.

To view the status of a file:

The status labels shown are those used by Team System to describe the source control status of the file.

The main statuses are:

• Edited - In JDeveloper, the file is checked out and may have been modified.

• Unchanged - In JDeveloper, the file is currently checked in.

• Scheduled for addition - In JDeveloper, the file has been added (that is, brought under source control) but not yet checked in.

The source control status of a file is indicated in the JDeveloper navigators by icon overlays, as below.

To refresh the status of files in JDeveloper:

• Select View > Refresh.

Once you have made edits and revisions to your working files, you return them to the Subversion repository.

Use these procedures to bring the Subversion repository up to date with the latest version of the files you have been working on, at the same time adding any new files to or removing any unwanted files from the Subversion repository.

You can perform the commit operation on individual files, or in the context of a working copy.

If an individual object that you want to commit has uncommitted parent objects, you must first commit the parent objects. An alternative is to commit the working copy that the objects are part of, in which case all the uncommitted objects will be committed.

You can also use change sets to manage groups of files, which can help ensure that you commit all files pertaining to a particular sub-project or task within the overall application.

To commit individual files shown in the Applications window or the Pending Changes window:

• Select the file(s) and choose Team > Commit.

  The Commit Resources dialog is displayed with any files listed. Set the options on the Commit Resources dialog as required.

  To obtain more information about the options, press F1 or click Help. To commit the listed file or files to the Subversion repository, click OK.

To commit a working copy from the Applications window:

1. Select a navigator node or file that is part of the working copy.

2. Select Team > Commit Working Copy.

To obtain more information about the options, press F1 or click Help. To update the Subversion repository with the content of the working copy, click OK.

When you use Commit Working Copy, all the files in your checked out working copy will be committed, regardless of which node you have active in your application in the JDeveloper Applications window. The alternative is to select Commit. This will only commit the folder or file (and any child folders and files) that you have selected in the Applications window.

Additionally, you can commit a working copy from the Pending Changes window.

To commit a working copy from the Pending Changes window:

There are two options for committing your changes to the Git repository: selecting an individual file to commit, or committing all files at once.

To commit an individual file:

1. Select the file you wish to commit.

2. Select Team > Git > Commit. This opens the Save Files dialog. Click OK to continue. This opens the Commit dialog.

3. If your team uses comment templates (for example, to make it simpler to track issues automatically in a bug-tracking system), select the template or add a comment. Otherwise, click OK to commit the file to the repository.

To commit all files in a project:

Use these procedures to update the CVS repository with the latest version of the files you have been working on, and to add any new files to or remove any unwanted files from the CVS repository.

You can perform this on a single file, or in the context of a project. When in the context of a project, JDeveloper determines which files have changed since they were last committed and displays them as a list.

If you select a project to be committed that includes files that are not yet part of CVS version control, the Add Files to CVS message dialog will open. To obtain information about using this dialog, press F1.

You can view the current contents of the CVS repository through the CVS Navigator. The nodes under CVS unfold to reveal the structure and file content of the CVS repository. You can open a read-only version of a CVS repository file by choosing Open from its context menu. This will let you see what changes have been made to the files in the CVS repository since you checked out or updated your local versions.

To commit individual files shown in the Applications window:

1. Select the file(s) in the Applications window, and then choose Team > Commit.

   The Commit to CVS dialog is displayed with the file(s) listed.

2. Set the options on the Commit to CVS dialog as required.

   To obtain more information about the options, press F1 or click Help.

3. To update the listed file(s) in the CVS repository, click OK.

To commit the contents of project folders shown in the Applications window:

1. Select the project folder(s) in the Applications window and, from the context menu, choose Versioning > Commit Project Folders.

   If there are files in the project that are not under CVS control, you will be asked whether you want to add them.

   The Commit to CVS dialog is displayed with the folder(s) listed.

2. Set the options on the Commit to CVS dialog as required.

   To obtain more information about the options, press F1 or click Help.

3. To update the listed file(s) in the CVS repository, click OK.

To commit files shown in the Pending Changes window:

Any changes that you make to a file are initially saved in your Perforce client workspace. To add these changes to the controlled version of the file and make them available to other users, you must submit them. In the following procedure, if the Submit menu option is unavailable, it is because there are unresolved conflicts between your copy of the file and the one in the Perforce depot. Before proceeding, you will have to resolve the conflicts or revert the file to a non-conflicting version.

To submit changes to the Perforce depot:

Use to check in a file to the Team System server. A checked in version of a file can be seen and worked on by other users.

To check in files:

Change sets, or change lists, are essentially labels which can be applied to working copy files to enable group operation on each change list. The idea behind adding files to a change set is similar to sorting files into directories, but change lists can be created dynamically and the labels applied to each file, regardless of their level in the file system hierarchy. You can then address all the files in the change set as a single group. For example, if you make a single bug fix that requires editing three different files, you can add all three files to the change set and track them as a single logical unit in the JDeveloper Pending Changes window.

Subversion lets you associate files with a named change set, either manually or automatically. You make additions to the change set through the menu system; automatic additions are also possible through default association, when JDeveloper detects outgoing changes.

You can browse changes for a named change set in a view of the Pending Changes window. From there, you can manipulate the change sets, and commit associated changes to the repository.

To add a selected file to a new change set:

• Select a file from the Pending Changes window, then select Team > Add To > New Change Set.

To add file to a change set:

In Perforce, changelists let you group files together to simplify operations. Once files are grouped in a changelist, you can check them out and submit them all in a single operation.

In Perforce, changes are submitted to a Perforce repository using a changelist. This lets you group changes to several files into a logical unit, and then submit this unit to the Perforce repository in one operation.

You can have more than one changelist. You may find it useful to create changelists for specific projects, for related groups of files, or for any other grouping of files that you find create a logical unit, based on the way you and your team work. You can also move files from one changelist to another.

In general, you use changelists by following this workflow: create a changelist, add files to your changelist, edit your files and submit your changelist with the edited files.

You can also browse existing changelists through the Changelist Browser. The Changelist Browser also lets you create, submit, and move files between changelists. If the submit operation fails on any file in the changelist, then the whole changelist fails. This means the Perforce repository is left in a consistent state.

A Perforce changelist lets you manipulate a number of changed files and folders in a single operation, simplifying the process when you have several files that you have been working on.

To create a Perforce changelist:

Annotating a Perforce revision or changelist lets you store the Perforce revision or changelist as a comment linked to every file in the revision. When you modify these files later in Perforce, you can view the sequence of revisions or changelists to these files, as annotations to the files.

To add annotations to a changelist:

Any previous annotations will be visible in the Comments field of the changelist.

A Perforce changelist lets you manipulate a number of changed files and folders in a single operation, simplifying the process when you have several files that you have been working on. When you add files to Perforce, you can select the changelist to which these files will be added at the same time, through the Open for Add menu.

To add files to a changelist:

Once you have made a series of edits to your files, you are ready to submit them in Perforce. If you have created a changelist, you can submit all the files on that changelist in a single operation, or select just the ones you have edited and submit them.

To select and submit the files in a changelist:

The Changelist Browser lets you see, at a glance, the state of all the pending changelists in your Perforce repository. Each pending changelist is shown with its name, description, and contents. The default changelist is always shown at the top of the browser. Under each changelist, you can browse the files that are associated with that changelist. Additionally, the Perforce connection and client are displayed at the top of the browser.

From the Pending Changelist browser, you can create and submit changelists, move files between changelists, and refresh the browser.

To create a changelist with the Changelist Browser:

1. From the Versioning menu, select Perforce > Create Changelist.

2. From the Connection drop-down list, select the preferred Perforce connection (if you have more than one) for this changelist.

3. Select the files to be added to the changelist, or click Select All to add all displayed files to this changelist.

4. Add comments to this changelist, if desired. You can choose a previous comment (with the option of editing it if necessary), or you can select your comment template.

5. When you have set up the changelist as desired, click OK.

To submit a changelist:

1. From the Versioning menu, select Perforce > Submit Changelist.

2. Enter a description of the changes you have made in the Description field.

3. Check the files you wish to submit. Use the Select All and Deselect All buttons if required.

To move files between changelists:

You can also refresh the changelist browser by pressing F1.

Many team environments allow the developer to enter comments when a file is checked in. These comments might include bug report numbers, dependencies on other files, or some other explanatory information to be stored in connection with the file being committed to the repository.

In particular, some teams wish to correlate checked-in files with the bugs that the files address. One way to do this is to set up a standard template for issue tracking, for example, bugtraq <bug number> where you replace <bug number> with the actual ID of the issue this file addresses, and use that as the comment to a file checkin. This way, file checkin comments can be used to correlate the edits with the issues being tracked.

JDeveloper lets you create and select templates for use with such comments. The templates are available from the Commit or Checkin menu, depending on how your version control system refers to the process of committing changes to the repository.

To create a new template:

The template you created will now be available to select when you commit or check in your files.

JDeveloper lets you import and export templates as text files, allowing you to share a set of templates with your team. This simplifies using the exact format that any tracking system you use will expect to see in the commit comments, and also avoids errors in formatting the template.

To import a template:

1. From the Comment Templates page, click Import. This opens a file browser.

2. Navigate to the directory containing the template file you wish to import and click on the file to select it.

3. Click Open.

The template file will be imported to JDeveloper.

You can also export your templates as a file to be imported later, either by you or (if you make the file available on a shared resource) by your team members.

To export a template:

The template file is now available for import to JDeveloper.

Note that if your team uses more than one version control system, you can use Export and Import to share the same templates across systems.

Many team environments require the developer to enter comments when a file is checked in. These comments might include bug report numbers, dependencies on other files, or some other explanatory information to be stored in connection with the file being committed to the repository.

JDeveloper lets you create and select templates for use with such comments. The templates are available from the Commit menu.

To select a template:

Your file will be committed with the template you selected, plus any edits you made.

Shelving lets you save file changes in the Team System server without having to check the files in. As part of the shelving process, you can choose either to continue to work on the changed files or to remove them from view and revert to unchanged versions.

When you later want to make use of the file changes that were shelved, you can unshelve them.

If you decide you no longer want to keep changes that were shelved, you can delete the shelveset that you put them in.

To shelve a set of file changes that have not been checked in:

To shelve a set of file changes that have not been checked in:

1. In the Applications window, select the versioned project containing the files.

2. Select Team > Shelve.

   The Shelve dialog opens.

3. Complete the dialog.

For information while completing the dialog, click F1.

The file changes will be shelved when you click OK.

The file icons in the Applications window will change to reflect the new file statuses, if any.

To unshelve a set of file changes:

1. In the Applications window, select the versioned project into which you want to unshelve the file changes.

2. Select Team > Unshelve.

   The Unshelve dialog opens.

3. Select the shelveset name for the shelveset containing the file changes.

The file changes will be unshelved when you click OK.

Files deleted since the shelveset was created will be reinstated and the file icons in the Applications window will change to reflect the new file statuses.

To delete a shelveset:

The shelveset will be deleted when you click OK.

Use to delete files from your workspace and from the Team System server.

To delete a file:

The file is deleted from your workspace and from the Team System server.

When you wish to put the work you have being doing on a branch back into the main line of development, you can start the process by using the merge revision facility. This will compare the content of two revisions and apply the differences to the current working copy. You can also use this facility whenever you wish to copy changes made in one revision to another revision.

You may want to change your working copy so that it is based on a different branch. You can do this using the switch feature, either as part of branch creation or independently.

To create a branch or tag:

1. Ensure that you have committed your files to Subversion before continuing.

2. In the Applications window, select a project or file that is in the line of development that you wish to branch or tag.

3. Select Team >Branch/Tag.

4. Complete the Branch/Tag dialog.

   For help when completing the dialog, press F1 or click Help.

To use the merge facility (that is, to compare two revisions and apply the results to the working copy):

1. In the Applications window, select a project or file that is in the start revision (that is, the resource that is to be compared against).

2. Select Team > Merge.

3. Complete the Merge dialog.

   For help when completing the dialog, press F1 or click Help.

To switch the working copy to be based on another location in the repository:

You can create a new, named branch of your Git repository, and optionally apply a tag when you create it, from the Create Branch dialog.This creates the named branch for use with Git, and associates the selected tag with it if you choose.

To create a new branch in Git:

You create a new branch when you are beginning a project based on an earlier version of your code repository, such as for fixing bugs after a major release, or working on specific features for a subset of your customers.

To create a new branch:

1. In the CVS repository, select the file or folder on which you wish to base your new branch, then click the right mouse button.

2. Choose Branch > Branch in CVS.

3. Type in the branch name. JDeveloper converts the branch name to the default tag for the branch, by appending _BASE to the branch name as you type it.

4. Choose whether the branch source is the trunk or the working copy. If you select the trunk, the HEAD revision of every file is branched.

5. Click Save.

The base tag is applied before the branch is created, allowing you to specify these versions as a merge point in future.

You can also specify that you wish to create your new branch from an existing branch, by choosing the branch to use as the base.

To create a new branch from an existing branch:

Checking out a branch in Git gives you access to the files on that branch.

To check out a branch in Git:

JDeveloper displays the branch that you have checked out, with any projects and files associated with the selected branch. You can access these files from the Application window.

You have the option of creating a new tag when you check out a branch in Git. However, you can also create a tag at any time by using the Create Tag dialog.

To create a tag in Git:

CVS allows you to create and assign tags to content.

To assign CVS tags:

This procedure will assign symbolic tags to the local CVS revisions of selected files.

1. In the Applications window, select a single file, a project or a workspace. If you select a project or a workspace, all the files within the project or workspace will be selected for tagging.

2. Choose Team > Tag > Tag.

3. Check that you want the operation to apply to all of the files highlighted in the file selection box.

4. Enter a name for the tag in the Tag Name box.

5. Set the other options as required. To obtain descriptions of the options, press F1.

6. Click OK.

To view CVS tags:

This procedure will display a dialog containing information about any existing tags that have been applied to the file revision.

1. From the context menu of the file, choose Team > Properties.

2. Select the Versioning tab. The sticky tag, date and options (if any) are shown, as is a list of existing tags for the file revision.

To reset CVS tags:

This procedure will remove any sticky tags or dates that have been applied to the selected files and reset them to the HEAD revision.

Deleting a tag does not delete the content associated with it, but if you are using tags to identify a specific project that has completed, you can delete the tag to simplify the display when you are choosing tagged content in future.

To delete CVS tags:

This procedure will delete symbolic tags from the local CVS revisions of selected files.

You can select from an existing tag in Git and apply it to the file you have selected for the current transaction.

To select a tag in Git:

• Select Team > Tag. Scroll through the list to find the tag you wish to apply to the selected file.

If there are more than one tags that apply to the file, hold down the Ctrl key, then select each tag that you wish to use.

As an example of using subversion properties, you can associate a specific subversion property with a newly added feature. Viewing all files or folders with this subversion property lets you see all the files associated with this feature: an HTML file, a JavaScript file, a class definition file, or any other elements that are involved in adding this new feature to your application.

When you add or edit subversion properties, the dialog lets you select or specify the following elements:

Resource file

The file (or folder or other resource) to which this property is to be applied. To change this value, select a different file or resource. Note that if you wish to add this property at the application or project folder level, edit the resource file entry so that it refers to the folder, not the file.

Property name

Select a property name from the available list, or enter a new name to create a new Subversion property. Preface the new property name with svn: to be tracked as a Subversion property.

Value string

Enter the string to be displayed with this Subversion property when you view properties. For example, you can associate a specific Subversion property with a particular bug identification number or a specific upcoming release.

Note that the Value String might differ depending on the property. For instance, consider a property named svn:externals meant to record the connection between a local file and its external URL in the SVN repository. This property's value string would be a pair of text strings, respectively showing the local directory where the external file is to be checked out and the URL to the external file in the SVN repository

Assume for this example that the resource file is D:\temp and the property name is svn:externals. The value string (a value pair) might be:

external_libs https://ukp16449.uk.oracle.com/repos/trunk/FOD/StoreFront.jar

This indicates that the file StoreFront.jar held in the Subversion repository at that URL is to be checked out to D:\temp\external_libs. If the Value String entries were held in a specific file pointed to from this property, use the Value File entry.

Value file

If you know you will be adding the same Subversion property to a number of resources in your application, you can save the value string in a text file. Click Browse to select the text file that contains the value string you wish to use.

Set property recursively

Select this if you wish Subversion to apply this property to all files and elements below the current level in the application or project hierarchy.

If your team has been using Subversion properties for some time, you can use the View Subversion Properties menu to see a list of all elements that use a selected Subversion property. You can also compare the Subversion properties between different versions.

To view a list of Subversion properties:

1. Select an element under Subversion control from the Applications window.

2. Select Team > Subversion > View Subversion Properties.

If your project needs a new property for tracking and managing a particular aspect (such as a new feature or a bug fix), you can also add new properties.

To add a new Subversion property

When you set an external property with a revision number, make sure you follow the correct format for the value string. You can use either of the following as the value string for a property of type svn:external to set the ExternalWebINF revision to 16, using the JDeveloper integrated Subversion:

ExternalWebINF -r 16 https://myserver.myteam.com/svn/repos/public-html/WEB-INFhttps://myserver.myteam.com/svn/repos/public-html/WEB-INF@16 ExternalWebInf

Use this procedure to check the content status and any associated property status of a file that is under Subversion source control. You can also refresh the status of a file.

To view the status of a file:

The status labels shown are those used by Subversion to describe the source control status of content and any associated property.

The main statuses for content are:

• added - The content has been added to source control but has not yet been committed to the Subversion repository.

• modified - The property has been locally modified since it was copied from the repository.

• unmodified (normal) - The property is unmodified since it was last updated from the Subversion repository.

• conflicted - There were conflicts when the property was updated from the Subversion repository.

• deleted - The file (content and any associated property) will be removed from the Subversion repository with the next commit action.

The main statuses for associated properties are:

• modified - The property has been locally modified since it was copied from the repository.

• unmodified (normal) - The property is unmodified since it was last updated from the Subversion repository.

• conflicted - There were conflicts when the property was updated from the Subversion repository.

Subversion allows you to create and save properties associated with folders or files. These properties have a name and a value string.

You can resolve any such conflicts using Subversion's Resolve Tree Conflicts feature.

To resolve Subversion property conflicts:

This displays the versions with the conflicting properties in two adjacent panes, as with the Version Compare.

To resolve the conflict, you can make changes in the Subversion Properties window.

The source control status of a file is indicated in the JDeveloper navigators (Applications window and Teams window) by icon overlays, as below.

If the status of a file is changed outside JDeveloper, for example by using a Subversion client application, the new status might not immediately be shown in JDeveloper. To ensure that the status indicated in the Applications window matches the true status of the file in the source control system, you can perform a manual refresh.

To refresh the status of files in JDeveloper:

• Select View > Refresh.

Use the Revert command to:

• Undo changes that you have made locally to the contents of a file.

• Change the status of a file that has been added, but not yet committed, back to unadded.

• Stop a file that is scheduled for removal (in the Pending Changes window) from being removed from the Subversion repository.

To revert a file:

You can revert changes made to a file that you have committed to a Git repository to return it to a previous state.

To revert changes:

CVS lets you select specific revisions from the CVS repository, if you find it necessary to begin or resume working with a previous version of the file you are currently working on.

To open a CVS file revision:

This procedure will obtain a revision of a file from the CVS repository so that you can view it or save it locally.

Use these procedures to compare files that are under Subversion control with other revisions of the same files, or with other files.

To compare revisions of a file:

1. From the context menu for the file, choose Compare With.

2. Select either Previous Revision, Latest Revision, or Other Revision.

   If there are no differences, a message is displayed. Otherwise the revision or revisions are shown in the Compare panel of the History tool.

To compare a file with another file:

1. From the context menu for the file, choose Compare With > Other File.

   The Select File to Compare With dialog is opened.

2. Select the file to be compared.

   The files are shown in the Compare panel of the History tool.

To compare two files:

You can hide (and later expose) the Compare panel of the History tool to view other panels in JDeveloper.

If there is a conflict between your copy of the file and the one in the Subversion repository, the icon next to the affected file will include an exclamation point. You will not be able to submit such a file to the Subversion repository. To overcome this problem, you should do one of the following:

• Revert to a non-conflicting version of the file.

• Resolve the conflict using the JDeveloper merge tool.

• Indicate to the Subversion control system that the conflict has been resolved (Team > Mark Resolved), even if no changes have been made (usually necessary only for binary files).

Another reason you might need to do this is if you have resolved the conflict yourself in the file, rather than using the merge tool. This might be the case if you have chosen to merge files at the server rather than the more usual solution of merging files locally.

To revert to a non-conflicting file version:

• Select the file in the Applications window and choose Team > Revert.

To resolve the conflicts using the merge tool:

To indicate that the conflict has been resolved, even if no changes have been made:

• Select the file (usually a file with binary content) in the Applications window and choose Team > Mark Resolved.

Use this procedure to merge two revisions of a file, where the revisions contain conflicting content. Conflicts are notified in the Pending Changes window: the outgoing status is "conflicts" or "conflicts on merge", and the Resolve Conflicts button is active.

To merge two revisions with conflicting content:

Use this procedure to merge two revisions of a file, where the revisions contain conflicting content. Conflicts are notified in the Pending Changes window: the outgoing status is "conflicts" or "conflicts on merge", and the Resolve Conflicts button is active.

To merge two revisions with conflicting content:

Use these procedures to compare revisions of files that are under CVS source control. You can compare a file with its immediate predecessor, or you can compare with any of the file's previous revisions.

To compare a file shown in the Applications window:

To compare a file shown in the Pending Changes window:

You can compare a file in the Pending Changes window either with a previous revision or with the HEAD revision, depending on which mode the window is in. To obtain more information when using the Pending Changes window, press F1.

• With the window in Outgoing Changes mode, select the file to be compared, then select the Compare with Previous Revision button.

• With the window in Incoming Changes mode, select the file to be compared, then select the Compare with Head Revision button.

If there are no differences, a message is displayed. Otherwise the Compare tool is displayed.

Use this procedure to replace a file with the base or head revision, or with a file with a specific revision number or tag. The head revision is the latest one. The base revision is the revision from which the one you are currently working on originated.

To replace a file with a CVS revision:

The history and status of a file will tell you what has been done to it, and what has been done to it last. This can help you make the determination of what you need to do to bring the file up to date, or to begin making your own modifications.

Use this procedure to open the History Viewer and view the history of CVS files.

To view the history of a project or file:

• With the project or file selected in the Applications window, choose Team > Version History from the context menu.

  For more information while using the History Viewer, press F1.

Use this procedure to check the status of a file that is under CVS source control. You can also refresh the status of files under CVS control.

To view the status of a file:

Possible statuses are:

• Changed locally - the file has been locally modified since it was copied from the repository.

• Changed in repository - the file has been modified by another user since it was copied from the repository.

• Locally removed - the file will be removed during the next commit.

• Locally added - the file will be added during the next commit.

• Up-to-date - the file is up-to-date with the latest CVS repository revision.

• File has conflicts - these may have resulted from a file update or commit action. If necessary, consult your CVS administrator for assistance.

• Needs merge or needs patch - the file has been updated externally, for example, by another user.

• Modified - the file previously had merge conflicts, but the timestamp has changed since.

If there is a conflict between your copy of the file and the one in the Team System server when you attempt to check it in, you will see a message box saying that the operation cannot be completed. To overcome this problem, you must first cancel the check-in operation, then do one of the following:

• Revert to a non-conflicting version of the file.

• Resolve the conflict using the merge tool in the Team System client software.

To revert to a non-conflicting file version:

• Select the file in the Applications window and choose Team > Undo.

Use to undo the most recent change to a file.

To undo changes:

Use this procedure to replace a file with the base version. The base version is the version from which the one you are currently working on originated.

To replace a file with the Team System base revision:

Use this procedure to open the History Viewer and view the history of files held under Team System control.

To view the history of a file:

• With the file selected in the Applications window, choose Team > Version History from the context menu.

For more information while using the History Viewer, press F1.

Use these procedures to compare files that are under Team System control with other versions of the same files, or with other files.

To compare versions of a file:

1. From the context menu for the file, choose Compare With.

2. Select either Previous Version, Latest Version or Other Version.

If there are no differences, a message is displayed. Otherwise the version or versions are shown in the History tool.

To compare a file with another file:

1. From the context menu for the file, choose Compare With > Other File.

   The Select File to Compare With dialog is opened.

2. Select the file to be compared.

   The files are shown in the Compare tool.

To compare two files:

The files are shown in the Compare tool.

You may wish to record the changes between two revisions of a file, then apply those changes to a third file. You do this by creating a patch and then applying it.

To create a patch:

This generates a patch comprising the differences between a controlled revision of a file and a revision of the file held locally.

Once you have created a patch, you apply it from the Team menu.

To apply a patch: