Copyright: Repository Mgmt Online Help - V9.0.2.93.7  Copyright © 1995, 2003, Oracle Corporation  All Rights Reserved


About repositories

In everyday language, a repository is a place where objects are stored, and a similar definition carries over into the language of information technology. In the computing sense, a repository is a single, central location storing descriptive information about the data that an enterprise maintains.

This descriptive information about the enterprise's data is known as meta data - data that describes data. For example, the enterprise might maintain an employee information system in a database table named EMP. In this system, an employee name would be the original data, while the meta data would be the description of the column in the database table where employee names are stored.

Meta data can include descriptions of:

•	applications used across the enterprise

•	data required by each application

•	the development environment

•	the development tools used to integrate and customize enterprise applications

•	data warehouse and decision support systems

A repository can contain meta data about:

The structure within a repository in which meta data is stored is known as a meta model. The richer the meta model, the easier it becomes to describe systems through meta data.

Who uses a repository?

The main categories of repository user are likely to be developers of:

•	enterprise-wide applications

•	decision support tools

•	application development tools

Enterprise-wide applications

You can use a repository as the basis for developing just about any kind of database application. Airlines, finance, health care, manufacturing, oil exploration, public utilities, travel agencies - these are just a few industry sectors that have benefited from repository-based development of applications.

For developing custom applications for an individual enterprise, a repository can offer gains in productivity throughout the development lifecycle, through component reuse, an integrated development toolset and the benefits of team-working. For developing packaged applications that can be marketed to an entire industry sector, a repository can help to ease integration of the various package components, as well as enable customization of the package for a particular site or user.

Before applications are built, however, enterprise management may decide to analyze the business processes or information systems of the organization. A repository can hold the results of these analyses too - the users in this case are likely to be business analysts, systems analysts and systems designers.

Decision support tools

By providing ad-hoc query, reporting and analysis capabilities, decision support systems enable business users at all levels of an organization to gain immediate access to information. Decision support tools can be used, for example, in the analysis and development of data warehouse systems. If these systems are based on a repository, the complexity of data structures and relationships can be hidden from business users, who need to focus on business issues rather than data issues.

Data warehousing

A common warehouse meta model, stored in a repository, may be required during the runtime of a data warehouse system as well as during design time. Repository services can be used at runtime to install and manage customers’ extensions to the common warehouse meta model.

Application development tools

Some users will want to develop their own tools to work directly with the contents of a repository. These users can gain productivity through the development lifecycle from tool integration, team working and component reuse.

Why use a repository?

Of course, you can make use of information technology without employing a repository at all. For example, for simple applications with only a few data entry screens and output reports, a repository-based approach could be excessive. However, for data operations involving any degree of complexity, a repository gives you a much greater degree of control over the process.

For example, one major advantage of a repository when implemented on a multi-user system is that it allows large teams of developers to work together on the same application design. If your team is developing a complex financial application, for example, central control of the project's components is vital.

Another important advantage is the ability to reuse components in different areas of an application. For example, if one developer designs part of a screen form (such as a button and its associated code) that could be used on more than one form, you can reuse that component as many times as you like, thus avoiding duplication of effort and ultimately saving development time.


About repository users

Because it is implemented in an Oracle database, Oracle Repository can be used by a single user, or it can be accessed simultaneously by dozens, even hundreds, of users provided that suitable hardware is in place to support this.

Any user who has access to the Oracle database can potentially be a repository user. One main user, typically the database administrator at the site, is designated as the repository owner and has complete control over installing, upgrading, backing up and deleting the repository, as well as granting repository access to other database users and performing day-to-day repository administration.

Repository users other than the repository owner are referred to as subordinate users. These users have access to all the features of the repository, but are not able to perform certain repository administration tasks.


About repository objects

A repository acts as a common area where users can store definitions of repository objects - the individual items of meta data that are the building blocks from which applications can be created. Application developers use software such as diagramming tools, either from Oracle or from third-party suppliers, to create these object definitions in the repository, refine them, test them, and then build complete applications from them.

Element types

A repository object is a specific instance of a particular element type. Oracle Repository provides a basic set, and Oracle Designer a much larger set, of predefined element types, each of which has a standard set of properties. For example, the element type Table Definition has properties such as Name, Display Title and so on.

There are various classes of elements. The most important are primary access controlled (PAC) elements and secondary access controlled (SAC) elements. A repository object consists of a single PAC element, plus any SAC elements defined for it, plus any references defined to other objects.

PAC elements (e.g. modules, table definitions) are owned directly by the container in which they were created or to which they have been moved.

Each PAC element can have a number of SAC elements (e.g. arguments of a module, or columns of a table definition), and can be created only if the appropriate PAC element exists. Some SAC elements can have their own SAC elements; for example, the PAC element type Table Definition has, among others, a SAC element type called Column which in turn has a SAC element type called Allowable Values. All SAC elements are owned by the PAC element under which they were created. So, for example, when you copy or delete a PAC element, its SAC elements are copied or deleted also.

User extensibility

The repository owner can create further, user-defined properties for a particular element type besides the standard properties for that type. Repository users can subsequently define values for those properties as well as for the standard ones. In addition, the repository owner can create complete user-defined element types besides the standard ones.

A standard set of association types enables users to define references between repository objects. The repository owner can create user-defined association types in addition to those provided as standard.

Similarly, a standard set of text types enables users to define various kinds of free-format text to do with an element type or association type, such as Description or Notes. The repository owner can create user-defined text types in addition to the standard ones.

Useful features to do with repository objects

In all but the smallest repositories, it is easy to lose track of which objects have been defined and by whom. The repository search feature enables you to search for objects, either across the entire repository or within a particular workarea. You can perform simple searches, for example by object name, or more advanced searches using complex search conditions. You can also restrict the search to repository objects of a particular type, for example table, column and so on. It is possible to search for a particular object by name, or to search for all objects with one or more properties that correspond to specified conditions.

You can compare the properties of two repository objects of the same type. The results of the operation are presented in a graphical display that highlights any property differences between the two objects. You can also merge two objects together, selecting which property values are to appear in the resulting object.

It is possible to define objects of certain element types in an element hierarchy, and display the hierarchy in the Repository Object Navigator. You can do this by defining a particular object as the parent of one or more other objects of the same element type.

Ownership of repository objects

A repository object is owned by a container, a logical subdivision of the repository, similar to a directory in a file system. An object is owned by the container in which it is created or to which it is subsequently moved. A container is owned by the repository user who creates the container, or to whom ownership has been transferred. You cannot grant access rights to a specific object, but you can grant these rights to the owning container.

Version control of repository objects

As developers make changes to objects in the repository (for example, changing the name or some other property of the object), the need can arise to keep track of the changes made. The version control feature of the repository allows you to record every change made to an object during its life cycle, using version numbering and version labeling systems for ease of identification.

The record of the changes to a particular object is known as the version history of the object. Both the standard element types and any user-defined element types enable you to create objects that are versionable (that is, capable of being placed under version control). About

Version control applies to a repository object at the PAC element level, so in effect the entire object is versioned. You cannot version individual SAC elements of a repository object.

A repository is installed with the version control feature disabled. The repository owner can subsequently enable this feature if version control is required. Note that once version control has been enabled, you cannot subsequently disable it.


About text colors

Names and properties of repository objects are shown in different colors in various tools. The following list shows the default colors, though these can be changed. How

The Option column shows types of item for which you can change the text color.

Option	Description	Default Color
Normal	Standard text	Black
Error	Properties that have been given an invalid value	Red
Modified	Properties for which a value has been specified but not saved	Blue
ReadOnly	Objects that cannot be updated (e.g., locked elements)	Green
Mandatory	Parameters for which a valid value must be specified	Red
Inherited	Properties of an object subtype that have been inherited from its supertype	Magenta
"Universal" values	Module property values that are not valid for the language defined for the module, but which could be valid if the module was generated for a different language	Red
FileSystem	Files in a file system that has been mapped to a folder but which have not been uploaded to the repository


