Please note : This help page is not for the latest version of Enterprise Architect. The latest help can be found here.

CVS with Remote Repositories

Before you can connect to a remote repository, you must:

  • Have version control setup on your local machine
  • Have version control setup on a remote server
  • Have a working directory on your local machine that points to the repository on the server.

To set up CVS version control with a remote repository, follow the steps below:

  1. Ask your system administrator to install CVS and create a remote repository with a module that you can use to control your Enterprise Architect package files. Your administrator must create a username and password for you before you can make a connection.
  2. Open a command prompt window and navigate to, or create, a suitable directory to hold your CVS working copy directory; for example:

C:\> cd myCVSWorkSpace

  1. Connect to the remote CVS repository. An example connection command is:

C:\myCVSWorkSpace> cvs -d:pserver:myUserID@ServerName:/repositoryFolder login


Replace myUserID with your CVS username, replace ServerName with the name of your CVS server and replace repositoryFolder with the path to the repository on the server.

  1. Create a local CVS workspace, derived from the remote repository. An example command is:

C:\myCVSWorkSpace> cvs -d:pserver:myUserID@ServerName:/cvs checkout moduleName


The above command creates a subdirectory in your current working directory, called moduleName. (Replace moduleName with the name of the module created by your system administrator). It creates local copies of all files contained in the CVS module found at ServerName:/cvs.

It also creates a subdirectory beneath moduleName, called CVS. This subdirectory contains a file called Root, that contains your CVS connection information. Enterprise Architect uses this file to obtain your CVS user ID.

  1. Verify that your CVS installation is working correctly.
  2. Change directory to the one you specified as the working copy, in the cvs checkout command above; that is, C:\myCVSWorkSpace\moduleName
  3. Now create a test file, such as Test.txt, containing the text CVS Test. You can do this with the command:

echo CVS Test > Test.txt

  1. Execute the following CVS commands:
  • cvs add Test.txt
  • cvs commit -m"Commit comment" Test.txt
  • cvs update Test.txt
  • cvs edit Test.txt
  • cvs editors Test.txt
  1. The editors command should produce output resembling the following:

Test1.txt myUserID Tue Aug 9 10:08:43 2009 GMT myComputer C:\myCVSWorkSpace\moduleName

  1. Take note of the userID that follows the filename. Enterprise Architect must find and use this user ID when you create your version control configuration. (See the example dialog below.)
  2. Launch Enterprise Architect and open or create the model containing the packages to place under version control.
  3. Select the Project | Version Control | Version Control Settings menu option. The Version Control Settings dialog displays.
  4. Click on the New button, enter a suitable name in the Unique ID field, then click on the CVS radio button in the Type field.
  5. To specify the Working Copy path value, click on the Select Path button. Select the local folder in which to keep local working copies of the XML files to be stored in the Version Control repository.
  6. Click on the OK button to return to the Version Control Settings dialog.
  7. The Current User field should display the user name used to log into the remote CVS repository. If this does not happen, it indicates that Enterprise Architect cannot extract the user name from the file ...\WorkingCopyPath\CVS\Root and the configuration does not work correctly.
  8. If necessary, set the CVS Exe Path by clicking on the Select Path... button and browsing to the file path for the for file cvs.exe, the CVS executable.
  9. Click on the Save button to save the configuration you have defined. The new configuration is added to the list of Defined Configurations.


A new entry is also created in the Local Paths list, with the same ID as the new version control configuration. The Local Path entry records the Local Project path, for use in subsequent path substitutions.


Use to

This model is Private

Specify whether all users connect to a single shared copy of the model (such as a DBMS) or each user connects to their own private copy of the model.

When unselected (for shared models), the option disables the File History - Retrieve functionality when the selected package is checked out by another user. This prevents modifications that might have been made by the other user from being discarded through importing a prior revision from version control.

Save nested version controlled packages to stubs only

Set nested version controlled packages to stubs or fully expanded trees. Defaults to selected.

For a full explanation of this option, see the Version Control Nested Packages topic.

Unique ID

Specify a configuration name that readily distinguishes it from other configurations. The unique ID displays as a selection in a list of Version Control configurations a package can connect to. In addition it is possible to select a previous version control configuration from this drop-down menu providing the configuration is not in use in the current model.

Working Copy path

Specify the folder where the XML files representing the packages are stored. This folder should already exist before it is specified here.

Every version control configuration you define in Enterprise Architect, should have its own local working copy folder in which to store working copies of the XMI package files; this should not be a shared network folder. Particularly bear this in mind if you are creating an Enterprise Architect project that is to be shared (e.g. a SQL database).

Current User

Specify the CVS user name associated with all CVS commands that are issued. This name is used by Enterprise Architect, to determine who has a package 'checked-out'.


Specify the full path of the CVS client's executable file.


Sparx Systems strongly urge you not to manipulate version controlled package files outside of Enterprise Architect. It is possible to leave the package files in a state that Enterprise Architect cannot recognize.