Proven Practice

IBM Cognos 8 Framework

Manager - Enabling a Multi-
Developer Environment
Product(s): IBM Cognos 8 Framework Manager
(MR2)
Area of Interest: Modeling
IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 2

Copyright
Copyright © 2008 Cognos ULC (formerly Cognos Incorporated). Cognos ULC
is an IBM Company. While every attempt has been made to ensure that the
information in this document is accurate and complete, some typographical
errors or technical inaccuracies may exist. Cognos does not accept
responsibility for any kind of loss resulting from the use of information
contained in this document. This document shows the publication date. The
information contained in this document is subject to change without notice.
Any improvements or changes to the information contained in this document
will be documented in subsequent editions. This document contains
proprietary information of Cognos. All rights are reserved. No part of this
document may be copied, photocopied, reproduced, stored in a retrieval
system, transmitted in any form or by any means, or translated into another
language without the prior written consent of Cognos. Cognos and the
Cognos logo are trademarks of Cognos ULC (formerly Cognos Incorporated)
in the United States and/or other countries. IBM and the IBM logo are
trademarks of International Business Machines Corporation in the United
States, or other countries, or both. All other names are trademarks or
registered trademarks of their respective companies. Information about
Cognos products can be found at www.cognos.com
This document is maintained by the Best Practices, Product and Technology
team. You can send comments, suggestions, and additions to
[email protected] .

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 3

Contents
1 INTRODUCTION ............................................................................................ 4
1.1 PURPOSE ................................................................................................................ 4
1.2 APPLICABILITY ......................................................................................................... 4
1.3 EXCLUSIONS AND EXCEPTIONS ..................................................................................... 4
2 METHODS FOR ENABLING THE MULTI-DEVELOPER ENVIRONMENT ........... 4
2.1 SEGMENTING AND LINKING FUNCTIONALITY..................................................................... 4
2.2 INTEGRATION WITH CVS AND MICROSOFT VISUAL SOURCESAFE ........................................... 4
3 SEGMENTING AND LINKING......................................................................... 4
3.1 LIMITATIONS OF SEGMENTING AND LINKING PROJECTS....................................................... 4
3.2 LEVERAGING A READ-ONLY PROJECT ............................................................................. 5
3.3 SCENARIO ONE – HUB/SPOKE...................................................................................... 5
3.3.1 Enabling the Hub/Spoke Environment .................................................................... 6
3.4 SCENARIO TWO – FUNCTIONAL AREA RESTRICTED METADATA ............................................. 8
3.4.1 Enabling the Functional Area Specific Metadata Environment ................................... 9
3.5 SCENARIO THREE – DISTRIBUTION BY LAYERS ............................................................... 11
3.5.1 Enabling the Distribution by Layers Approach ....................................................... 13
4 FRAMEWORK MANAGER REPOSITORY CONTROL FUNCTIONALITY .......... 16
4.1 INSTALL AND SETUP OF THE REPOSITORY FEATURE ......................................................... 16
4.1.1 The IBM Cognos Configuration Tool ..................................................................... 16
4.2 CREATE A REPOSITORY USING VISUAL SOURCESAFE ........................................................ 18
4.3 CONFIGURING A VSS REPOSITORY IN FRAMEWORK MANAGER ............................................ 18
4.4 CREATE A REPOSITORY USING CVS............................................................................. 19
4.5 CONFIGURING A CVS REPOSITORY IN FRAMEWORK MANAGER ............................................ 19
5 BEST PRACTICES FOR SEGMENTING AND LINKING PROJECTS ................. 20
5.1 USING THE REPOSITORY WITH SEGMENTED PROJECTS...................................................... 20
5.1.1 How to Create a Segmented Project in a Repository.............................................. 20
5.1.2 Procedure for Adding or Deleting a Segment in a Repository Project ...................... 22
5.1.3 Adding an Already Segmented Project to a Repository........................................... 23
5.1.4 Working with Segments with Multiple Users.......................................................... 24
5.1.5 Opening a Segment as a Separate Project ............................................................ 25
5.1.6 Upgrading Segmented and Linked Projects ........................................................... 25
5.1.7 Using the Revision History Feature ....................................................................... 25
5.1.8 Using the Synchronize Command with a Repository Project ................................... 26

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 4

