on the topic of EA version control

the following are excerpts from online research and do not represent much in the way of original thought. if you would like the MS Word version, click here: EA versioning.

Version Control

With in-built support for CVS and SCC compliant version control systems, EA allows precise management of the development process and the ability to share different models and frameworks across an entire organization, either locally or in a highly distributed manner.”

EA’s version control system allows for storing in any compliant system of standard XMI text files. These may then be versioned and distributed to developers, analysts, managers and team members in general, either for inclusion in privately assembled models (“private mode”) or as part of the control and management of a shared DBMS (“shared mode”).

EA allows for complex nesting of versioned packages, and the ability to easily reconstruct complex models from a single or multiple root packages. By importing a versioned root package into a “clean” model and invoking the “GetAll” command, an entire model can be populated from scratch – making the possibility of building “on demand” models a reality.

For example, a developer may include versioned root packages like these:

  • Use Case Model
  • Design Model
  • Java Framework
  • Server Framework
  • Requirements Model

Presuming these are all versioned packages that have been developed over the lifetime of the current project, once these are imported into a clean EA model, it is simply a matter of invoking the “Get All” command to fully populate the model with the latest information.

EA supports the popular CVS version system natively, and a wide range of popular tools, such as ClearCase, Visual Source Safe, Accurev, Perforce and others.

For maximum flexibility EA also lets you link a single model to multiple version control repositories – and it lets you use different version control providers within the same model. This lets you cleanly partition your models into different version controlled repositories, and still bring them back together in a single model file or shared DBMS project.

Version control is also a great way of working in a highly distributed environment – either with each developer having their own “private” model – or with small to medium sized teams sharing a controlled model. The distribution and propagation of changes within the models can then be left to the version control system.

With the new “Compare and Diff” functionality built into EA Professional and Corporate, you can also do a quick “Diff to Latest File” on any versioned package. This lets you monitor your changes and verify your work before committing back to the main repository.

So if you need to carefully manage the development process and keep precise versioned copies of completed work and work in progress, then EA has the capability to meet your needs.

Features

Version Control provides two key facilities:

  • Coordinating sharing of packages between users
  • Saving a history of changes to Enterprise Architect packages, including the ability to retrieve previous versions.

Set-Up

Before using Enterprise Architect’s version control facility, your version control software must be installed on each machine on which it is intended to be used.

Typically there are:

  • A server component that manages a version control repository, and
  • Client components on the workstations that Enterprise Architect uses to communicate with the server.

A version control client must be installed on every machine where you run Enterprise Architect and want to access your version control system. Once the version control software has been installed and configured, you must define a Version Control Configuration within Enterprise Architect, to use your installed version control product.

Note:
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.

 

Usage

There are four basic ways in which the version control facility might be used:

Use Description
Single Shared model Users share an Enterprise Architect model, stored in a central .EAP file or DBMS repository. This configuration enables you to view changes to other users’ packages without explicitly having to check them out, but by simply refreshing your view of the model.

  • Version control regulates access to packages, and maintains package revision history.
Multiple Private models An Enterprise Architect model is created by a single user who configures it for version control. The model file is then distributed to other users, with each user storing their own private copy of the model.

  • Users update their model’s packages through version control
  • Version control regulates access to packages, and maintains package revision history
  • Other users’ new packages are retrieved using the Get Package menu option.
Shared packages Individual users create separate Enterprise Architect models but share one or more packages.

  • Users share packages through version control.
Standard packages A company might have a standard set of packages which are broadly shared (on a read-only basis).

Version Control Indicators

Packages under version control are identified in the Project Browser by icons that indicate the current status of the package.

Icon Indicates that…
 refer to EA documentation This package is controlled and is represented by an XMI file on disk. Version control either is not being used or is not available. You can edit the package.
 refer to EA documentation This package is version controlled and checked out to you, therefore you can edit the package.
 refer to EA documentation This package is version controlled and not checked out to you, therefore you cannot edit the package (unless you check the package out).
 refer to EA documentation This package is version controlled, but you checked it out whilst not connected to the version control server. You can edit the package but there could be version conflicts when you check the package in again.

For example, below, CVSOO and CVSPackage are configured for version control. CVSOO is checked out to you, and CVSPackage is not.

See Also

System Requirements

Version controlled packages are packages that have been configured for use with version control software. To use version control in Enterprise Architect, a third-party source-code control application is required that controls access to and stores revisions of the controlled packages. Enterprise Architect supports the following version control applications:

  • Subversion, which is available from http://www.subversion.tigris.org/
  • CVS, which is available from http://www.march-hare.com/cvspro/
  • Microsoft Team Foundation Server
  • SCC-compatible products; all version control products that provide a client that complies with the Microsoft Common Source Code Control standard, version 1.1 or higher.

The following products are SCC-compatible and are known to successfully integrate with Enterprise Architect:

– Accurev Tested by Sparx
– Borland Star Teams Users report success
– ClearCase Users report success
– MS Visual Source Safe Tested by Sparx
– MS TFS-SCC Tested by Sparx
– MKS Source Integrity Tested by Sparx
– Perforce Tested by Sparx
– Serena Dimensions Users report success
– Serena Change Manager Users report success
– Snapshot CM Tested by Sparx
– SourceGear Vault Tested by Sparx
– Source Offsite Tested by Sparx

Products that do not appear in the list should still integrate successfully with Enterprise Architect, if there is a client available for that product that complies with the MS SCC API specification.


Optimizing Performance

When sharing large models over a network (LAN or WAN), some considerations should be made to optimize performance. In general, performance depends on:

  • The model repository type used (EAP or remote DBMS).
  • Whether version control integration is used to manage editing of shared models
  • The network response time, which is based on:
    • Network load
    • WAN latency (a low latency WAN connection has under 40-50ms latency)
    • Note: best used in conjunction with the WAN Optimizer (see below).

The following tables indicate which network and repository type configurations allow for high performance. The first table considers repository configurations that do no not use Enterprise Architect’s version control integration capability, while the second table allows for version control.

Table 1 — Configurations without version control integration

 Configurations without version control integration


Table 2 — Configurations with Version Control

When using Enterprise Architect with Version Control across a LAN or a WAN, performance is dependent on the Version Control system in use, as well as network response times. Each Version Control system has different response times; however there are a number of options available and points to consider for the best results. Below are comments on these options:

Configurations with Version Control

The material for this post is compiled from other sources and protected by copyright law. (C) Sparx Systems Pty Ltd.

wanna say something?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s