Hi VENKATA RAMARAO POTLAPALLI,
Central Repository is mainly used for Multi User Development like to share the ETL Code.
Multi-user development:
If you are using a central repository management system, allowing multiple
developers, each with their own local repository, to check in and check out
jobs, the development environment typically has the following characteristics:
It has a central repository and a number of local repositories.
• Multiple development environments get merged (via central repository
operations such as check in and check out) at times. When this occurs,
real owner names (used initially to import objects) must be later mapped
to a set of aliases shared among all users.
• The software preserves object history (versions and labels).
The instances share the same database type but may have different
versions and locales.
• Database objects may belong to different owners.
• Each instance has a unique database connection name, user name,
password, other connection properties, and owner mapping.
In the multi-user development scenario you must define aliases so that the
software can properly preserve the history for all objects in the shared
environment.
Porting jobs in a multi-user environment:
When porting jobs in a multi-user environment, consider these points:
• Use the Renaming table and function owner to consolidate object database
object owner names into aliases.
• Renaming occurs in local repositories. To rename the database objects
stored in the central repository, check out the datastore to a local
repository and apply the renaming tool in the local repository.
• If the objects to be renamed have dependent objects, the software
will ask you to check out the dependent objects.
• If all the dependent objects can be checked out, renaming will create
a new object that has the alias and delete the original object that has
the original owner name.
• If all the dependent objects cannot be checked out (data flows are
checked out by another user), the software displays a message, which
gives you the option to proceed or cancel the operation. If you cannot
check out some of the dependent objects, the renaming tool only
affects the flows that you can check out. After renaming, the original
object will co-exist with the new object. The number of flows affected
by the renaming process will affect the Usage and Where-Used
information in the Designer for both the original object and the new
object.
• You are responsible for checking in all the dependent objects that were
checked out during the owner renaming process. Checking in the new
objects does not automatically check in the dependent objects that were
checked out.
• The software does not delete original objects from the central repository
when you check in the new objects.
Use caution because checking in datastores and checking them out
as multi-user operations can override datastore configurations.
• Maintain the datastore configurations of all users by not overriding the
configurations they created. Instead, add a configuration and make it
your default configuration while working in your own environment.
• When your group completes the development phase, It is
recommended that the last developer delete the configurations that
apply to the development environments and add the configurations
that apply to the test or production environments.
Source: Multi User Development
Regards,
Akhilesh Kiran.