Find all unmerged files/elements in ClearCase

Question

We use ClearCase where I work and I\'m trying to figure out how to find any files that have been modified but not merged up. We have a main branch at the very top level in

Answer 1

If you know the source and destination branches (topic detailed in Jonathan's answer, which I have upvoted), then don't forget the query primitive merge:

merge (from-location , to-location)

In all cases, TRUE if the element to which the object belongs has a merge hyperlink (default name: Merge) connecting the from-location and to-location.
You can specify either or both locations with a branch pathname or a version selector.
Specifying a branch produces TRUE if the merge hyperlink involves any version on that branch.
The branch pathname must be complete (for example, /main/rel2_bugfix, not rel2_bugfix).

This thread illustrates that query in action:

How is it possible to find all the elements on a specific branch that are checked in and not merged away?

cleartool find \\view\administration\ProjectVOB \
   -branch "brtype(HNH-372452) && \
   !merge(...\HNH-372452\LATEST,...\main-372452\LATEST)" -print

\\view\administration\ProjectVOB\Com-API\Dll\COMFrontendDll\Mmi.cpp@@\main\HNH-372452
\\view\administration\ProjectVOB\geometry\geochain\geocutterloc.cpp@@\main\HNH-372452

That "merge hyperlink" is the red arrow you see in version tree:
(see article "Versioning and parallel development of requirements")

Answer 2

Normally, you use ct findmerge to find files to merge from one branch or view into the current view (assuming ct is an alias for cleartool).

I think you would have to identify all the branches you are interested in and do a separate ct findmerge operation for each branch - for each destination branch. That's complex. You'd also want to be able to eliminate many branches which are known to be fully merged. You can annotate a branch to indicate that it is fully merged.

So, I don't think there is a simple, single command to do this job.

---

You need to decide which branches are targets that you're concerned about. These would be your integration branch(es). Presumably, you have a fairly small list of these.

For each of those target branches, you need to decide which work branches are relevant to that integration branch. This is the tricky part; there is no easy way to determine whether a particular bug fix or feature branch is relevant to that integration branch using information in the VOBs; it is really only known by the users.

You then need a script that does (in outline):

for int_branch in $(list_relevant_integration_branches)
do
    ...create view with tag $tag for $int_branch...
    ct setcs -f $(cspec_for_integration_branch $int_branch) $tag
    ct setview -exec "find_outstanding_merges_for_integration_branch $int_branch" $tag
done

where find_outstanding_merges_for_integration_branch looks a bit like:

vob_list=$(list_relevant_vobs)
for mrg_branch in $(list_relevant_merge_branches $int_branch)
do
    echo
    echo "Merges from $mrg_branch to $int_branch"
    ct findmerge $vob_list -fversion .../$mrg_branch/LATEST -print
done

Note that this command assumes (a) the current view is appropriate for the target, and (b) the integration branch name is passed as an argument.

You can get fancy and decide how to handle automatic or graphical merges instead of -print. The hard part is still the unwritten commands such as list_relevant_integration_branches and list_relevant_vobs. These might be simple:

# list_relevant_integration_branches
cat <<EOF
integration_branch_version_3_0
integration_branch_version_3_1
integration_branch_version_4_0
EOF

# list_relevant_vobs
cat <<EOF
/vobs/mainproject
/vobs/altproject
/vobs/universal
EOF

Or they might be considerably more complex. (If you only have one VOB, then your life is much simpler; the systems we work with have 20-odd VOBs visible in the cspec.)

The other unwritten script is list_relevant_merge_branches. I don't know whether there's a simple way to write that. If you define and apply appropriate attribute types (ct mkattype, ct mkattr) when the development branches are created (perhaps a 'target integration branch' attribute type, an enumeration type), you could use that to guide you. That leaves you with a retrofit problem; how to get the correct attribute onto each existing working branch. You also need a separate attribute to identify branches that no longer need merge scrutiny, unless you decide that the absence of a 'target integration branch' attribute means 'no need to scrutinize any more'. That reduces the retrofit problem to adding the target integration branch to those branches that still need merging; by default, all existing branches will be deemed fully merged.