About version control

Related Topics

Version control is the process of maintaining multiple versions of software development objects and is the most basic requirement for a software configuration management system.

Both repository and non-repository objects can be version-controlled in the common repository. About

The repository manages all repository objects, as well as file system files and directories. This enables the tracking of changes to the organization of the source data, as well as tracking the changes to the contents of individual files.

Versions are organized into a version tree structure with branches. Branches have user-defined labels, typically chosen to indicate their role in the development process.

All object versions can be identified by system-generated version numbers or user-defined version labels. You can choose the format used to identify object versions:  either the version label, or the branch label followed by the version number. How

Version history

Each object in the repository is held as a set of snapshots, called object versions, of its state at certain points in time. The object versions are linked together by associations that record how each object version evolved from its predecessors. This web of associations, represented by the version tree, is called the version history of the object and can show succession, branching and merging.

The version history associations also have a number of version control attributes, including:

•	a unique version identifier

•	the identifier of the user who created the object

•	the date and time the object was created

•	the identifier of the user who changed the object

•	the date and time the object was changed

•	status of the object (for example checked out or checked in)

•	a comment (a descriptive reason for checking in or out)

Checkin and checkout

Version control starts when an object is checked in. Objects that are checked in are write protected. The object must be checked out before it can be modified.

Only one version of an object can be included in a workarea and only one version of an object is visible through the workarea view. However, the complete history of an object and all the events that occurred to it can be viewed through tools provided by the repository.

Any file or folder in your file system, as well as repository objects, can be the subject of version control. You can copy files and folders into the repository and copy them back to the file system. You can also synchronize your file system with the repository at any time to ensure both are consistent. About

When checking an object in or out you can provide notes to briefly describe the reason for the action.

Once the object is checked out a copy of the object is moved into your workarea. Your workarea contains all the checked-out objects you are working with. When the object is checked out, the workarea is refreshed so that the new object version appears in your version resolved view and can be edited by you.

You can undo a check out but any changes you have made to the object are lost. The system administrator has the privilege to cancel a checkout.

Branching

When checking in an object, you can decide if the changes are to be included in the branch from where the object was checked out or if the changes are to be represented on a new branch. Branch labels can provide some meaning to the development strand, for example, as a set of changes related to bug fixes.

Many of the checkin options are available by default. For example the default action could be to create a new branch, with a specified label. This default would apply to all objects checked in from your workarea. This could enable all the changes made on a given set of objects to be queried from the repository and used in release management or quality assurance procedures.

Locking, comparing and merging

During the checkout operation, the object can be locked so that no other users can check out a copy for editing. If you choose not to lock the object, there is the possibility that when the time comes to check the object back in, another user may have made changes in the interval. In these circumstances, and depending on who checks their version in again first, the compare and merge tools have to be used to ascertain how to check the object back in.

A compare operation compares two object versions and displays the differences and details of the two object versions in the Compare window.

A merge operation combines changes that have occurred independently in two object versions. A merge is typically required when development has taken place on a branch and the changes need to be incorporated back onto the main line of development.

The merge operation takes two contributor object versions, compares them to a common ancestor version, and uses internal rules to create a result version based on changes found in all three versions.  The differences and conflicts encountered by the merge algorithm are displayed in the Merge window, enabling to view the selections and, if necessary, to override those selections before the result is produced.


Versionable objects

The following element types allow you to create versionable objects (that is, objects that are capable of being placed under version control):

0	 Application Systems

1	Assumptions

2	Business Functions

3	Business Terminology

4	Business Units

5	Cluster Definitions

6	Communities

7	Configurations

8	Critical Success Factors

9	Data Items

10	Datastores

11	Diagrams

12	Documents

13	Domains

14	Entities

15	Extended Elements

16	Externals

17	Files

18	Folders

19	Java Class Definitions

20	Key Performance Indicators

21	Languages

22	Locations

23	Materialized View Definitions

24	Modules

25	Nodes

26	Non-Persistent Queues

27	Objectives

28	Oracle Collection Types

29	Oracle Databases

30	Oracle Object Types

31	Other Databases (than Oracle)

32	Persistent Queues

33	PL/SQL Definitions

34	Preference Sets

35	Problems

36	Process Events

37	Queue Table Definitions

38	Record Files

39	Records

40	Reusable Lists of Values

41	Reusable Module Components

42	Sequence Definitions

43	Source Files

44	Storage Definitions

45	Synonyms

46	Table Definitions

47	Transformation Mapping Sets

48	User-Defined Sets

49	View Definitions


About workareas

Oracle Repository can support large numbers of concurrent users. An individual user may not want to see a list of every object in the repository. In addition, some kind of mechanism is needed to ensure that one user does not interfere with another user's work. Oracle Repository solves both these problems by allowing you to create individual workareas - specific views of the repository through which you can work on your own objects. In this way, you can avoid seeing objects belonging to other users, and you need not be concerned that your changes might be overwritten by someone else:

As an example, assume that version control has been activated and User A wants to work on some of the repository objects that he or she owns. User A checks these objects out, locking them at the same time. Other users can still check out and update these objects, provided they can access them. However, they cannot check them back in to the same branch until the lock is released. User A then works on the objects and, having finished, checks them back in. This releases the lock, allowing other users to check in their versions. However, it will then be necessary to merge their versions with User A's versions to enable checkin.

It is possible to check out and update an object without locking it, allowing other users to check out the same object and possibly update it as well. In this situation, the first user to check the updated object back in is allowed to do so, while updates from other users must be merged with the original updates. It is also possible to set a repository option to lock every object when it is checked out. This option, known as a strict locking policy, prevents any other user from checking out the object until the first user checks it back in.

Oracle Repository provides a Workarea Wizard - a predefined set of screen forms that take you step by step through the process of workarea creation. When you create a workarea, it is initially a private workarea, meaning that only you can access it. Subsequently you can, if you wish, grant one or more other users access to it, thus making it a shared workarea. If you later revoke access to the workarea from all other users, the workarea becomes private again. Note that the repository owner must have assigned you the Workareas repository privilege before you can create workareas.

Any user granted access to a shared workarea can update a repository object visible in that workarea, provided that that user has update access rights both to the workarea and to the container that owns the object.

When you create a workarea, you are its owner. You can subsequently transfer ownership to another user.

It is possible to choose exactly which repository objects or object versions you want to see in a particular workarea. Options are available that enable you to include or exclude specific objects or versions, for example.

If you are using version control, only one version of a particular object is visible in a workarea. However, you can change the version that is visible in the workarea you are currently using.

At least one workarea must be available to you before you can do any work in the repository. You can either create a workarea yourself, or use a shared workarea that has been made available to you. In a workarea, you must create at least one container before you can create other repository objects. Any versioned container or object can be included in (that is, visible from) more than one workarea. However, a non-versioned container or object cannot be visible from more than one workarea.

You make objects visible in a workarea by defining a workarea specification consisting of a set of rules, which define the precise versions of  objects that are to be visible in the workarea. For example, you can specify that the workarea is always to include the latest version of objects on a particular branch, or the latest version between two dates, and so on. In addition, you can include configurations - predefined sets of object versions - in your workarea specification.

You can create a workarea from a specification file containing rules, configurations or both. Specification files have the default extension .CWS.

When you refresh a workarea, the workarea contents are redisplayed according to the current workarea specification. As a result, objects may be added to, updated in, or removed from, the set of objects visible in the workarea. Refreshing a workarea also resolves potential version conflicts for objects in the workarea.

Here's an example of the effect of refreshing a workarea whose specification includes two potentially conflicting configurations:

