|
||||||||
|
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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
Hi Marc
I think you are right; using -nmerge is not really the solution to the original problem; Being that files show up more than once, due to being changed in several versions and in contributing activities (versions on different branches).
The phenomena "contributing activity" is only relevant when comparing two baselines on the same stream - in other words, in the context of the plugin it's only an issue in poll-self mode. In poll-child and poll-sibling, the changesets are showing correctly as is ...right?
I'm thinking of a possible solution to the original problem:
Could it be that we offer an option to use a "Washed Change Set" which should mean that
a) We only report versions, that are on the same stream (no contributing activities)
b) If an element is included in the activity in more than one version, we only report the newest
We could quite easy to do this, We could continue to use the currently generated output from the diffbl command, but then simply "wash" it before we display it - when the job runs in poll-self mode.
I didn't get this idea before you mentioned it, but actually it has anopter property which I like a lot: It would report a changeset, that is less ClearCase'ish and more like what you would expect to see from VCS such as SVN, Git and Mercurial.
We could simply make this feature an option (a checkbox), so old-school ClearCase nerds could continue to make sense out of the same element being represented more than once in the same change set - if they want to![]()
Let me know what you think?
Lars