Q: Is it possible have two Informix dbs under same name on a single server (in different locations)?

A: No, it is not.

No matter how we call it - (mydb or /data/synergydb/mydb) it will all be the same.

Trouble starting Synergy session

Warning provided to user when starting synergy client session:

Duplicate user name: 'john'
Warning: Syntax error(s) in attribute 'users' of base/model/base/1.
Starting in multiple server mode.
Set the environment variable CCM_ADDR to serv:32920:123.321.231.213 to send commands to this server.
SYNERGY/CM address is serv:32920:123.321.231.213.

Solution: run "ccm users" and remove the extra occurence of the problematic user ('john').

How To Fix: recreate accidentally removed prep project (original project version exists, successor working project exists) (work)

1. Create new project for Integration Testing purpose.

To do this: copy project from existing Working Project (myproj#john-2.00.00:project:1). Make sure new project has the same release as the working project and the correct version name and purpose.

The project is created but the status is working. We will change this later.

2. List all three projects to see their full object names:

$ ccm query -type project -name myproj -f "%objectname"
1) myproj#1.00.00:project:1
2) myproj#2.00.00:project:1
3) myproj#john-2.00.00:project:1

3. Now fix the relations of the projects. We shall get the project 2.00.00 as a successor of 1.00.00, and then 2.00.00-john as a successor of 2.00.00.

First relate the projects as needed, then remove the old links:

$ ccm relate -n successor -f myproj#1.00.00:project:1 -t myproj#2.00.00:project:1
'successor' relationship created from 'myproj#1.00.00:project:1' to 'myproj#2.00.00:project:1'

$ ccm relate -n successor -f myproj#2.00.00:project:1 -t myproj#john-2.00.00:project:1
'successor' relationship created from 'myproj#2.00.00:project:1' to 'myproj#john-2.00.00:project:1'

$ ccm unrelate -n successor -f myproj#john-2.00.00:project:1 -t myproj#2.00.00:project:1
'successor' relationship deleted from 'myproj#john-2.00.00:project:1' to 'myproj#2.00.00:project:1'
$ ccm unrelate -n successor -f myproj#1.00.00:project:1 -t myproj#john-2.00.00:project:1
'successor' relationship deleted from 'myproj#1.00.00:project:1' to 'myproj#john-2.00.00:project:1'

4. Check the Integration Testing project status:

$ ccm attr -s status myproj#2.00.00:project:1
working

It should be prep, not working. (Working was inherited from the original working project it was copied from).

5. Change the status attribute:

Note that to change the status we should clear the 'Make Copies Modifiable' property of the project work area as suggested:

$ ccm attr -m status -v prep myproj#2.00.00:project:1
Check in to prep state not permitted for projects with 'Make Copies Modifiable' work area setting.
Attribute 'status' could not be modified on object 'myproj#2.00.00:project:1'

$ ccm attr -m status -v prep myproj#2.00.00:project:1

Status has been now changed to prep, no output is produced by command ccm attr.

~~~ End of story ~~~

redirect STDOUT and STDERR to the same file

> logfile 2>&1

Q: Unbounded file-versions are related to project? [ ref:00D2nW4.500224kaq:ref ]

Q: We've discovered a number of files that are not bounded (as reported by finduse command), yet they are marked as belonging to a project. This looks like inconsistency. Is such a situation normal or should we worry about this state?

Here is an example:

ccm finduse -name con_chk.o
con_chk.o#1 integrate john relocatable_obj MYAPP 1 1871
Object is not used in scope.

A: This is the project it was originally created in. There is no other relation. For a file that is used in a project, you will get a list of locations it is at.

Concept of Synergy collapse command is problematic

The collapse command enables you to delete object versions from the database and adjust history links. You use this command when the object you delete has successors. All collapsed objects are removed from the database. If you collapse a project, its members are unused and the project is removed.

Note Before you check in a working version to a non-modifiable state, be sure to collapse the earlier checkpointed versions you do not want in your database; otherwise, you will only be able to collapse the checkpointed versions while working in the ccm_admin role.

The immediate successor of a checkpointed version must be writable to collapse the predecessor. For example, assume you have an object named bufcolor.c with a version history of: 1 --> 2 --> 3 --> 4, where version 1 is in the integrate state, versions 2 and 3 are checkpointed versions, and version 4 is in the working state. If you want to collapse version 3, you can do so because version 4 is in the working state. If version 4 was in the integrate state, you would not be able to collapse version 3.

