I also observe this issue. I guess this happens because rebasing without merging
something on the stream does not actually constitute a change on the stream and
hence no change to the respective branch type.

However, I believe it is relevant to catch such changes - if you perform builds
off a stream which is rebased in order to bring in new files, you would want
your build to trigger in order to include those new files in the build.

Unfortunately I have not found a command to extract such "changes". I would
guess that this could be accomplished by doing some monitoring on the foundation
baseline of a stream and triggering a build if it changes. If this is
implemented it should probably be an option the user can enable to avoid such
monitoring if you don't have to.

Assigning to me.

Not sure anything can be done about this without some really ugly hacking.
Opting for WONTFIX.

This is fixable, but you'll have to jump through a couple of hoops. The problem
is that when you change the foundation or recommended baseline for a
non-modifiable component, although CC will create a rebase activity for the
change, the rebase is actually a no-op. The only thing that gets changed is one
or another of the process variables attached to the stream object; this escapes
the lshistory check for 2 reasons; firstly, the change isn't actually to the
branch type; secondly, even though the change does appear in the stream history,
the event record will not state anything other than "changed variable PVAR_FOO"
(or whatever the variable is named), and not tell you what the actual change in
value is.

To resolve this, what you would need to do is, around the same time as the
lshistory, execute a lsstream -long on the stream object (cleartool lsstream
-long stream:WindowsForms_Int@\SHARED_PVOB, to use one example from a build
here), and parse the output of that command to get the foundation baselines used
for the non-modifiable components. Store that in a multidimensional array (one
axis for the component, one axis for the build #), and the compare values
against the last build. I have scripts that parse this output in perl; should
probably convert to java without too much frustration.

I would love to have this functionality within the plugin, on a personal note

I'm going to reopen this, recategorize it as an enhancement, and bump down the
priority to a P4 - I'll see if I can make a run at implementing that at some
point in the future.

CC'ing

I changed the changelog logic in order to include activities from rebase.

The change is currently in trunk.