In this example, which assumes the use of version control, version 1.1 of object A is included in workarea WA1, together with the other objects. Version 1.2 of object A is excluded because its configuration, config2, is lower down the list than config1, which contains version 1.1 of the object.

You can preview the effect of refreshing without actually performing the operation.

You can set up a workarea to work with a specific development branch. To do so, you specify a default checkin branch to ensure that all versioned objects updated via that workarea are assigned to the same branch on checkin. For this feature to be effective, the automatic branching policy must be active.

It is possible to compare two workareas. You can compare either the workarea contents or the workarea specifications. The results of the operation are presented in a graphical display that highlights any differences between the two.

Note:	If you are not using version control, only a single, shared workarea (known as the global shared workarea) is available for all users to create and maintain objects. This workarea cannot be edited or refreshed, nor can you include or exclude specific objects. No further workareas can be created unless version control is enabled.


About containers

Even within a single workarea, you may be able to see hundreds, even thousands, of objects. Some way of organizing these objects is necessary. Oracle Repository provides different types of containers in which to organize your objects.

Containers are similar to directories in a file system - they are simply a means of organizing repository objects in a logical fashion. Note that the repository owner must have assigned you the Containers repository privilege before you can create containers.

There are two types of container, folders and application systems, either of which can hold instances of any type of repository object. Folders are available even if you install only the core repository (for example when using the repository as a source control system). Application systems are available (as well as folders) if you install Oracle Designer, for application development.

A special folder, the system folder, contains a number of predefined language types, such as Java or Oracle Forms. You can use these when defining application modules, for example. The system folder also contains a predefined preference set for use with Form Generator, to optimize the look-and-feel of generated applications.

When you create a container, you are its owner. You can subsequently transfer ownership to another user.

Any container can be placed under version control, as can any or all of the objects it contains, but objects and their containers are versioned independently of each other. A new version of a container is created when its owner either adds or removes objects in it, or changes one or more of its properties (for example its name).


About references

You might need to create a link between one repository object and another. For example, you might want to record the fact that one object refers to another, such as an application module using a particular database table definition. This kind of link is known as a reference, and you can create one using repository tools or other tools (such as diagramming tools). Some repository tools indicate references by displaying a [image] icon next to the name of the referenced object.

A reference is an instance of an association type. The objects in the association must be of two element types for which an association type exists in the repository. Oracle Repository supplies a number of predefined association types, and the repository owner can create others by means of the user extensibility feature.

While working in a particular container, you might want to view or edit details of an object owned by a different container that is visible in your workarea. Oracle Repository allows you to do this by creating a shortcut (that is, a link to an object that is not owned by the current container). In the repository tools, these kinds of reference are indicated by a [image] icon next to the object name in the container from which the object is referenced. Shortcuts are simply a convenient way of accessing objects in other containers.

An external reference occurs when an object that you are viewing in a particular context (a workarea, container or configuration) has a reference to another object outside that context. For example, a container called App1 owns an entity called ENT_A with an attribute ATT_1 that belongs to a domain called DOM_1. However, DOM_1 is owned by a different container, App2. Container App1 is then said to have an external reference to App2.

Oracle Repository provides a utility that enables you to list the external references for a particular workarea, container or configuration. This could be particularly useful, for example, after refreshing a workarea as it allows you to add to the workarea any further objects that are needed to maintain referential integrity for that workarea. Another use of such a list would be when exporting a set of repository objects to another repository. Here it is necessary to check that no external references exist in the set, so that the exported collection of objects is complete.


About wastebaskets

When you delete a non-versioned repository object, it is not immediately removed from the repository. Instead, it is placed in a storage area called a wastebasket, similar to the recycle bin in Windows.

You can either remove the wastebasket contents completely from the repository by emptying the wastebasket, or you can restore some or all of them to the repository, for example if you deleted a non-versioned object by mistake. Note that restoring an object restores only the primary access controlled (PAC) element of the object. Secondary access controlled (SAC) elements, including references to other objects, are not restored.

If you delete a non-versioned container, any non-versioned objects it contains are also placed in the wastebasket. You can identify the container that was the owner of a wastebasket object either from the Owning Container property in the Property Palette, or by viewing version details about the wastebasket itself.

There is a separate wastebasket for each workarea in the repository. In addition, there is a global wastebasket, which includes the contents of all the workarea wastebaskets, together with any objects or object versions that are not visible in any workarea.

You can view the contents of a wastebasket from the Navigator window of the Repository Object Navigator. The wastebasket for each workarea is shown under the workarea node:

The global wastebasket is shown under the All Containers node:

The node named Lost+Found refers to an additional storage area for those objects that have no owning container anywhere in the repository. This means that any object that is not owned, but has been shared in the repository, appears in the Lost+Found folder and so is able to be reached and manipulated.


About deleting and purging repository objects

Related Topics

Oracle Repository enables you to manage the removal of repository objects in a carefully controlled manner.

Many repository objects include references to other objects that exist in the same repository. When you delete a repository object, you need to specify what happens to any objects that reference the deleted object.

If an object is under version control, you will need to specify whether you want to delete an object version (that is, remove that version from a particular container) or purge one or more versions of an object (that is, remove them from the repository altogether).

Various repository tools permit the following operations:

Delete

Force Delete

Purge

Force Purge

Delete and Purge with checked-out objects

Recover a deleted or purged object or version

Summary of operations permitted

The following tables summarize the operations that are permitted on the various kinds of primary access controlled (PAC) elements of repository objects and their secondary access controlled (SAC) elements.

PAC elements

Operation	Checked-in versioned object	Checked-out versioned object	Non-versioned object
Delete	Yes	No	Yes
Force Delete	*	No	Yes
Purge	Yes	**	Yes
Force Purge	Yes	No	No
            *  uses Force Purge
            ** does an undo checkout

SAC elements

Operation	Checked-in versioned object	Checked-out versioned object	Non-versioned object
Delete	No	Yes	Yes
Force Delete	No	Yes	Yes
Purge	No	No	No
Force Purge	No	No	No
Referential integrity

When you attempt to delete a PAC or SAC element that is referenced by another element, one of three things can happen. Assume you want to delete an element, Element A, that is referenced by another element, Element B. The possibilities are as follows:

•	Element B blocks the operation

•	Element A, Element B and any other referencing elements are deleted (this process is known as ‘cascade delete’)

•	Element A is deleted; Element B is not, but its reference to Element A is nullified

For an ordinary delete operation, what happens in each case is governed by the referential integrity rules defined for each element type in the Oracle Repository meta model. However, you can override any blocking rules by means of a force operation (see below).

Note:	If you delete a PAC element (for example, a table definition), the object is not immediately removed from the repository. Instead, it is placed in an intermediate storage area known as a wastebasket. From a wastebasket you can either remove the object completely, or restore it.

If you delete a SAC element (for example, a column in a table definition), it is removed from the repository immediately and cannot be restored.


Delete, Purge and Force

Delete

You can delete a non-versioned object or a checked-in versioned object. You can do so only from within a particular workarea, and you must have DELETE access rights for that workarea and the container that owns the object. If the container is under version control, the container must be checked out.

A delete operation could be blocked by a referenced object, depending on the element types involved. Other referenced objects in the workarea may be cascade deleted, or have their references to the object nullified.

You cannot delete a root container (one that is not a subcontainer) that is checked in. You must use Purge for this (see below).

Note:	If you simply want to hide an object from your workarea’s view of the repository, you can exclude the object from the workarea.

If you delete a non-versioned object, the object is placed in the wastebasket for that workarea (when deleting repository objects and containers) or the global wastebasket (when deleting configurations).

If you perform a delete operation on a checked-in versioned object, the operation applies only to the object version that is visible in the workarea. In fact, the object version is not deleted as such; only its container membership is deleted. That is, the object version is removed from its container, but it is not placed in a wastebasket. (If the owning container is not under version control, the object version is placed in the Lost+Found folder.) The object version is retained in any previous versions of its container, but is no longer visible either in the current workarea or in any workareas that use subsequent versions of the container. The object version can be restored to the workarea by including a previous version of the container in the workarea.

