Baseline concept confusion
Hello!
We're evaluating RTC 3.0 and we have some difficulties in understanding the concepts relating to component baselines. Accepting/delivering baselines through "pending changes" seems to work as expected - in the target stream, all changes are preserved and its component list is updated to reflect the new baselines. However - if I try to work with baselines directly in the stream editor (by clicking the "Add..." button and picking another baseline for a component that is already in the stream), the behaviour appears to be quite different and also depends on whether it's a stream or a workspace. It seems that: - In a workspace, I cannot switch baselines for a component with pending changes ("Cannot replace Component 'X', it has active change sets and force is false"). - In a workspace, switching baselines for a component (without pending changes) silently discards any unresolved changes related to that component. - In a stream, switching baselines for a component with pending changes silently discards all the stream's change sets related to that component. From that, I conclude that messing with component baselines in the stream editor can put you in serious trouble and is not something that you would normally do. Yet, the ability to do that is part of the default Team Configuration. If I remove those permissions, however, It seems that I'm also disabling the ability to deliver baselines safely to the stream through "pending changes" (I get a "You don't have permission to Save Stream " error). Additionally, baseline changes does not seem to respect the Team operational behaviour wrt Source Control/Deliver (server) Preconditions. Is there a rationale behind this behaviour? Best regards, Christer Palm |
5 answers
|
I guess my last question was answered in this thread created by Hampus: http://jazz.net/forums/viewtopic.php?t=14373
But we are still interested in your opinion about the rest of my findings. Best regards, Christer Palm |
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 21 '10, 11:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
As a general comment, whenever you "replace" a component in a
stream/workspace with some specified baseline, the system always stores your configuration immediately preceding the replace as a special "backup before replace" baseline in the baseline history of that stream/workspace, so you can always get back to that previous configuration. More comments below: On 12/7/2010 11:23 AM, cpalm wrote: ... If I try to work with baselines directly in the stream What client and what operation were you using to switch baselines? I've never gotten this message from the Eclipse client when I use the "Replace_With->Baseline" operation. - In a workspace, switching baselines for a component (without pending Same question on client/operation. When I use the Eclipse client, I always get a warning to the effect that "You have unresolved changes ... if you don't check them in first, you will lost them". - In a stream, switching baselines for a component with pending Yes, but you can always get that configuration back from the "backup-before-replace" baseline. From that, I conclude that messing with component baselines in the Because of the backup-before-replace baseline, you never get into serious trouble. Just restore the backup-before-replace baseline, and you are back to where you were before doing that operation. If I remove those permissions, however, It seems that I'm also Because of the presence of the backup-before-replace baseline safety-net, it is not considered more dangerous to deliver a baseline than it is to replace a baseline. Cheers, Geoff |
As a general comment, whenever you "replace" a component in a Aha OK, yes I can see the backup baseline now.
... If I try to work with baselines directly in the stream What client and what operation were you using to switch baselines? I've never gotten this message from the Eclipse client when I use the "Replace_With->Baseline" operation. It's the Eclipse client. The procedure is: 1. Double-click the Stream or the Workspace to bring up the Stream editor 2. Click the 'Add...' button in the Components pane 3. Click 'Next >' 4. Select a component already in the Stream/Workspace 5. Pick a baseline for that component 6. Answer 'Yes' to the question "The selected component 'X' is already present in this stream. OK to replace?" 7. Click 'Save' in the Stream editor Best regards, Christer Palm |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Dec 23 '10, 11:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Sure enough, I get that as well in a workspace where there are
non-completed (aka "open", aka "active") change sets in that workspace. I verified that I don't get this error when I perform the replace from the Pending Changes view. I agree that this operation should have consistent semantics in those views. But more seriously, I also verified that the replace baseline operation in the Workspace Editor will silently overwrite any Unresolved changes in that component (as you indicated). I've submitted defect 148543 ("The replace baseline operation in the Workspace editor will silently overwrite unresolved changes") for this problem, and in the Description, mentioned the inconsistent behavior WRT uncompleted change-sets, requesting that be made consistent. One question though ... you said you got this for streams also ... that I didn't understand, because you cannot deliver non-completed change-sets to a stream (the deliver will automatically complete any non-complete change sets). Are you sure you were able to generate this error message in streams, in additions to workspaces? Cheers, Geoff On 12/22/2010 6:38 AM, cpalm wrote: - In a workspace, I cannot switch baselines for a component with |
Sure enough, I get that as well in a workspace where there are OK. Question is, what would those semantics be? The thing is that Pending Changes does not As a side note, this means that although Pending Changes allows you to merge the change sets from two different baselines from different streams into a workspace, you'd get to a point where you always have an incoming baseline and you'd have to choose which one to keep and which one to throw away. But more seriously, I also verified that the replace baseline operation OK thanks! One question though ... you said you got this for streams also ... that Actually I didn't say that (or at least I didn't intend to). What I was trying to point out is the inconsistent behaviour when replacing the baseline in the Stream editor: - Workspace/unresolved change: Silently discarded (obviously not applicable to streams) - Workspace/change set: Error message, can't do that - Stream/change set: Silently discarded (though after beeing silently backed up by implicit baseline) Best Regards, Christer Palm |
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.