1 Introduction
1.1 Purpose
This document describes the existing functionality in Framework Manager for
enabling a robust multi-developer environment. Choose the method, or
combination of the methods, that best match the required environment as
defined by your development efforts.

1.2 Applicability
This document is applicable to IBM Cognos 8 Framework Manager MR2.

1.3 Exclusions and Exceptions

Details regarding any possible exceptions or caveats that may be
encountered during the implementation of the below will be identified with a
NOTE.

2 Methods for enabling the multi-developer environment

2.1 Segmenting and Linking Functionality
Segmenting helps divide large models into smaller easier to manage sections.
It enables many developers to effectively build their respective portion of the
model in isolation from other project development. Linking projects allows
multiple developers to reference shared metadata elements, while protecting
those common elements from unwanted changes.

2.2 Integration with CVS and Microsoft Visual SourceSafe

Use CVS or VSS for repository control to manage projects, control versions,
enable file recovery, and provide multiple developers access to the latest
changes of any Framework Manager projects.

3 Segmenting and Linking

Use Framework Manager to create and link: segments, projects and folders.
In conjunction with repository control, Segmenting and Linking provide both
an effective means to protecting your code while enabling an adaptable
multi-developer environment. Projects designed to enable multi-developer
modeling, are usually driven by a few key development requirements of the
organization.
NOTE: Segments or links are granular to the namespace level. For instance,
query subjects within a namespace can not be segmented on their own.
Two common scenarios where you may find segmenting and linking
functionality useful are known as Hub and Spoke, and Distinct Development
Paths. There are different recommendations when using each approach.
Please also review the section later in this document called Best Practices
for Segmenting and Linking Projects.

3.1 Limitations of Segmenting and Linking Projects

Please note the following limitations:

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 5

You cannot change or test objects in a read-only linked segment.

Changes to a read-only segment can only be performed by a modeler
with write permission.

You cannot test objects in a segment or linked project if they refer to
objects that exist in an unavailable segment.

You cannot create new objects that are based on objects referencing
objects existing in an unavailable segment

3.2 Leveraging a Read-Only Project

You can make a read-only project available for other developers to leverage
while protecting the project from unwanted change.

Steps for setting up a read-only project:

1. Create a shared directory or shared network location that will host
the project that is to be protected.
2. Grant read-only access and remove other rights to the new
directory or network share for any developer or group leveraging
the project. This will allow the developer to read the files while
preventing modifications. Consult your operating system
documentation for details on creating, sharing, and securing
directories on a file system.

Note: Changing the properties of the project files to read-only, will not
achieve the desired result as users will still be able to overwrite the read-only
file if they are allowed write access to the files.

3.3 Scenario One – Hub/Spoke

Common metadata exists that should be shared by all functional areas of the
organization. This approach requires a central model containing a fully
modeled ‘Physical Layer’ that will be leveraged by multiple functional area
branch modelers.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 6

A central data modeler will generate a Root model, containing all the basic
elements for the functional areas they support. Functional area developers
enhance branch models linked to the Root, with functional area specific
information. The functional areas are allowed to view and use content from
the Root model but are not capable of changing that original root model. A
Read Only copy of the root model is made available to all functional areas.
This method allows for reuse and protection of the parent model metadata
against unsanctioned or accidental change by a functional area developer and
ensures consistency of the physical layer across all functional areas.
3.3.1 Enabling the Hub/Spoke Environment
1. In a shared resource create the following folder structure; create a shared
folder called Root.
2. Grant read/write access to your central data modeler responsible for
creating the physical layer in the Root model. Grant read-only access to
this share for all functional area modelers (i.e. Finance Developer).

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 7

