Auto create a snapshot after Deliver occurs Error
Di Tang (44●1●8●13)
| asked Jan 12 '13, 1:30 a.m.
edited Jan 12 '13, 11:11 a.m. by Ralph Schoon (63.6k●3●36●46)
Hello!
IScmService scm = getService(IScmService.class);
WorkspaceItemListResult result = scm.createBaselineSet(destWorkspace, new IComponentHandle[0],
now.toString(), now.toString() + "SnapShot", true,
null, null, null);
The code running without exception in my operation participant but an error occurs in Eclipse which show in following picture:
I think the reason why this error occurs is I have modified stream(create snapshot) before the change sets really delivered to it, but I have no idea how to fix or avoid it.
Is there any solution? I will be very appreciate!
showing 5 of 14
show 9 more comments
|
3 answers
SCM uses SaveItemInTxn and RepositoryTransactionContext. This means that there are 3 layers of delayed writes. Writing any kind of code that runs after an SCM write operation is very difficult and I am not sure that we intend to support that at all.
Comments
Di Tang
commented Jan 14 '13, 8:46 p.m.
0_0' Thank you for your reply, and is there any way to do that? |
Hi Ralph,
I understand why the development team design the advisor and participant like what you say, and thank you for your
Or, is there any way to add my transaction (create snapshot) to the system transaction queue in participant?
|
@Di Tang any update on this ?? did you resolved the above stale data error ? if yes can you tell me how you resolved, i have also slimier error |
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.
Comments
Are you sure you have written a participant (that runs after the operation)? The behavior would be understandable if you have an Advisor (that runs before the operation is performed). Is this a client or a server extension?
Well, I'm sure I have written a participant that runs after the deliver operation and the behavior is really strange. My extension is server-side and the server is RTC 3.0.1.3.
I have forwarded this question to people who know more than I do. You could look at https://jazz.net/wiki/bin/view/Main/CustomPreconditionsTable#operations and try one of the other operations. There are several stages in scm. I know that SCM is a bit different, which could explain your error. However, I have written several participants for work item save operations that work. You can find example code at http://rsjazz.wordpress.com.
One example is: http://rsjazz.wordpress.com/2012/11/30/a-create-approval-work-item-save-participant/ you have to make sure to resolve the latest state of the work item to be able to modify it.
You might need to go through Hong Kong to get at the blog.
We have seen http://rsjazz.wordpress.com.nyud.net/ is accessible through Hong Kong.
I can not comment on why officials in China have chosen to block wordpress. I can see that it (still) can be reached through Hong Kong. You can look at the code of the post here: http://dl.dropbox.com/u/12668004/CreateApprovalParticipant/20121130_CreateApprovalParticipants.zip
The key is this code piece
You need to get the latest state of the work item first, get a working copy and manipulate that.
For the modification of the delivery, I can't tell if that is possible or not.
I think I understand the participant behavior of save work item now. Thank you for your reminder.
As I see it, both an advisor as well as a participant run before the transaction is finally committed, because the advisor as well as the participant need to be able to block the transaction to be finalized in case they detect an error.
I don't know what exactly you mean, all kind of operation advisor and participant or just only deliver operation advisor and participant?
Hi Di,
I meant all advisors and participants. In the workitem save participant you are actually causing a new save operation as a by product. in saveWorkItem3() you can actually pass a string to, for instance, detect that the same participant is triggered by the additional modification, which prevents you from ungracefully dying in a recursion....
Other paricipants would for example start a build and prevent saving the work item if that is not possible like in the extensions workshop.
HI Ralph,
I don't know how all that is implemented. I can just say from what I have been seeing. I would assume all the operations are run in a certain context that keeps together what happens. The second save would then issue a new save operation that is queued after the current one and isolates the changes. I could imagine that the second save could be cancelled if the first one is canceled in a later step.
The infrastructure has to isolate and manage multiple concurrent operations, so some framework is involved, that handles the database transactions.
Thank you for the explanation, I think you are right.
The other way around. You are not supposed to/should not modify the work item in the advisor. The class implementing the advisor does assume you don't. See http://rsjazz.wordpress.com/2012/12/14/do-not-modify-the-triggering-element-in-an-operationadvisor/
/**
* Operation advisors are run before an operation is invoked to decide whether
* or not the operation should be executed. Advisors check conditions and
* report problems via the collector they are given. If an advisor reports a
* serious problem with an operation, the operation will not be executed (though
* subsequent advisors may still be checked).
*
You could modify e.g. a work item in an advisor today and you would even not have to save it. This would also, today, not cause an additional call to work item advisors.
In the future the extension point might track that and prevent you from doing it. Today it does not.