If I deliver a change set to a stream and not associate it with a work item can the change set be associated with a work item after it has been delivered ?
Yes.
The changeset itself is closed upon delivery to the stream.
But its associated work-item(s) is not: you can add or remove one or several work-items in association with the delivered changeset.
That being said, I have a special hook which makes that association mandatory on deliver: ie, you cannot deliver without having first associated your change set first to a Work Item.
I am not sure if that hook is a custom one for my organization, but here is where you can check if it is there:
It is in the Project Area administration, under
Team Configuration /
Operation Behavior /
Source Control /
Deliver (client) /
Preconditions and follow-up actions are configured for this operation /
Require Work Items and comments
Related
I am developing rest api update method for user profile resource user/profile. I am disappointed what http method should i use. Update contains some required attributes so it more PUT request, where client need to fill all attributes. But how it can extend attributes in future. If i will decide to add new attribute then it will automatically clear because client is not implement it yet.
But what if this new attribute has default value or is set by another route?
Can i use PUT with not stricting number of attributes and use old data if new isn't come in request. Or how it can be done normally?
HTTP is an application whose application domain is the transfer of documents over a network -- Webber, 2011.
PUT is the appropriate method to use when "saving" a new version of a document onto a web server.
how it can extend attributes in future.
You design your schemas to be forward and backward compatible; in practice, what this means is that you can add new optional elements with reasonable default values. When you need to add a new required element, you change the name of the schema.
You'll find prior art in this topic by searching XML literature for must ignore.
You understand correctly: PUT is for complete replacement, so values that you don't include would be lost.
Instead, use the PATCH method, which is for making partial updates. You can update only the properties you include values for.
I want to make sure that every time I make a change to a document, a certain action is performed. For this I wanted to use OnBeforeStore or OnAfterSaveChanges.
Unfortunately, these two events are not triggered when I save a change via patch or add/delete an attachment.
We use the CQRS pattern and have several commands making changes to entities / collections. I need a central place to execute every change to a particular collection, no matter which command is used.
Is there such a thing in RavenDB?
There is no "central place" that track every change to collection.
About the OnAfterSaveChanges event, it should fire on those actions too.
https://issues.hibernatingrhinos.com/issue/RavenDB-13906
I am completely new using RTC so please, I need an answer as simple as possible.
I recently accepted a change set from another team member and I need to discard the change set from my workspace. My problem here is that the change set I accepted was not delivered and it's still pending and awaiting a review approval. If I discard the change set will this wipe out the team members changes or will it just remove the change set from my workspace? In other words, I am not going to remove any changes the other team member made am I?
I really need to understand this?
Thanks
If I discard the change set will this wipe out the team members changes or will it just remove the change set from my workspace?
Just from your workspace (and your repo workspace).
See help page "Discarding change sets from workspaces".
Once a change set is delivered to the stream, you cannot remove it.
And you will have to accept it eventually, especially if you want to deliver your own change sets yourself to that same stream.
If accepting that change set is problematic, then the developer who originally delivered that activity to the stream needs to revert it (deliver a new change set that would cancel the previous one).
See more at "How to discard the change set once delivered in RTC".
Erigami comments below:
You can remove a change set from a stream by:
discarding it from your workspace, then
running 'Replace in <stream name>' from the Pending Changes view.
That sets the component's history to be the same as that of your workspace, so make sure you have all of the change sets you want in there. ;)
This question is linked to :
Why can't all change sets be found when accepting change sets?
If RTC discovers that by accepting a change set some of the change sets which depend on this change set will not be accepted, is it possible to view what these change sets are ?
It seems very risky to accept a change set and not be 100% sure that the change sets being accepted contain same source code file changes as was intended by developer who delivered the change sets ?
What you can do is adding the repo workspace of the developer having delivered on the source stream.
You would add that repo workspace as a flow target of your own repo workspace (the one you are using for the merge)
By setting that new flow target as current, you can quickly see what change set you are missing.
Of course, the real issue is that what I just proposed doesn't scale: if you have multiple developers having made partial delivers (with missing intermediate change sets), then you would need to have a look in turn to each developer's repo workspaces.
That is why you have since 2007(!) the "blocker" Work Item "Enhancement 24822":
"Confirm Content Accept" dialog should be more specific (offer to fill in gaps when a gap exception occurs)
... but it is still unresolved, even in the latest RTC4.x.
At 'Project Area' level on RTC under 'Team Configuration' -> 'Operation Behaviour' there are two deliver options :
What is the differnence between the two ? Are they both not delivering to the server ?
Those are for hooks:
executed on the client, that is before the deliver,
executed on the server, that is at the reception of the deliver.
It is on the client side, for instance, that I set the hook requiring that a Work Item is associated to a change set before said change set can be delivered (as illustrated in your previous question "Can I associate a change set with a work item after it has been delivered?").
I could check it on the server, but why use network traffic if the deliver is rejected anyway?
More precisely, As mentioned in this thread:
In general, you want all preconditions to run on the server, so the server (including the web server) can ensure those preconditions have been executed.
But there are some preconditions that must be run on the client, namely those that need to look at the local state of the client.
This is illustrated by the list of predefined preconditions.
In particular, most of these preconditions refer to the build/compile state of the workspace (information not available on the server), such as: "prohibit unused imports" and "prohibit workspace errors".
Note that there are three client-side preconditions that do not require client-side information ("require work item approval", "require work item and comments", "descriptive change sets").
These are included for backward compatibility, since they were made available in the first release of RTC, but have since then made available as server-side preconditions as well, so you should always use the server-side form of them.
I've submitted work item 209427 to get these client-side preconditions marked as "deprecated" with a pointer to the server-side preconditions that replace them.