Occasionally when I am accepting I change set I receive the following message :
To resolve this I apply the changes as a patch and then 'Merge into workspace' the changes
Why cannot all of the change sets be found ? Is there a danger my code could become out of sync with the flow target ?
The danger is not so much the out of sync, but the integrity of the resulting code, once the patches are applied:
You are accepting change set based on other change sets that are not delivered.
There is no guarantee that it works.
As explained in this thread:
In S1, suppose there are two change sets that have modified file foo.java: CS-23 and CS-35.
You have requested CS-35, but not CS-23.
But the state of file foo.java in CS-35 contains the changes from CS-23... So you can't get CS-35 unless you also have CS-23 (i.e. "the change set that led up to this change set").
It is ok for a developer A to not deliver all his/her change set, provided he/she delivers all change sets up to a certain point.
The warning appears in case of a partial deliver (the developer delivers B, based on change set A, but does not deliver change set A)
That might not be an issue, if there is no functional dependency (similar to git cherry-pick) between the two change sets (if B doesn't rely on code in A to compile, for instance).
Related
I have a program that reads the settings from a settings.ini file. If it comes across a typo or similar issue, what should it do?
Given a settings.ini-file's syntax is like this:
DefaultFolder = C:\Settings
Programversion = 0.52
If the program comes across, say, a spelling error, like this:
DefauFolder = C:\Settings
What should it do?
The answer to this is, inevitably, 'Fail gracefully'. However, in the case of a settings file the 'fail' part is what is in question.
Typically, when a piece of code requires a setting, it will fail if it doesn't find that setting, throwing an appropriate error or exception. In that case, it is the code that needs the setting that should fail gracefully.
Also typical is to see a settings file that allows settings beyond what is strictly required. All additional settings are ignored. Whatever ingests the settings simply skips by them (or puts them in a registry, or what have you). But it still assumes the user knows what they are doing.
Anything more complex requires knowing a lot about user intent.
Given your specific example, this means:
The DefauFolder setting is consumed by the setting ingester and placed in a registry or hashmap, where no one looks at it.
When code needs the DefaultFolder setting, it looks in the settings registry and doesn't find it. It fails with an error message that says something like, "DefaultFolder setting is required in the ini file to complete , but could not be found."
Say I have a table for machines, and one of the columns is called status. This can be either active, inactive, or discarded. A discarded machine is no longer useful and it only used for transaction purposes.
Assume now I want to discard a machine. Since this is an entry update, RESTfully, this would be a PUT request to /machines/:id. However, since this is a very special kind of an update, there could be other operations that would occur as well (for instance, remove any assigned users and what not).
So should this be more like a POST to /machines/:id/discard?
From a strict REST perspective, have you considered implementing a PATCH? In this manner, you can have it update just that status field and then also tie it in to updating everything else that is necessary?
References:
https://www.mnot.net/blog/2012/09/05/patch
http://jasonsirota.com/rest-partial-updates-use-post-put-or-patch
I think the most generic way would be to POST a Machine object with { status: 'discarded' } to /machines/:id/.
Personally, I'd prefer the /machines/:id/discard approach, though. It might not be exactly in accordance with the spec, but it's more clear and easier to filter. For example, some users might be allowed to update a machine but not "archive" it.
Personally I think post should be used when the resource Id is either unknown or not relevant to the update being made.
This would make put the method I would use especially since you have other status types that will also need to be updated
path
/machines/id
Message body
{"status":"discarded"}
So I'm using CodeMirror, and I'd like a way to omit certain edits from the undo state. In particular, I've got a situation where I want one keystroke to
Replace a portion of the mirror text AND
Auto-indent the fresh region
Doing this naively would mean that using the keystroke, then hitting undo would leave the mirror containing the new text without the indentation. I'd like a single undo to restore the initial text rather than going to the unindented version of the replaced text.
The only API-supported approach seems to be doing a .getHistory call before the indent, followed by a .setHistory call immediately afterwards, but the docs imply that this is a bad idea. Specifically, the effects of this are undefined if the contents of the mirror changed between .getHistory and .setHistory calls, which is the whole point in this situation.
There's also an addToHistory flag in the text marking API, but it's only available marking rather than arbitrary edits like indentation.
Is there a good way to do what I'm looking for here?
Changes made within a single operation will result in only a single history event.
If arranging for a single operation isn't viable, the origin field of a change (settable as an argument to replaceRange and replaceSelection, and in other cases a little more awkwardly by registering a beforeChange event handler) determines the type of history-event-combination that CodeMirror does. If you assign an origin that starts with an asterisk (*) character, subsequent changes with the same origin will be combined. If the origin starts with a +, subsequent same-origin changes will be combined when they occur within options.historyEventDelay milliseconds.
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.