You cannot delete a PAC element of a versioned object that is currently checked out. You must first either check the object in or undo the checkout.

To delete a SAC element of any object, you must have UPDATE access rights for the appropriate workarea and container. The same rules for blocking checks, cascade deletes and nullify operations apply as for PAC elements. If the object is under version control, the object must be checked out. SAC elements are not placed in a wastebasket when they are deleted, and thus cannot be restored.

Force Delete

If you want to remove a repository object PAC or SAC element and override any blocking constraints defined for the corresponding element type, you use Force Delete.

Using Force Delete on an object removes the PAC element together with any SAC elements owned by the PAC element, and any references that the object has to other objects. Any blocking references are either cascade deleted or nullified, depending on whether the reference property is mandatory or optional.

To force delete an object you must have DELETE access rights to the workarea and the owning container, and the Force repository privilege. If an object is referenced from a container other than the current one (that is, if [image] is displayed next to the object name in the Navigator), it can be deleted only from the owning container.

Force Delete is used for non-versioned objects. When you force delete a non-versioned object, it is removed to your workarea wastebasket. Force Delete has no effect on a versioned object that is checked out.

To forcibly remove (that is, to remove overriding any blocking constraints for) a versioned object, Force Purge is used. If you choose Force Delete with a versioned object, a force purge operation is invoked automatically.

If a force delete operation would result in the cascade delete of a SAC element (or the nullifying of one of its properties) of a checked in PAC element, the operation will be prevented. This is because SAC elements cannot be deleted or have properties updated if their owning PAC element is checked in.

Purge

Purge works only on a checked-in versioned object, completely removing some or all object versions from the repository. Purged objects or object versions cannot be restored. (Delete, by contrast, removes only the container membership for the object version.)

When you purge a version of an object, that part of its version history is also completely removed and does not appear in either the Version History Viewer or the Version Event Viewer. The version number of a purged version is not reused when a new version is created.

You cannot purge a non-versioned object or a SAC element.

It is possible to purge:

•	a specific version of an object

•	insignificant versions of an object

•	all versions of an object

Note:	If you try to purge the last remaining version (that is, the root version) of an object, OBJECT_A, that is referenced by one or more checked-in objects, the operation is blocked in order to maintain referential integrity. You would need to purge all versions of the referencing checked-in objects (or delete the references manually) before a purge of the root version of OBJECT_A would be allowed.

Purge Specific Version

You can purge a specific object version unless:

•	it is used in other workareas

•	it is used in a configuration

•	it forms a significant version in the object’s version history

The restriction on object versions used in other workareas exists because purging an object version from one workarea would affect other workareas and may introduce invalid references into the other workareas.

A significant version is defined as the:

•	root version in the history (unless it is the only version in the history)

•	first version on a branch (unless it is the only version on the branch)

•	source of a branch

•	source of a checkout

To perform a purge operation, you must have DELETE access to the appropriate workarea and container, and have the Purge repository privilege.

Purge Insignificant Versions

It is possible to make a object’s version history more compact by getting rid of those versions that are considered insignificant.

An insignificant version is defined as one that is:

•	not used in any workarea or configuration

•	not a tip node (the end of a branch)

•	not the root node in the object’s version history

•	not the first node on a branch

•	not the source or target of a merge

•	not the source of a checkout

To purge insignificant versions, you must have DELETE access to the object being purged, and have the Global Purge repository privilege. You can purge insignificant versions either on a particular branch, or throughout the entire object.

Purge All Versions

If you want to remove all evidence of a versioned object, you can purge all versions of it.

You can purge all versions either within or outside the context of a workarea. If you do so in a workarea context, secondary updates are performed on objects in the workarea (only the currently visible versions of referencing objects are be cascade deleted). The operation is blocked if any version of the object is used in a workarea other than the current context (or simply any workarea, if no context is set).

Force Purge

Force Purge acts only on a checked-in versioned object, completely removing from the repository the object version that appears in the current workarea, and overriding any blocking constraints defined for the element type. The object must be checked in first.

To perform a force purge operation, you must have DELETE access to the appropriate workarea and container, and have the Force and Purge repository privileges.

Note:	If you try to force purge the last remaining version (that is, the root version) of an object, OBJECT_A, that is referenced by one or more checked-in objects, the operation is blocked in order to maintain referential integrity. You would need to purge all versions of the referencing checked-in objects (or delete the references manually) before a force purge of the root version of OBJECT_A would be allowed.

Delete and Purge with checked-out objects

Normally you cannot delete or purge a checked-out object version. However, if a checked-out object version is referenced by an object that is deleted where this results in a cascade delete operation to the referenced object, the checked-out version is deleted.

Recover a deleted object or version

It is possible to reverse the effect of a Delete or Force Delete operation (but not a Purge or Force Purge operation) by recovering the deleted object or object version from the wastebasket. When attempting to reverse a Force Delete operation, the deleted object or object version is recovered, but reference properties nullified by the operation are not restored.


About file systems

One of the most powerful features of Oracle Repository is its ability to create and store files and file systems within the repository itself.

File creation from the repository

You can create a file directly in a container in the repository. If you give the file an extension for which a program is associated in Windows, you can use the program to open the file, edit and save it directly from the repository. How

Upload and download

From a disk-based file system, you can copy individual files or entire directory structures and their contents into a container in the repository (uploading). Subdirectories are stored as folders in the repository.

This feature is useful if you are using the repository as a source control system, as you can bring uploaded files or folders under version control. The feature also enables you to make files and directories accessible to applications that you are developing using the repository.

Files created in the repository, or uploaded to it, can also be copied to any local or remote file system that is accessible from your workstation (downloading). These files can be accessed through the repository by existing file-based tools (for example, text editors, word processors or other applications).

Note that you cannot upload to a shortcut reference (denoted by the [image] icon). About

Users of UNIX systems cannot upload from a symbolic link, though it is possible to download to a symbolic link.

Mapping and synchronization

You can perform a folder mapping operation to associate a container in the repository with a directory in the file system. When you subsequently select a container from which to download, or a file system from which to upload, the associated destination is selected by default. Mapping is also essential for synchronization, explained below.

Note:	Mappings are specific to the username and workarea under which they are created.

Once a container is mapped, the container access rights in the repository take precedence over any file system access rights. Thus if a file has the read-only attribute in the file system, this may be overriden in the repository.

Changes made to uploaded files in the repository are not necessarily reflected in the equivalent files in the file system. Similarly, if downloaded files are changed from the file system, the changes are not necessarily made in the equivalent files in the repository. If no mapping is in place between the two sets of files, changes can occur completely independently between the two sets. However, it is possible to synchronize files in the repository and the file system to ensure that both sets are kept up to date with each other. About

Performing a mapping implicitly activates synchronization, but performing a synchronization is effective only on mapped containers and their contents. The following table gives more details:

Operation	Mapping  required?	Repository and file system copies synchronized?	Notes
Upload/download	No	No*
Folder mapping	-	No	Simply creates an association between container and directory
Synchronize	Yes	Yes
Edit repository or file system copy	No	Only if mapped (see below)
   * user chooses whether to overwrite destination copy if different from source

If you open a file via the Repository Object Navigator, the repository copy and file system copy are synchronized if a mapping is in place. If there is no file system copy, the file is downloaded to the mapped directory if a mapping is in place, otherwise to the directory defined as your Windows temporary directory.

If you edit a file in an unmapped container via the Repository Object Navigator, the changes you make are stored in the copy in the Windows temporary directory. These changes are not reflected in the repository copy unless you synchronize, which requires a mapping to be performed first.

An automatic synchronization is performed before the following repository operations on files in mapped containers:  file open, checkout, undo checkout, checkin, compare and merge.

