date:20130610

[JIRA] [clearcase-ucm] (JENKINS-18279) Keep the snapshot update files in the workarea

2013-06-10 Thread mdeb...@gmail.com (JIRA)















































Marc De Boeck
 created  JENKINS-18279


Keep the snapshot update files in the workarea















Issue Type:


Improvement



Affects Versions:


current



Assignee:


Praqma Support



Components:


clearcase-ucm



Created:


11/Jun/13 6:56 AM



Description:


Before a new build is started, almost all view-private files are deleted from the view where the build is made.
t would be very helpful if the snapshot update files would never be deleted from the workarea. These files contain useful information, and represent also in a way the change set of that particular build. From the update file, a build manager also has access to the versiontree and properties of all updated elements.




Project:


Jenkins



Priority:


Major



Reporter:


Marc De Boeck

























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[JIRA] [clearcase-ucm] (JENKINS-18278) Change set is not correctly calculated after a rebase of the integration stream

2013-06-10 Thread mdeb...@gmail.com (JIRA)















































Marc De Boeck
 commented on  JENKINS-18278


Change set is not correctly calculated after a rebase of the integration stream















Here is an example of a perl script which calculates correctly the predecessor baseline:

($stream,@recbls) = split (' ',`cleartool lsstream -fmt "%Xn %[rec_bls]Xp" -cview`);
foreach (@recbls)
{
$component = `cleartool lsbl -fmt "%[component]Xp" $_`;
chomp( @BLs = `cleartool lsbl -fmt "%Xn\\n" -stream $stream -component $component` )
or next; # "No baselines for component $component in stream $stream\n";
system ('cleartool','diffbl','-baselines','-activities','-versions',# whatever opts you want, '-graphical' ?
(@BLs > 1 ?# was there a previous for the latest ?
'-predecessor' :# no, compare  foundation
$BLs[-2]),# yes, compare second latest
$BLs[-1]);# compare to latest
}




























This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira







-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[JIRA] [clearcase-ucm] (JENKINS-18278) Change set is not correctly calculated after a rebase of the integration stream

2013-06-10 Thread mdeb...@gmail.com (JIRA)

Marc De Boeck
created JENKINS-18278

Change set is not correctly calculated after a rebase of the integration stream

Issue Type:

Improvement

Affects Versions:

current

Assignee:

Praqma Support

Components:

clearcase-ucm

Created:

11/Jun/13 6:44 AM

Description:

The plugin executes the command “cleartool diffbl -pred” to calculate the differences between two consecutive job-runs. Unfortunately, the option -pred doesn’t always take the predecessor from the same stream. More specifically: when the foundation baseline has changed, it takes the new foundation baseline as predecessor, and thus the plugin calculates the difference between the latest baseline on the selected (integration) stream and the new foundation baseline.

See also the following thread on the ClearCase forum:
How to compare a baseline with its predecessor on the same stream

The consequence of this:

each time after a rebase of the "monitored" integration stream, it takes many hours before the plugin has calculated the difference between these two baselines (typically a few 1000 files different files in our case).
The reported difference is actually not what we are interested in. We just want the difference between the latest baseline on the integration stream (which results actually from the rebase), with the last but one baseline (typically just before the rebase).

Dave-Robinson from IBM has provided in his answer on the clearcase forum a small perl-script to illustrate how this can be achieved with cleartool commands, because there is not out-of-the-box ClearCase option to achieve this.

Proposed solution:
I propose to replace the option “-pred” with a calculation of baselines within the same stream (in case there is no previous baseline in the same stream, then comparison should be made with the foundation baseline). If you don’t want to change the current behaviour of the plugin, this could be switched on/off by means of a configuration parameter for the Jenkins plugin.

Project:

Jenkins

Priority:

Major

Reporter:

Marc De Boeck

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

78 matches

Mail list logo