3. Create one shared folder for each functional area (I.e. Sales Project,
Human Resources Project, and Finance Project). Grant read\write access
to the central data modeler. Grant read/write access for each functional
area modeler to their corresponding folder.

4. The central data modeler can now create a Root project in the Root folder
created in the first step. All required languages should be added, and a
complete physical layer should be defined.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 8

5. Each functional area model developer will create a new project and link to
the root model to expose the entire physical layer or specific
subset/namespace for further functional area specific development.

6. Each developer can now open their corresponding branch model to

complete development with functional area specific information. Business
packages may now be defined and published to IBM Cognos Connection.

3.4 Scenario Two – Functional Area Restricted Metadata

Multiple developers need to work concurrently on a project, but do not or
should not have access common or shared metadata. This requires a central
model to link and coordinate the restricted metadata from distributed models.
Functional Area modelers must not be able to see development by other
areas.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 9

3.4.1 Enabling the Functional Area Specific Metadata Environment

1. Create one folder for each functional area (I.e. Sales Project, Human
Resources Project, and Finance Project). Grant read\write access to the
central data modeler. Grant read/write access for each functional area
developer to their corresponding folder.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 10

2. The individual functional area owners can now import and model the
physical and business layers specific to their own functional area.
3. In a shared resource create a shared folder called Combined.
4. Grant read/write access to your central data modeler responsible for
creating the presentation layer in the Combined model. Optionally, grant
read-only access to this folder for all functional area modelers (i.e.
Finance Developer).

5. The central data modeler can now create a blank Combined project in the
Combined folder created in the first step with all the required languages.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 11

6. The central data modeler can now create one functional area project and
initial model structure for every functional area. Storing the correct
project in the correct functional area folders created in a previous step.
7. The central data modeler links each of the functional area models to the
Combined model, exposing only specific public portions of the physical or
business layer for that functional area.

8. The central data modeler can now define a presentation layer in the
Combined model that will format the publicly exposed metadata from the
functional areas for consumption by multiple functional area users. If
there are no common links between the functional areas then the
presentation layers can be defined in the functional area models.
9. The central data modeler can now create a package in the Combined
model that contains the multiple functional areas. This package can now
be published to IBM Cognos Connection.
10. Each developer can now open their corresponding model to complete or
update the functional area specific information. Business packages
published from the Combined model will reflect the changes made within
each functional area linked model.

3.5 Scenario Three – Distribution by Layers

Common metadata exists that should be shared by all functional areas of the
organization. Requirements as follows:

A physical model containing a fully modeled ‘Physical Layer’ to be

leveraged in the Development Layer model.

A development model linked to the physical model. This model will
contain a fully modeled ‘Development Layer’ to be leveraged in the
Business model.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 12

A business model linked to the physical model. This model will contain
a fully modeled ‘Business Layer’; where reporting packages may now
be defined and published for user consumption.

A central data modeler will generate a Physical Model, containing all the
basic elements of a Framework Manager best practice physical layer; to
support a second model called the Development Model.
The Development Model is linked back to the Physical Model and
contains all the elements required to support a third model called the
Business Model.
The Business Model is linked back to the Development Model and will
contain all the final elements required to create and publishes the reporting
packages to IBM Cognos Connection.
The Development modelers are allowed to view and use content from the
Physical Model but are not capable of changing that model. A Read Only
copy of the Physical Model is made available to Development Modelers.
The Business modelers are allowed to view and use content from the
Development Model but are not capable of changing that model. A Read
Only copy of the Development Model is made available to Business
modelers.
This method allows for reuse and protection of the physical/development
layer models metadata against unsanctioned or accidental change by second
and third stage modelers.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 13

3.5.1 Enabling the Distribution by Layers Approach

1. In a shared resource create the following folder structure; create a shared
folder called Physical.
2. Grant read/write access to this share to your central data modeler
responsible for creating the physical layer in the Physical Layer Model.
Grant read-only access to this share for all other developers.