Synchronization makes use of files named .RVI on the mapped file system. These files store the synchronization information, and should not be edited or deleted. To ensure the integrity of the .RVI files, we recommend the following:

•	keep mapped directories local (i.e., do not give other users access to them)

•	ensure that no more than one client machine uses the same directory for mappings

•	do not map from two different workareas or repository users (or repositories) to the same file system directory

Case sensitivity in file and directory names

File and directory names are case sensitive in UNIX file systems, but not in Windows file systems. This can lead to differences in behavior between the two types of file systems for upload, synchronization, and download operations. About

File registry

Files are stored in the repository as either binary or text files, and in either compressed or uncompressed format. You can use the file registry feature to specify how a particular type of file, or even a file with a specific name, is to be stored. For example, you can specify that files with the extensions .SQL, .ORA, .TXT or .JAVA are stored as uncompressed text files, while those with the extension .EXE or .FMB are stored as compressed binary files. You can also override a specification for an individual file name. The repository is supplied with a number of file types predefined in the file registry.

The distinction between storage as binary or text files is necessary for the following operations:

•	compare

•	merge

•	end-of-line character translation (when converting text files between
MS-DOS and UNIX format)

The compare and merge operations are supported only for text files in ASCII or Unicode format. Specifically, compare or merge cannot be used for binary files (except Oracle Forms .FMB and .FMX files). One benefit of specifying a file type as binary is that if users inadvertently try to compare or merge files of that type, an error message will be displayed rather than unpredictable output.

End-of-line character translation is supported only for text files in ASCII format.

Files are actually stored in the repository as Binary Large Objects (BLOBs), irrespective of their specification in the file registry.

All files are stored as uncompressed by default. Storage in uncompressed format means that the repository does not perform its own compression on such files, though uploaded files may already be compressed by their native operating system (e.g., .EXE or .ZIP files). There is little advantage in using repository compression on files that have already been compressed in some other way.

Compressed format is useful for saving repository storage space for uploaded ASCII or Unicode text files, which are not normally compressed by their operating system.

One particular sequence of events is important to note. Assume that your file registry specifies that (for example) .TXT files are stored in compressed format, and you upload a file named ABC.TXT. You then decide that you want to store .TXT files as uncompressed, so you remove the file registry rule for .TXT files. In this case, subsequent uploads of ABC.TXT will still be in compressed format, while subsequent uploads of other .TXT files will be uncompressed, as this is the default. You will need to specify an explicit file registry rule to store .TXT files uncompressed before ABC.TXT will be affected.

File renaming

If you want to rename a file after you have uploaded it to the repository, you should do so from the repository (e.g. in the Repository Object Navigator) and not from the file system. This is particularly important if you change the file extension for any reason, so that the associated application (if any) for the new extension is correctly invoked when you edit the file from the repository.


About synchronization

An upload operation copies a file from the file system to the repository. If you edit the file, your changes are made to the file system copy, even if you open the file from the Repository Object Navigator. Oracle Repository provides a synchronization mechanism to enable you to keep the different copies up to date with respect to each other.

When you perform synchronization, the system checks whether any changes have been made to the repository copy, the file system copy, or both. The resulting actions are:

Repository copy	File system  copy	System Action
Unchanged		Unchanged	None
Unchanged	Checked in	Changed	Hijacked file - displays dialog for user intervention
Unchanged	Checked out	Changed	Uploads copy from file system
Changed		Unchanged	Downloads copy to file system
Changed	Checked in	Changed	Displays dialog for user intervention
Changed	Checked out	Changed	Displays dialog for user intervention

Files where the file system copy has been changed while the repository copy remained checked in are known as hijacked files. In this case you can choose to download the repository copy (effectively canceling the changes), check out the repository copy (enabling you to upload the file system copy or download the repository copy), compare the two copies or view the version history of the file.

In other cases where a dialog is displayed for user intervention, you can choose to upload the file system copy, download the repository copy, check the repository copy in or out or merge the two copies, resolving the differences one by one.

When you synchronize a mapped container for the first time, a file named .RVI is created in the corresponding file system directory. This file maintains the synchronization information for that file or folder, and should not be deleted or edited.

A few special cases of synchronization are worth noting:

•	If you delete the repository copy but not the file system copy before synchronization, the repository copy reappears on synchronization. This is because in this case it is treated as a new file and uploaded accordingly. The same applies if you exclude the repository copy from your workarea.

•	If you delete the repository copy but not the file system copy after the two have been synchronized, subsequent synchronization operations offer you the choice of deleting or retaining the file system copy. The same applies if you exclude the repository copy from your workarea. If you choose to retain the file system copy, on subsequent synchronization the repository copy reappears. This is because it is treated as a new file and uploaded accordingly.

•	You cannot synchronize a file system file with a shortcut reference (denoted by the [image] icon). AboutRS_About_references

•	Users of UNIX systems cannot synchronize a repository-hosted file with a symbolic link on the file system.

•	The effect of synchronization can differ between Windows and UNIX file systems owing to the case-sensitive nature of UNIX file and directory names. About


About configurations

Related Topics

A configuration is a collection of repository object versions, usually related in some way that is significant to an application. Any set of specific object versions can be recorded as a configuration, rather like the striping or labeling features of some configuration management systems. Example

Usually a configuration represents all the object versions that represent a checkpoint in development or component of an application, for example, all the object versions that make up a Payroll application, or a screen form used in that application.

For example, when the development of individual objects reaches the stage where you can build a particular application, you need to specify exactly which version of each object is to be used for the build. The same applies when assembling a set of objects to be used for a test or included in a production release or a patch release - the configuration defines which versions of which objects are to be used.

When you create a configuration, you are its owner. You can subsequently transfer ownership to another user.

Configuration members

A specific object version that is included in a configuration is said to be a member of that configuration. Note that only those objects to which you have select access rights can be added to a configuration that you create.

Configuration members can be added or removed as and when required. However, only non-versioned or checked-in objects can be included in a configuration. Each configuration is a repository object in itself, and can therefore be placed under version control. Note that, if a configuration is under version control, only one version of the configuration can be checked out at a time.

Configuration Wizard

Oracle Repository provides a Configuration Wizard - a predefined set of screen forms that take you through the creation process step by step. Note that the repository owner must have assigned you the Configurations repository privilege before you can create configurations.

The Configuration Wizard allows you to create:

•	a new configuration

•	a new version of an existing configuration (containing, for example, all the latest object versions)

All external references (that is, references to objects currently outside the configuration) are displayed during the creation process. You can include externally-referenced object versions into your configuration.

When you have completed your new configuration or new configuration version you can either save the configuration only, or save it and check it in to version control. You can add checkin notes and specify a checkin branch.

If you choose only to save the configuration you can edit it later without creating a new version.

New configurations

You can choose to create:

•	a configuration based on a specification file (sometimes known as a template file) containing rules or other configurations

•	a configuration based on the contents of a workarea

•	a configuration based on the latest versions of objects on a specific branch

•	a custom configuration

You can then add, remove or change the version of members as required.

You can create a configuration from a specification file containing rules, other configurations or both. Specification files have the default extension .CWS.

If you choose to create the configuration from a specification file, workarea or the latest versions on a branch, you can then refine the configuration by adding or removing members or changing the versions of members. You can also add or remove selected rules and configurations. Populating a configuration from a rule will only add those objects returned by the rule and to which you have access.

If you choose to create a custom configuration, you can do so either by specifying combinations of rules or other configurations (or both), or you can simply select individual objects or object versions from the repository.

New versions of existing configurations

When you create a new version of an existing configuration you have all the features that are available when creating a new configuration. That is, you can reinitialize the configuration from a template file, recreate it from a workarea or from the latest objects on a branch, or you can use the custom option to recreate it from rules and other configurations or by selecting individual objects.

