Can we link it as a duplicate of JENKINS-7218?

I would say it is related, but not a duplicate.

The author seems to be interested in getting changes by label tracking instead, so in this case it duplicates JENKINS-7218. As for disabling lshistory it would be sufficient to disable SCM polling if it's not adequate. Am I missing something?

lshistory is used for two use cases :

• during polling to determine whether there are changes
• during the build in order to build the changelog

One possible solution for this would be to use the command 'cleartool find ${CLEARCASE_VIEWPATH}${load_rule_line} -cview -print' for each load rule entry, storing the output in some file that would be used for comparison between builds (checking for differences)

To get the changelog it would be possible using the similar command as in lshistory for each different line (full version extended path)

Example:
ct desc \
-fmt '\"%Nd\" \"%u\" \"%En\" \"%Vn\" \"%e\" \"%o\" \n%c\n' \
/Vobs/BETS/production_and_patches/windows_patch_framework/create_patch.pl@@/main/27
"20101021.140308" "scmbuild" "/Vobs/BETS/production_and_patches/windows_patch_framework/create_patch.pl" "/main/27" "create version" "checkin"

Implemented in hudson/master. Testing has mostly been done on UCM where you have 3 choices availbable (no history, current branch, branch + rebase), feel free to validate for Base.

After reading more of JENKINS-7218 It seems a good step in the right direction but I also would like to see changes on branch on some cases (mostly only build scripts). This covers 99% of code with it and I guess I could instate policy to have changes on the rest to also com by label.

Having a rather complex configspec with multiple branches and labels, the best solution would be to use lshistory as you are using (because it is very fast and using the -minor option really gets everything), instead of list all versions in current view with "cleartool find $loadRule -cview -print" and comparing outputs between builds.

I've tested this with version 1.3.5 and the log output does get a bit large some times (100Mb from a build not run over a month). I'll probably open a new Issue to better filter the output in log, to show only the relevant entries.

The "no history" option will come in handy because I have some chained jobs in clearcase views (compilation first in Solaris chained with more compilation and packaging on windows), so in the second job it saves time doing changelog that was already done in the first job.

Sorry, not sure how I managed to assign this to myself.