Synergy: work area path created with _no_context_ entry

The trouble:

I’m trying to check out a new project and getting a complaint from the CCM that WA already exists, I think it’s because it tries to use the _no_context_ directory again.

What to do?

Here is the story:

The problem was with the project_subdir_template been set wrong. Instead of keywords it contained other symbols (%project_version_BA). As this keyword was not legal, the system replaced it withe the _no_context_ string.

The correct keywords are to be selected from the drop-down keywords list (Classic GUI) or set in the $HOME/.ccm.ini as following:

%dcm_delimiter

%delimiter

%optional_project_instance

%optional_project_instance_no_delim

%platform

%project_instance

%project_instance_no_delim

%project_name

%project_version

%project_version_no_delim

%release

\

And the default wa_path_template for our DBs is to be set as :

wa_path_template = %home/source

project_subdir_template = %project_name%delimiter%project_version

The _no_context_ entry in the workarea path usually indicates that the wa_path_template or the project_subdir_template contain a keyword which could not be resolved and thus has 'no context'.

The keywords need to be either valid text attributes of the project object or 'so-called' psuedo-attributes i.e. keywords defined in the keywords list in the Online Help.

OS environment variables are not necessarily defined keywords in the context of a Synergy project.

Important: the project_subdir_template must contain a keyword which makes the workarea for the particular version of the project unique. (eg %version will add the version string to the workarea path).

Show Synergy types and their content

- get hold of the type "ascii": ccm query -t attype -n ascii

- see the list of attributes for above: ccm attr -la @1ccm attr

- see the content of the attribute "cache_path_template" : ccm attr -s cache_path_template @1

Task is not required on CO anymore and failed to create objects, ci files and run update & synchronize

After an upgrade from 6.4 to 6.5 of one of our databases we now see that checking out a file does not requires associated task to be present (Linux client).

In other words we can check out a file when there is not task and it goes on without any warning.
This is different from the past behavior and we would like to change it back to have the task required on every check out.

Checked the type definitions and we do have the initial state for all basic types set to "working" and "Task required on state" also set to "working". I can not really see the reason why the new file being checked out is not associated with a task.

Windows clients works just fine - requires task as expected.

Also,
The update and object creation fail with the message:

“Create failed: Object of type ‘ascii’ is not allowed in work area”.

Additionally, following is reported:

$ ccm create c -task 18850 ccmtestfile.c
Warning: Error(s) detected in migrate rules:

Invalid type name, ascii
Do you need to use the Type Definition facility?
Line #8 (Auto#1) : MAP_FILE_TO_TYPE .*\.[Tt][Xx][Tt]$ ascii

Invalid type name, shsrc
Do you need to use the Type Definition facility?
Line #8 (Auto#2) : MAP_FILE_TO_TYPE .*\.sh$ shsrc

Invalid type name, c++
Do you need to use the Type Definition facility?
Line #8 (Auto#5) : MAP_FILE_TO_TYPE .*\.C$ c++

Invalid type name, csrc
Do you need to use the Type Definition facility?
Line #8 (Auto#6) : MAP_FILE_TO_TYPE .*\.c$ csrc

Invalid type name, incl
Do you need to use the Type Definition facility?
Line #8 (Auto#7) : MAP_FILE_TO_TYPE .*\.h$ incl

Invalid type name, lsrc
Do you need to use the Type Definition facility?
Line #8 (Auto#8) : MAP_FILE_TO_TYPE .*\.l$ lsrc

Invalid type name, ysrc
Do you need to use the Type Definition facility?
Line #8 (Auto#9) : MAP_FILE_TO_TYPE .*\.y$ ysrc

Too many errors. Error reporting stopped after 7 error reports.
Warning: Unexpected error(s) in default rules file:
/tmp/ccm/dbname/db/../lib/Unix/migrate.rul
Create failed: Object of type 'ascii' is not allowed in a work area.

Solution (came from vendor support):

Verify the value of wa_type for cvtype on ascii is set to "any".
Use the following commands in the ccm_admin role:

>ccm set role ccm_admin
>ccm query -t cvtype -n ascii
>ccm attr -s wa_type @

Check the value returned. If it is not "any", change it:

>ccm attr -m wa_type -v any @

Restart the sessions to see the effect.
------------------------------

For some reason the wa_type was set to sfs during the upgrade.
Once fixed with the attr command also the problems with the Update / Reconcile and Check In of new files seem to be solved.