snapshot deliver error
16 answers
Getting the following error message, when attempting to deliver snapshots to my stream and cannot find a solution.Can you provide the steps you performed to get this error? I'm not quite sure what you mean by delivering a snapshot. A snapshot will create baselines if necessary. Are you trying to deliver the baselines created by the snapshot?
Problems occurred running delivering baselines
Reason:
Can not update an item that has already been deleted from the configuration.
Config id = ; item id = ; item name = 'null'
Getting the following error message, when attempting to deliver snapshots to my stream and cannot find a solution.Can you provide the steps you performed to get this error? I'm not quite sure what you mean by delivering a snapshot. A snapshot will create baselines if necessary. Are you trying to deliver the baselines created by the snapshot?
Problems occurred running delivering baselines
Reason:
Can not update an item that has already been deleted from the configuration.
Config id = ; item id = ; item name = 'null'
After a build, I have a snapshot or a baseline waiting in my "Outgoing" Pending area. I right click on "Outgoing" and select deliver and I get that message.
Are you using the same workspace for your own development and the build? I would not recommend reusing a workspace like that.
How are the baselines from the build getting to the workspace you have loaded in Pending Changes?
Yes, I use the same id. been doing that for well over a year now. We have discussed creating a new user to handle builds. The baselines come to the pending changes on completion of the build. I am using the Jazz Build Engine. I don't take any action other then attempting to deliever the baseline. I am actually not sure what the net affect is of delivering the baselines, just been my practice.
Are you using the same workspace for your own development and the build? I would not recommend reusing a workspace like that.
How are the baselines from the build getting to the workspace you have loaded in Pending Changes?
Yes, I use the same id. been doing that for well over a year now. We have discussed creating a new user to handle builds. The baselines come to the pending changes on completion of the build. I am using the Jazz Build Engine. I don't take any action other then attempting to deliever the baseline. I am actually not sure what the net affect is of delivering the baselines, just been my practice.I don't know what can happen if you use the build workspace for non-build related tasks since the build will alter that workspace. It would be best to create a workspace just for the build.
Baselines are useful indicators for notable points in the component's history. It allows users to load configurations at those specific points. The build automatically creates these baselines if there are change sets after the last baseline. I would recommend creating a baseline before delivering to the stream that is used in the build. Then you wouldn't have to deliver the baselines back to the stream.
If you're a small team and only use one stream, you don't have to deliver the baselines created from the build. Then you may create baselines whenever you think is a notable moment (i.e. release/milestone/test build).
Baselines are good and can help users roll back to a certain point in time. It also speeds up comparing workspaces/streams if both have a common baseline (everything after the most recent common baseline would have any differences).
Using the same repository workspace for two different file areas is
almost always a bad idea. In particular, if the build is ever running
at the same time as you are doing development in your workspace, you are
at risk of making the build inconsistent. It's not a high risk, because
a build normally loads all the files it is going to use in the beginning
of the build, and commonly does not checkin new files during the build,
but there are cases where you can cause inconsistencies, and I predict
what you are seeing is an instance of one.
Cheers,
geoff
On 5/4/2011 3:23 PM, ashworth wrote:
almost always a bad idea. In particular, if the build is ever running
at the same time as you are doing development in your workspace, you are
at risk of making the build inconsistent. It's not a high risk, because
a build normally loads all the files it is going to use in the beginning
of the build, and commonly does not checkin new files during the build,
but there are cases where you can cause inconsistencies, and I predict
what you are seeing is an instance of one.
Cheers,
geoff
On 5/4/2011 3:23 PM, ashworth wrote:
tmokwrote:
Are you using the same workspace for your own development and the
build? I would not recommend reusing a workspace like that.
How are the baselines from the build getting to the workspace you
have loaded in Pending Changes?
Yes, I use the same id. been doing that for well over a year now.
We have discussed creating a new user to handle builds. The
baselines come to the pending changes on completion of the build. I
am using the Jazz Build Engine. I don't take any action other then
attempting to deliever the baseline. I am actually not sure what the
net affect is of delivering the baselines, just been my practice.
Are you using the same workspace for your own development and the build? I would not recommend reusing a workspace like that.
How are the baselines from the build getting to the workspace you have loaded in Pending Changes?
Yes, I use the same id. been doing that for well over a year now. We have discussed creating a new user to handle builds. The baselines come to the pending changes on completion of the build. I am using the Jazz Build Engine. I don't take any action other then attempting to deliever the baseline. I am actually not sure what the net affect is of delivering the baselines, just been my practice.I don't know what can happen if you use the build workspace for non-build related tasks since the build will alter that workspace. It would be best to create a workspace just for the build.
Baselines are useful indicators for notable points in the component's history. It allows users to load configurations at those specific points. The build automatically creates these baselines if there are change sets after the last baseline. I would recommend creating a baseline before delivering to the stream that is used in the build. Then you wouldn't have to deliver the baselines back to the stream.
If you're a small team and only use one stream, you don't have to deliver the baselines created from the build. Then you may create baselines whenever you think is a notable moment (i.e. release/milestone/test build).
Baselines are good and can help users roll back to a certain point in time. It also speeds up comparing workspaces/streams if both have a common baseline (everything after the most recent common baseline would have any differences).
This makes sense, so I've created a new repository workspace, but now what do I do with these baselines that I cannot deliver? I would not call them milestones of any kind and as long as they dont impact the stream I dont really care what happens to them, but my deliveries stopped working last friday, so I'd like to get this working again for comfort on my part. My development system gets built every hour, should I disable the creation of a baseline for every hour? Thanks for you responses.
You don't have to deliver those baselines. Maybe someone more familiar with how builds work can chime in on the errors that could occur if you load the build workspace and use it for other tasks. My guess is the build's component is completely replaced with the new baseline. It doesn't have the old baseline and your client view is out of sync. If you refresh, you might see that the baseline is gone or replaced with the build's new baseline.
I wouldn't worry about not being able to deliver it. Your stream still has the change sets that you've delivered. Did you create a new workspace for the build or a new workspace for you to use for development? If you're using the workspace that was used for the build then you can replace the component with the latest from stream (you may want to suspend any outgoing change sets). Or you could create a new development workspace for yourself. It's ok for users to create and use more than one workspace.
I wouldn't worry about not being able to deliver it. Your stream still has the change sets that you've delivered. Did you create a new workspace for the build or a new workspace for you to use for development? If you're using the workspace that was used for the build then you can replace the component with the latest from stream (you may want to suspend any outgoing change sets). Or you could create a new development workspace for yourself. It's ok for users to create and use more than one workspace.
page 1of 1 pagesof 2 pages