3. Create one share for each successive layer (I.e. Development; and
Business).
4. Grant read\write access to the Development share to the modeler
responsible for creating the Development Layer model. Grant read access
to the Business Layer modeler to the Development share.
5. Grant read\write access to the Business share to the Business Layer
modeler.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 14

6. The central data modeler can now create a Physical Layer project in the
Physical share created in the first step. All languages are added, and a
complete physical layer is modeled.

7. The Development Layer modeler can now create a project and models a
complete development layer. Store the project in the correct share
created in a previous step. Note: Define all required project languages
before beginning your modeling.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 15

8. The Development Layer modeler links to the Physical Layer model,

thereby exposing the entire physical layer.
NOTE: you will not be capable of creating shortcuts off objects from the
linked physical layer. You will not be able to create relationships between
objects from the linked physical layer to new objects in the development
layer. Make use of model query subjects and create new relationships in
the development layer to work around these restrictions.

9. The Business Layer modeler can now create a project and models a
complete Business layer storing the project in the correct share created in
a previous step. Note: Define all required project languages before
beginning your modeling.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 16

10. The Business Layer modeler links to the Development Layer model,
thereby exposing the entire development and physical layer. (Note: you
will not be capable of creating shortcuts off these layers. Use model query
subjects instead )
11. Business packages may now be defined and published to IBM Cognos
Connection.

4 Framework Manager Repository Control Functionality

Using Framework Manager you can create a connection to a Visual
SourceSafe (VSS) or Concurrent Versions System (CVS) repository. Use
repository control to help manage your Framework Manager projects. Control
versions of a project to ensure that each version of a file is recoverable.
Ensure users in a large organization have access to the most recent changes
or versions of a project or segment. Add new or existing projects to the
repository. After connecting and adding your project to the repository you will
be able to check in\Check out projects, segments, or related child models. By
using this functionality, developers may get the latest version of a project, or
view project history without ever leaving the Framework Manager modeling
environment.

4.1 Install and Setup of the Repository Feature

4.1.1 The IBM Cognos Configuration Tool
In IBM Cognos Configuration define a group of Source Control System
properties to allow Framework Manager to locate an existing (local) source
control system. Framework Manager can connect to multiple source control
systems, although only connection to one type of source system can be
configured at a given time. Here are some tips for using the IBM Cognos
Configuration Tool to set up a repository system:

On the Explorer tab, select Environment | Source Control System

From the Edit menu, invoke New Resource | Source Control System…

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 17

Enter a name to identify the repository in Framework Manager. This

name is arbitrary, but should help the user identify the repository
system.

Select the repository type: CVS, or Visual SourceSafe.

Now you must identify the executable file to handle the repository.
For SourceSafe browse (using the little pencil icon on the right) to
identify where SourceSafe is installed, and select SS.EXE.
NOTE: Ensure that you do not select SSEXP.EXE by mistake.

For CVS, select the CVS executable file.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 18

4.2 Create a Repository Using Visual SourceSafe

If you use Visual SourceSafe as your repository, connect to it using your
Windows user name and password. When you open a project stored in Visual
SourceSafe, you can automatically log on using your Windows user name and
password
1. Start Visual SourceSafe Administrator.
2. From the Tools menu, click Create Database.
3. Specify where you want to create the database.
4. Select the New 6.0 Database Format check box, and click OK to
create the database.
5. From the Users menu, click Open SourceSafe Database.
6. Locate the srcsafe.ini file, and click Open.
7. You can choose to change the database name. Click OK.
8. Click the database you just created, and click Open.
9. A list of the users assigned to the database appears.
10. Ensure that a user with the same credentials as your Windows account
exists.
11. Tip: To add a user, from the User menu, click Add User and enter the
credentials of your Windows account.
12. From the Tools menu, click Options, and on the General tab, select the
Use network name for automatic user log in check box.
13. Close Visual SourceSafe Administrator.
14. Using a text editor, open the srcsafe.ini file, and type the following
command at the end of the file:
15. Update_No_Change=Update
16. This command ensures that the project is updated each time there is a
check in.
17. Save the srcsafe.ini file and close the editor.