You can perform a collapse command on a specified object except when the object has either of the following characteristics:

• the object is non-modifiable and you are not working in the ccm_admin role

• the object is a member of a project

Note Collapsing a version that has multiple successors and predecessors links each of the version’s predecessors with each of the version’s successors. Collapsing a version that has no predecessors and multiple successors unlinks the successors’ histories.

All users can collapse objects to which they have write access.

Users working in the ccm_admin role can collapse non-modifiable objects as well.

As a matter of fact this command kind of breaks the very idea of the Synergy/CM - Task-Based CM:

Synergy/CM defines a release as a collection of tasks. It is content of this collection (and not the content of the code line) that defines what goes into release and what does not.

When an object is collapsed, this is done outside of the tasks. The operation does not require any task to perform. Thus the release content is changed without any trace left.

Change propagation is task-based as well. So if at any time we would want to propagate the specific change (task) to another version, we may propagate the incomplete change - without the collapsed object and without knowing something is missing.

And if for some reason we'll ever look at the release tasks, we'll see some empty tasks (those that held the only file that was collapsed). We'll then wonder what's the point of having an empty tasks to change the code.

Hence it does look like the collapse operation is only acceptable for non-source files, e.g. shared build products.

Synergy and CBD (citation)

by Greg Fischer
We are doing component development where I work, and have been for a few years.

To answer some of your questions:
Synergy deals with components very well, if you set it up correctly in the very beginning. Otherwise yes, there will be alot of overhead. (I'll come back to this).

You can easily reach a point where you have too many components. But, it is manageable again, if you set it up correctly to start. Yes, you will have a different release for each component project, and that would be your biggest headache, as you would have to determine if the releases change together at major milestones or separately.

You basically have three ways to implement this. Let's say Application A requires components B and C. You need the build products from B and C to build A. So, within project A, you can:

1> Have a directory named "Components" for example, with maybe subdirectories for B and C, and your reconfigure properties will include task folders to provide you with the latest B and C products and any other B and C files you need.

2> You have an absolute project which contains all possible required components for everybody, and this absolute project is then a subproject for Project A and any other projects that need it. On Windows, your users would then check out the Components common project, along with Project A, then map a network drive (pick a standard - everybody uses Q:) to map the top-level directory of your workarea for the Components project. Then any reference to files needed by Project A would be Q:\components\componentB\B1.dll, etc.

3> The components directory under Project A "uses" integrate projects as part of the baseline for the dependent components. This has the added advantage of having the build manager be able to NOT select the latest baseline for a component in their baseline, or having the developers go back a baseline (or two or X number) to help in bug fixes.

We started doing 1> here, but that gets messy, because Project A is now collecting tasks for Components B and C, and the number of tasks in the baseline just gets bigger and bigger and bigger (and quickly).

I've done 2> in my career, with Synergy, with great success. The one problem with 2> is that people will tend to check out the *entire* Components absolute project, thereby getting components A through Z, when all they need is B and C.

We're just in the process of implementing 3> now, and so far, so good. Synergy treats "integrate" projects special, so you can have it "relative" to many other projects, but because it is in the "integrate" state, Synergy allows this, AND and Update won't bother with those - they are static.

So the initial setup of your projects will be key, but Synergy can definitely handle it.
http://www.cmcrossroads.com/component/option,com_fireboard/Itemid,558/func,view/id,83799/catid,24/
Greg Fischer

How To Fix: Synergy project is locked

Sometimes when the client session terminates in the middle of the operation (e.g. reconfigure), the project is locked and is not accessible from the new GUI session.

To solve this: locate all the user sessions via ccm monitor and kill them.

How To: list project reconfigure folders

Here is the way to list all the reconfigure folders for a specific project:

ccm reconfigure_properties -show folders <project properties>

For example:

$ ccm reconfigure_properties -show folders PROD#verb8.18.19:project:1
1) Folder 24630: All Completed Tasks for Release ABC_3.07
2) Folder 26646: All Completed Tasks for Release CBGTR_6.01
3) Folder 27144: All Completed Tasks for Release OIUY_6.04
4) Folder 27527: All Completed Tasks for Release ZZZ_7.10
5) Folder 28060: All Completed Tasks for Release TYU_6.05

Synergy numbers

Telelogic support suggest projects should not have more than 2K objects for performance sake.

There used to be a reference to the source of this suggestion somewhere but no more.