In addition, you can:

•	refresh all existing members with the latest versions

•	refine the existing configuration membership as required


Example of a configuration

The following example shows a configuration consisting of a specific version of three different objects:

In this example, the configuration is represented by the thick line. The configuration includes version 1.1 of object A, version 1.0.1.1 of object B and version 1.1.1.0 of object C.

With Oracle Repository, each configuration is a repository object in itself, and can therefore itself be versioned, as this diagram shows:

Here, the configuration is named CONFIG_A. Version 1.0 of the configuration includes version 1.0 of objects A, B and C. At the time that CONFIG_A version 1.1 is created, there has been more development on object C than on the other two objects, with the result that object C is already at version 1.2. Thus version 1.1 of the configuration will include version 1.1 of both objects A and B, but version 1.2 of object C.

By the time that CONFIG_A version 1.2 is created, there has been further development on objects A and C, but not on object B. However, the latest version of object A (version 1.3) is still under development, so CONFIG_A version 1.2 includes the previous version of object A, together with the latest versions of objects B and C.


About repository rules

A workarea or configuration is defined by specifying one or more rules. These rules define which repository object versions are to be included in, or excluded from, the workarea or configuration to which the rules apply.

When you create or modify a workarea or configuration, you use the Workarea Wizard or Configuration Wizard to specify the rules you want to use. From the wizard you can:

•	define the rules directly on one of the pages of the wizard

•	identify a specification file or template file containing the rules you want to use About

