In Synergy, is it possible via CLI to check if a filename in a workarea has any parallel versions?

Share URL
 
Henrik's picture
Henrik asked on October 14, 2011 - 2:39pm | Replies (3).

I have a tool that checks out files and I want to check if there are any parallel versions before doing the actual check out in a workarea (e.g. d:\ccm_wa\test-1\test\dummy.txt) .

The idea I had was to run a query and check for is_hist_leaf().

But before that I need to get a unique "objectname" from the filename to feed to ccm query. I can get attributes from "ccm attr -s filename", but how can I get the unique objectname attribute from a filename?

Best regards
Henrik

Tags: 
configuration management
cm synergy

3 Answers

David Honey's picture

Hi Henrik,

You could perform a [i]Detect Membership Conflicts[/i]. This will report any unmerged parallels that are required to be merged according to the update properties of your project, and report on any cases where the object in the project is not the latest version as specified by the update properties of your project. There isn't a direct way of querying for parallels. Such a query would not consider whether any such parallels are relevant to the release stream you are working on. I believe that there used to be some contrib code, but that code relied on custom ACcent library code and that can only be used with the now obsolete and retired classic client.

Regards,
David.

Per Lundborg's picture

Henrik,

if you are to do a checkout, you should know the project's name and version, with this information you can do a a query on
recursive_is_member_of($project-$version,none) and name=$file_name -u -f %objectname
Now you have the 4-part-name that you can feed the follow up query. However, as David points out, you will still not know if the c/o is valid...

Consider:

1.0--\--2.0
\--1.1.1

Both 2.0 and 1.1.1 will return true on is_hist_leaf() and you are none the wiser.

So you need to either travel the historical relation backwards until you either come to is_hist_root() (ie no parallel) or to a point where has_successor returns more than one match, ie you have a branch...

David Honey's picture

Analysis of parallels really only make sense in the context of some release. Not all parallels need merging or are relevant. It's the update properties of a project that provides the appropriate context for determining which, if any, parallels are relevant.

For example, if in the example, versions 2.0 and 1.1.1 are for the same release, almost certainly they should be merged. However, what if version 2.0 is for release X and version 1.1.1 is for release Y. The situation is less clear. If release Y is a patch and X is a main release, then a merge is probably what's desired, unless some feature got redesigned in release X such that the patch change is no longer relevant. The update properties provides the extra information about whether, for some specific release, changes from releases X and Y are required. If so, that would be reported as a membership conflict, and the resolution of the conflict is to merge.

In the Synergy GUI, you can perform a Show Parallels on a task. In the Synergy CLI in 7.2 onwards, you can do the same thing in the CLI. Those will consider the parallel_exclude_rules setting, but I think it does not use update properties, and hence may report parallels that would not give rise to membership conflicts.

Regards,
David.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.