4.3 Configuring a VSS Repository in Framework Manager

1. Start Framework Manager and, from the Welcome page, click
Repository, Connection Manager.
Tip: If you have Framework Manager open, from the Repository menu,
click Connection Manager.
2. 2. Click the New button.
3. In the Connection Name box, type a name for the connection.
4. In the Type list box, click SourceSafe://.
5. In the Settings window, click in the Value pane, and browse to the
location of the srcsafe.ini file.
Note: Do not include the filename of the srcsafe.ini filename in the
location.
6. Click Test.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 19

If you specified your path using a drive letter, you will be prompted to
replace it with a network (UNC) path. This is recommended if the
repository is to be shared with other computers. Press Yes to use the UNC
path, or press No to keep the drive letter.
7. Click OK.

4.4 Create a Repository Using CVS

You can use Concurrent Versions System (CVS) as a Framework Manager
repository.
Create a directory for the CVS repository. An example is:

C:\cvs_repository.

Create a subdirectory named CVSROOT. An example is:

C:\cvs_repository\CVSROOT.

4.5 Configuring a CVS Repository in Framework Manager

1. Start Framework Manager and, from the Welcome page, click
Repository, Connection Manager.
Tip: If you have Framework Manager open, from the Repository menu,
click Connection Manager.
2. Click the New button.
3. In the Connection Name box, type a name for the connection.
4. In the Type list box, click SCCS://.
5. In the Settings window, click in the Value pane, and browse to the
location of the repository.
Do not specify the CVSROOT in the path. The repository location must be
different from the location where the new project is stored.
An example is C:\cvs_repository.
6. Click Test.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 20

If you specified your path using a drive letter, you will be prompted to
replace it with a network (UNC) path. This is recommended if the
repository is to be shared with other computers.
7. Click OK.

5 Best Practices for Segmenting and Linking Projects

A segment is part of a single project, while a linked project may be shared by
multiple projects. Here are some basic rules for managing segments and
links:

A segment is owned by a Root project, and its project files will be

created in a sub-directory below it.
NOTE: If you want to rename the folder or namespace, this must be
done before converting it into a segment.

Create segments from the root project outwards. This means do not
convert a folder or namespace into a segment if it already contains a
segmented folder below it because the new model segment will be
created without references to other linked or model segments that
may be contained in the original folder or namespace.

A linked project is shared by other projects.
NOTE: Linked projects should not be created in a sub-directories
below the root project. Linked projects are not affected by the
Revision History feature, so repository actions must be done on them
by opening the linked project.

5.1 Using the Repository with Segmented Projects

5.1.1 How to Create a Segmented Project in a Repository
Segmented projects intended for a repository should be created as follows:

Use the “New Project” dialog to create a root project and add it to the
repository. The root project should remain checked out.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 21

Set up the desired folder structure.

Use the “Create Segment” dialog to create segments on the desired

namespaces and folders. If the segments are to be nested, always
work from the root project down. Check the “Add to Repository”
checkbox, and do not change the default “Connection” and “Location
in Repository” text strings.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 22

Check in the segments.

Check in the root project.
NOTE: The segment structure is not saved until the root project is
checked in, so do not let other users work on the project until you
have finished with these steps.
5.1.2 Procedure for Adding or Deleting a Segment in a Repository Project

Check out the root project.
NOTE: Segments can only be created by one user at a time from the
Root project.

If there is more than one segment level, also check out the project
where the new segment is being created

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 23

For example, a new segment is required under Segment One in the

above picture; so check out both the Root Project and Segment One
from the repository.

Create the new segment and add it to the repository; or alternatively
delete an existing segment.