In either case, the available rules for specifying a workarea or configuration are as follows. For detailed specifications of the rules and their formats, see the index entry for "repository rules" in the Command Line Tool Guide (available through the Start button menu.

Rule	Effect
EXCLUDE_FOLDER	Excludes all specified container versions and their contents
EXCLUDE_OBJECT	Excludes all specified object versions
FOLDER_LATEST_BEFORE	Includes the latest versions of all objects in the specified containers that were checked in before the specified date, and all container versions in the path
FOLDER_LATEST_BETWEEN	Includes the latest versions of all objects in the specified containers that were checked in between the specified dates, and all container versions in the path
FOLDER_LATEST_CONTENTS	Includes the latest versions of all objects in the specified container on the specified branch, and all container versions in the path
INCLUDE_CONFIG	Includes all the object versions defined by a configuration
INCLUDE_FOLDER	Includes the latest versions of all objects in the specified containers, and all container versions in the path
INCLUDE_OBJECT	Includes the latest or the specified version of the specified object, and all container versions in the path
LATEST	Includes the latest versions of all objects on the specified branch
LATEST_BEFORE	Includes the latest versions of all objects on the specified branch that were checked in before the specified date
LATEST_BETWEEN	Includes the latest versions of all objects on the specified branch that were checked in between the specified dates
LATEST_CONFIG_CONTENTS	Includes the latest versions of all the objects defined by the specified configuration
LATEST_DIAGRAM_CONTENTS	Includes the latest versions of all the objects on the specified branch that make up the specified diagram


About workarea and configuration specifications

Workareas and configurations are defined by specifications. A specification is a set of rules or configurations that define which object versions should be included and which excluded.

The rules are applied in order, starting with the first rule in the specification. Thus, for example, the first rule could include a whole range of objects, perhaps using an INCLUDE_FOLDER rule, and a subsequent rule could exclude specific objects using an EXCLUDE_OBJECT rule.

0	 When you are creating or editing a workarea or a configuration, one option is to create or recreate the workarea or configuration from a set of rules stored in a specification file. Each rule must be on a separate line in a specification file.

0	 A repository rule takes one of the following forms, depending on the rule:

0	 rule_name(object[=element_type][,parameters])

1	rule_name(branch_label[,parameters])

0	 where:

0	 rule_name identifies the rule, for example, INCLUDE_FOLDER or EXCLUDE_OBJECT.

0	 object is a version resolved name (that is, a name that includes a specific version label) which identifies a particular version of a repository object.

0	 element_type is the element type of the object.

0	 parameters are the various rule parameters, explained later in this topic.

1	branch_label identifies a particular checkin branch, where a rule requires this.

0	 List of available rules

Examples

The following are some examples of rules as they appear in a workarea specification:

INCLUDE_FOLDER(NF_HOLLYWOOD{1.2.1.1}=Folder)

EXCLUDE_OBJECT(NF_HOLLYWOOD{1.2.1.1}/REGION{1.1}=Domain)

0	FOLDER_LATEST_CONTENTS(NF_HOLLYWOOD{1.2.1.1}=Folder,fix06)

LATEST_BETWEEN(fix06,24-FEB-2000,19-APR-2000)

The INCLUDE_FOLDER rule includes in the workarea all the objects from version 1.2.1.1 of the folder named NF_HOLLYWOOD.

The EXCLUDE_OBJECT rule specifically excludes from the workarea version 1.1 of the domain named REGION.

FOLDER_LATEST_CONTENTS specifies that the workarea is to include the latest versions of all objects in version 1.2.1.1 of the NF_HOLLYWOOD folder on the checkin branch named fix06.

The LATEST_BETWEEN rule restricts the workarea to includes the latest versions of all objects on the checkin branch named fix06 that were checked in between 24 February 2000 and 19 April 2000.

Identifying objects in repository rules

0	 Objects are identified in rules using version resolved names, which include a version label that identifies a particular version of a repository object. Generally, the type of object can be specified in addition to the version resolved name by including an equal sign (=) and the element type of the object after the name.

0	 If any special characters are used in an object name, they must be preceded by a caret mark (^).

Dates in repository rules

0	 Some repository rules require dates to be included. Dates can be given in any of the following formats:

0	 DD-MON-YYYY

1	DD-MON-YYYY HH:MI:SS

0	 Examples:

0	 19-APR-2000

1	19-APR-2000 12:00:00


About policies

Related Topics

You can set repository-wide options that control certain aspects of:

•	version control

•	file naming (case sensitivity)

•	object dependencies

Version control policies

A user with the Set Policy repository privilege can impose restrictions on the following versioning features:

•	branching

•	version labeling

•	locking

Automatic branching

When an automatic branching policy is set, all checked-out objects will check in to the default checkin branch set for each workarea. This feature can help to ensure, for example, that specific development branches are not populated with new object versions at critical periods in development, for example during a build.

If a default checkin branch is not set for a workarea, object versions in that workarea will check in to the branch from which they were checked out, unless you specify a different branch during checkin.

Automatic version labeling

When automatic version labeling is set, the user is unable to specify a label for an object version on checkin; the repository automatically assigns a label. This feature ensures adherence to a system-specified format for object version labels.

Strict locking

When strict locking policy is applied, users are forced to lock objects on checkout. Because two or more users cannot apply locking to object versions on the same branch, a strict locking policy prevents concurrent development of object versions on the same branch.

Without a strict locking policy in force, a user can choose whether or not to lock an object on checkout. In this situation, locking does not prevent another user from checking out an unlocked copy of the same version. It only prevents that user from checking in onto the same branch until the locked version is checked in.

File naming policy

The case sensitive uniqueness policy ensures that case sensitivity is applied to the names of file system files and their containers when these are created in the repository. When the policy is in force, for example, you are able to create a file named 'MyFile' and a different one named 'myfile'. When the policy is inactive, these two files would be treated as the same file, so creation of the second one would not be allowed. The policy is inactive by default, so it must be explicitly activated.

This policy is of particular use for files that are uploaded from a UNIX server, where case sensitivity is a feature of file and directory names. About

Dependency policies

Further options control whether object dependency data, if any, is copied by default when repository objects are either versioned or copied. Dependency data is created by means of the Dependency Manager tool. In either case the default can be overridden at the time of the operation.


About security and access rights

Repository security is provided at the following levels:

•	repository access control

•	repository contents access control

•	event auditing and monitoring

Control of access to the repository

Access to the entire repository is controlled through the standard Oracle database access control features. Anyone wishing to use the repository must already have an account on the database where the repository resides. Only a user with database administrator (DBA) privileges can create user accounts on the database.

At the time the repository is installed, only the repository owner can access the repository. The repository owner can subsequently authorize other existing database users to access the repository.

Control of access to repository contents

It is possible to control a number of general security features on an individual user basis. The repository owner can assign each user a number of repository privileges. These privileges specify, for example, whether a particular user is allowed to create or delete workareas, containers or configurations. Other repository privileges specify whether a user can perform certain repository operations (such as setting policies or purging objects), or whether that user can use the various software tools that are supplied with Oracle Repository.

Access to a particular workarea, container or configuration is controlled by the user who owns that item. The user who creates a workarea, container or configuration is initially its owner. That user can grant or revoke access rights (for example, update or delete) for that item to or from themselves or another user. However, the owner of an item always retains administrate and select access rights to it.

A particular role with the name PUBLIC is predefined for use with access rights. Granting or revoking access rights on a workarea, container or configuration to or from PUBLIC enables you to grant or revoke those access rights to or from every repository user in a single operation.

The owner of a workarea, container or configuration can transfer ownership of that item to another repository user.

0	 A user may have access rights for a container. However, if that user does not also have access rights to a workarea in which that container is visible, the user will not be able to perform operations corresponding to those access rights on objects in the container.

Event auditing and monitoring

Each repository object has sets of audit properties, which record details such as the:

•	date when the object was created

•	date when the object was last changed

•	user who created the object

•	user who last changed the object

•	number of times that the object has been modified

There is a set of audit properties for the PAC element, and a set for each of its SAC elements, and these are maintained independently. Thus, for example, if you change the name of a column in a table definition, only the audit properties for the column are changed, not those for the table. Similarly, if you change the name of the table itself, the audit properties for the table are changed, but not those for the column. The values of the audit properties can be displayed by repository tools such as the Repository Object Navigator.

If an object is under version control, one of the repository tools (the Version Event Viewer) provides a comprehensive view of the change events that have occurred for that object.


About impact analysis

For many repository users, it is important to assess the impact on the rest of an application of changing one component - a process known as impact analysis. For example, developers could investigate how many applications use a particular Java method, and thus discover whether a change to the method would have a significant impact across the enterprise.

Oracle Repository provides the following tools that are useful for impact analysis:

•	Dependency Manager

•	Matrix Diagrammer

•	Repository Object Navigator

•	Repository Reports

The Dependency Manager enables you to create dependency analysis data about the relationships between certain types of repository object so that you can determine the potential effects of change. (You can also create the dependency analysis data from the Command Line Tool.) You can then use the Dependency Manager to view a graphical display of the dependency data. Thus, for example, you can see whether a particular object uses, or is used by, another object.

The Matrix Diagrammer is a general purpose cross-referencing tool that can be used to support project scoping, impact analysis, network planning and quality control. The Matrix Diagrammer can cross-reference, create and manipulate repository objects in the form of matrix diagrams. A matrix diagram consists of two (and in some cases three) axes, each displaying a different element type, and intersection cells, which indicate whether a relationship exists between two objects.

The Repository Object Navigator also shows details of the usage of one repository object by another, for example, the mapping of an entity to a particular table, or the use of a particular table column in a data bound item.

Some of the reports provided by the Repository Reports tool address the area of impact analysis. For example, you can run reports that highlight the impact of changing a column in a table definition, or reports which indicate the functions, modules or tables that use a particular entity definition.


About repository management tools

The information in the repository can be managed and controlled using the repository management tools.

For example, you can:

•	install a new repository, or migrate an existing one, using the Repository Administration Utility

•	create and maintain object definitions in the repository using the Repository Object Navigator

•	display or print information about the contents of the repository using Repository Reports

•	view the version history of a repository object using the Version History Viewer

•	view version event details for a repository object using the Version Event Viewer

•	compare and merge repository objects using the compare and merge utilities

•	assess the impact of changes to certain types of repository object using the Dependency Manager

•	create and show references between objects in the repository using the Matrix Diagrammer

•	perform a wide variety of repository tasks from a command-line interface provided by the Command Line Tool


About importing and exporting repository data

The import and export facilities of the Repository Object Navigator enable you to transfer the contents of workareas, containers or configurations from one repository to another.

You export data from the source repository to a file via a set of temporary repository tables known as the XT tables. You can then import the data from the file to the target repository, again via XT tables. Export and import are each handled by a wizard, a set of screen displays that simplifies the task of importing or exporting data.

Alternatively you can use the command line interface to perform these operations.

Note:	If you want to archive an entire repository, or move an entire repository to another machine, the repository owner must use the backup and restore feature of the Repository Administration Utility to do so.

You can transfer repository data in either of the following formats:

•	Oracle database export format

•	Repository Loader format

Oracle database export format

You can use this format when transferring data from one Oracle (or compatible) database to another. The data is exported to a file known as a dump file, which has the default extension .DMP.

In database format, you can choose to export an entire workarea or configuration, or one or more selected containers from a particular workarea.

A check is made during the export operation for external references. These occur when an object that is owned by one container has references to objects owned by a different container. If external references are found, you are asked how you want to process them.

Repository Loader format

You can use this format only when transferring data from one Oracle Repository installation to another. The data is exported to an ASCII text file in the Repository Loader format, which has the default extension .DAT.

In text format, you can export anything from an individual PAC or SAC element to the entire contents of a workarea.


About the Application Programming Interface (API)

Oracle Repository provides a published Application Programming Interface (API) to enable developers to write programs or design tools to interact directly with the repository contents. The API is implemented as a set of database views, PL/SQL packages, functions and procedures, and Java classes and methods.

The API is also fully extensible - users can define their own types of elements, properties and associations in addition to those provided as standard.

Repository views

We strongly recommend that user-written programs query repository data via the published views, rather than accessing the repository tables directly. This is because direct access to the tables could lead to corruption of the repository. The views provide a consistent interface, shielding programs from internal changes to the repository.

You can use the repository views to construct SQL queries on the repository contents. Doing so enables you, for example, to create custom reports on the repository data. Each element type has a view named CI_element_type so, for example, you can use the view CI_ENTITIES to query the entity definitions in the repository.

PL/SQL interfaces

The Repository API provides a number of PL/SQL packages, procedures and functions to enable PL/SQL programs to interact with the repository.

Element packages

Each element type has a PL/SQL package named CIOelement_type. You can use these packages to create, update, select, delete, copy and lock repository objects and (for a versioned repository) check objects in and out. Thus, for example, you can use the package CIOENTITY to create a new entity or delete an existing one.

As an example, a PL/SQL statement that calls the procedure to create an entity might look like this:

cioentity.ins (object_id in number, property_list in out cioentity.data);

Each of the CIO... packages contains the procedures ins (insert), sel (select), upd (update) and del (delete). Some element types can have additional operations performed on them, so their packages include extra procedures, such as check_in, check_out, copy or move.

The set of element packages together with the repository views are known collectively as the CASE Dictionary API (CDAPI).

Repository service functions and procedures

A number of functions and procedures are provided that enable a PL/SQL program to interact with various repository services, such as those handling workareas, containers, configurations, access rights and version control.

As an example, a PL/SQL statement that calls the function to create a new workarea might look like this:

jr_workarea.create_workarea (user_name in varchar2

, workarea_name in varchar2

0	, description in varchar2 default null

, kind in varchar2 default 'PRIVATE') return number;

Java interfaces

The Repository API also provides a limited number of Java classes and methods to enable Java applications to interact with the repository. There are Java classes and methods for:

•	comparing and merging repository objects

•	handling operating system files as repository objects (including upload, download and synchronization)

•	mapping operating system files and repository containers


About issuing repository commands from the command line

You can perform a wide variety of repository tasks using the command-line interface provided by the Command Line Tool. How

In this way, for example, a build manager could perform bulk operations on the repository, such as creating releases or individual workareas for entire teams.

Commands consist of a command name, parameters and options. In the following example:

lsfolder folder1 -s

the lsfolder command lists all the objects in the container named folder1. The -s option causes the list to include all sub-folders of folder1 as well.

Some of the operations you can perform from the command line are:

•	create workareas, containers, branches and configurations

•	check objects in and out

•	undo checkouts

•	synchronize the repository and the file system

•	delete workareas, containers, branches and configurations

•	list the contents of workareas, containers and configurations


About running repository tools from the command line

You can run the following repository tools from a command line prompt on a Windows workstation. How

•	Dependency Manager

•	Matrix Diagrammer

•	Repository Administration Utility

•	Repository Object Navigator

•	Repository Reports

•	Version Event Viewer

•	Version History Viewer


About loading and unloading from the command line

You can load and unload repository data via the command line using the batch version of the Repository Loader utility.

You can use the utility to transfer data from one repository to another, though both repositories must be at the same release level.

Using the unload feature you can generate a text file (with the default extension .DAT) to contain the definitions of the items you are unloading. You can unload specific objects, or user-defined sets of objects, which you identify by their repository ID numbers, or an entire containers or workareas, which you identify by name. Any associated objects are also fully unloaded.

Using the load feature you can load data from text files in insert mode, but not update mode (that is, you can add new objects but not overwrite existing ones). The text file must be in the required format (see the Repository Loader reference information). You can either load objects into an existing container or workarea, or load an entire container or workarea.

Running the utility from the command line

The Repository Loader utility is named CKLDBT61. When you run the utility you specify the following using command line options:

•	whether this is a load or an unload operation

•	the name of the container and workarea from which you are going to unload elements or into which you are going to load elements

•	the name of the text file to be created or used

•	for an unload, the repository IDs (IRIDs) of the objects to be unloaded; if you do not specify any IDs, the whole container is unloaded


Non-sharable objects

Most element types in Oracle Repository allow you to create object instances that can be referenced from a container other than their owning container. A reference of this kind is known as a shortcut, and is denoted in some tools by the [image] icon.

Those objects for which this type of reference is not possible are listed below. For reasons to do with the history of Oracle Repository, these are known as non-sharable objects. Note that, depending on the product you are using, not all of these element types may be available to you.

The non-sharable objects are:

•	Business functions

•	Business terminology

•	Data items

•	Diagrams

•	Events

•	Transformation mapping sets

•	User defined sets


About case sensitivity in file names

File names are case sensitive in UNIX file systems, but not in Windows file systems. This can lead to differences in behavior between the two types of file system for upload, synchronization, and download operations in the repository. These differences are highlighted later in this topic. We strongly recommend avoiding the situation where multiple files in the repository have the same (case insensitive) name.

When a file is created in the repository, either by an upload or as a result of synchronization, the file name is stored in the repository using the casing with which it was created in the file system. Windows users should note that files can be displayed in Windows Explorer with their names capitalized or with the extension hidden, depending on the display options selected.

Oracle Repository has a system-wide option (the File Naming policy) that controls whether a uniqueness check is performed when files are created in the repository. This option is inactive by default, and has the effects shown in the following paragraphs.

If the File Naming policy is active

If the File Naming policy is not active

If the File Naming policy is active

In the Repository Object Navigator, mapped file system files and directories that have different case sensitive names are displayed in the Navigator window.

Example:

•	repository folder fol1 is mapped to file system directory fol1

•	repository folder fol1 contains an uploaded file File1.txt

•	file system directory fol1 contains a file FILE1.TXT that has not yet been uploaded

•	both files are displayed in the Navigator window

On upload, if there is no file or folder with the same case sensitive name as the one specified, the file or folder is created in the repository. If a file or folder with the same case sensitive name already exists in the repository, it is overwritten with the file system copy if the overwrite option is selected.

Example

•	repository folder fol1 contains two files: file1.txt and File1.txt

•	file system directory fol1 contains one file: FiLe1.TxT

•	user performs upload to repository folder fol1, specifying all files

•	repository folder fol1 now contains three files:  file1.txt, File1.txt, and FiLe1.TxT

On synchronization, files and folders are synchronized only if there is an exact file name match. In the case of a Windows file system where more than one file or folder has the same case insensitive name, only one file or folder is synchronized, and a message is displayed to indicate that the other files or folders were ignored.

Example (UNIX file system)

•	repository folder fol1 contains two files: file1.txt and File1.txt

•	file system directory fol1 contains one file: FiLe1.TxT

•	user synchronizes fol1 with the “include files new to the repository” option

•	repository folder fol1 and file system directory fol1 now contain three files:  file1.txt, File1.txt, and FiLe1.TxT

Example (Windows file system)

•	repository folder fol1 contains two files: file1.txt and File1.txt

•	file system directory fol1 contains one file: FiLe1.TxT

•	user synchronizes fol1 with the “include files new to the repository” option

•	repository folder fol1 now contains three files:  file1.txt, File1.txt, and FiLe1.TxT

•	file system directory fol1 still contains only one file: FiLe1.TxT (the other two files cannot be downloaded to the file system without overwriting FiLe1.TxT)

On download, behavior again depends on the type of file system.

For a UNIX file system, a file or folder is downloaded if no exact match is found in the file system. If an exact match is found and the ‘overwrite changed files’ option is selected, the file or directory is overwritten.

For a Windows file system, the file or folder is downloaded if a case insensitive match is found in the file system. If downloading a folder and the ‘recurse into subdirectories’ option is selected, all folders with the same case insensitive name are downloaded to the same file system directory, as new file system directories with different case sensitive names cannot be created.

If the File Naming policy is not active

In the Repository Object Navigator, mapped file system files and directories that have a case insensitive match in the repository are not shown in the Navigator window.

Example:

•	repository folder fol1 is mapped to file system directory fol1

•	repository folder fol1 contains an uploaded file File1.txt

•	file system directory fol1 contains a file FILE1.TXT that has not yet been uploaded

•	only File1.txt is displayed in the Navigator window; FILE1.TXT is considered to be the same file as File1.txt, as it has the same case insensitive name

On upload, if there is no file or folder with the same case insensitive name as the one specified, the file or folder is created in the repository.

If a file or folder with the same case insensitive name already exists in the repository, it is overwritten with the file system copy if the overwrite option is selected.

If more than one file or folder with the same case insensitive name already exists in the repository, upload takes place to a case sensitive match if possible, otherwise to one of the case insensitive matches (the other matches are ignored).

Example

•	repository folder fol1 contains two files: file1.txt and File1.txt

•	file system directory fol1 contains one file: FiLe1.TxT

•	user performs upload to repository folder fol1, specifying all files

•	repository folder fol1 still contains two files: file1.txt and File1.txt

On synchronization, if a file or folder in the repository has the same case insensitive name as one on the file system, a synchronization takes place. If there are multiple case insensitive matches, only one file or folder is synchronized, and a message is displayed to indicate that the other files or folders were ignored.

Example

•	repository folder fol1 contains two files: file1.txt and File1.txt

•	file system directory fol1 contains one file: FiLe1.TxT

•	user synchronizes fol1 with the ‘include files new to the repository’ option

•	repository folder fol1 now contains two files: file1.txt (synchronized with FiLe1.TxT) and File1.txt (for which the message is displayed)

•	FiLe1.TxT is not renamed in the file system

On download, behavior depends on the type of file system.

For a UNIX file system, all files or directories of the same case insensitive name are created or overwritten in the file system as separate files. No attempt is made to make a case insensitive match in the file system.

For a Windows file system, a repository file or folder overwrites one in the file system with the same case insensitive name if the ‘overwrite changed files’ option is selected.