team concert suspend baseline delivery
Is it possible to mark baselines / snapshots as "non-deliverable"?
We would like to control the construction of baselines / snapshots on our streams (we have several reasons for this). We can do this in the RTC process permissions settings and limit baseline and snapshot delivery to appropriate users. However, for all other users, this results in the accumulation of un-deliverable baselines created in thier workspaces. These continue to be reported indefinitely in their pending changes view which is annoying fluff. One solution is to prevent users from creating baselines too but this will seriously limit general users ability to record interim way points in thier work spaces. I'd prefer not to implement this as I firmly believe that the users need to tag thier code at salient points. Whilst these "personal tags" are vital to the user they are of limited use to everyone else on the programme and yet the default behaviour is to wantonly propagate all baselines to all users associated with the stream. What is missing from my point of view is some form of baseline scope, an ability to keep a baseline local to a workspace and differentiate it from a real project level baseline. A personal baseline/snapshot would not be listed it in the pending changes view and not delivered by default. I really hope this sort of function already exists but I can't find it ... is this a candidiate for an enhancement? |
2 answers
If you never intend to deliver the baselines then the discard a baseline story may be of interest: https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/18512
A workaround is to suspend/discard the latest change set in the baseline. The configuration's latest baseline becomes the previous one. Resume/accept the change set and the unwanted baseline will be gone. It still remains in the workspace's history so you can replace your component with it in the future. |
|
Thanks for the feedback and workarounds Tim.
Unfortuantely neither of these is really acceptable. Whilst simple in principle, this problem is going to be encountered by users on a regular basis which is going to impact productivity. I am wondering if I should raise this as a defect instead? This maybe expected behaviour when we switch off permissions to deliver baselines but it is far from elegant. The user recieves permissions error for every delivery after they create a baseline in thier workspace. Would it not be better for them to be prompted with "do you want to make this baseline as a personal, non-deliverable baseline?", a positive response would be for the baseline to be handle it like a suspended change set. Probably a better approach would be for baselines to be handled the same as snapshots and explictly promote them rather than assume they are to always be delivered (workitem 85458 looks like). Of course for backward compatability you might want to make this a boolean property on the workspace so that existing users see the same behaviour and those users who can not or do not want to deliver baselines can set the property once and no longer recieve annoying errors from their cluttered pending changes view. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.