Check in the new segment, and then check in each segment up the
hierarchy to the root project. Finally check in the root project.
NOTE: The segment structure is not saved until the root project is
checked in.

All other users should perform Get Latest Version after the root
segment has been checked in.
5.1.3 Adding an Already Segmented Project to a Repository

Add the root project to the repository, and keep it checked out.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 24

Add the segments to the repository, starting from the root and
working out.

Check in the segments from the outer ones and work toward the root
project.

The root project must then be checked in. The segment structure is
not saved until the root project is checked in.
5.1.4 Working with Segments with Multiple Users

A single user should be responsible for any changes to the segment
structure of the project (add or remove segments). See the
procedures described above. Multiple users may each check out their
own segment.
NOTE: There is no need to check out the root to work on a segment
(it is only required to create one).

When checking in, provide a clear comment, and start it with the
name of the segment. This will make the Revision History easier to
understand.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 25

5.1.5 Opening a Segment as a Separate Project

It is suggested that you do not make any changes to a segment when
opened as a project because those actions will not appear in the
Revision History of the root project. If a single Revision History is
required; it is a better practice for each modeler to open a copy of the
root project and then check out their respective segment only (not the
root).

If you do opening a segment as a separate project, ensure there are
no checked out segments below the segment, including the root.
NOTE: Do not create a nested segment inside your segment, because
this will not get recorded in the root segment.
5.1.6 Upgrading Segmented and Linked Projects
A project must be upgraded starting from the child segments, and proceed
toward the root project. A linked project must be upgraded before using any
projects that use that project. It is suggested that repository projects be
checked in before upgrade, but it is not necessary. Upgrade should be done
as follows:

Open each segment (if they are nested, start from the outermost
segment) as a separate project.

The Upgrade Model dialog will appear – press OK.

After the project opens, do File | Save. If the project was checked in,
you will be prompted to check it out. Press OK. Do not Check in the
segment.

After you have upgraded the root project, then you should check in
each of the segments, and finally check in the root project.
5.1.7 Using the Revision History Feature
The Revision History feature allows you to restore a repository project to a
previous revision. If the project contains segments, they are co-coordinated
with the root project.

Always select the root project before invoking Repository | View
History. You will be warned if you do not do this.

To revert to a previous version, all segments should be checked out,
perform the sync (not to be confused with the Synchronize command
found under the Project menu), and then check all segments in.
NOTE: You can revert to a previous version while all segments are
checked in, but you will not be able to check out to make further
changes.

Rather than synch to a version of a segment that had a segment
created in it, it is better to synch to the root version that was checked
in after the segment was created. You may get warning messages
that segments could not be found. If you accept these warnings, you
will get your project without these segments. The segments can be
restored by synching to a later version.
NOTE: When reverting to an earlier version, segments that were
created after that version are not deleted from disk; they are simply
no longer linked into the main project.

IBM Cognos Proprietary Information

IBM Cognos 8 Framework Manager - Enabling a Multi-Developer
Environment 26

Do not delete a segment, and then create a new one with the same
name. This may cause problems when tracking revision history.
5.1.8 Using the Synchronize Command with a Repository Project
NOTE: It is suggested you do not use the Synchronize command with
repository projects. If you do so, keep in mind the following:

After the Synchronize command is done, all repository information will
be removed from the project. You must manually remove the old
project from the repository, and then use Framework Manager to add
the project back into the repository. All revision history information
will be lost.

When adding segments to a repository project that will be
synchronized, do not use the feature on the Create Segment dialog
that adds the segment to a repository. You must first create the
segment, and then use the Add Project to Repository dialog instead.
Synchronize will fail if it is not done this way.

If you use the Revision History feature to revert to an earlier version,
the log files for the revisions that should be removed are not
deleted. Synchronize will execute these log files; therefore it will not
correctly reproduce the revision that it should.
NOTE: You will have to manually identify and remove log files to
make this work.

IBM Cognos Proprietary Information