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. ;)
Related
I use unison to sync a couple of directories between my laptop and desktop. Whenever there are new files on one system, I have to confirm each one individually:
<--- new file c [f]
I've scoured through the docs, but I can't seem to find a setting that will just auto-accept unison's recommendation. Is there one?
Yeah, the option -auto is what you're looking for. From the documentation:
auto
When set to true, this flag causes the user interface to skip asking for confirmations on non-conflicting changes. (More precisely, when the user interface is done setting the propagation direction for one entry and is about to move to the next, it will skip over all non-conflicting entries and go directly to the next conflict.)
Also of interest:
batch
When this is set to true, the user interface will ask no questions at all. Non-conflicting changes will be propagated; conflicts will be skipped.
I need to do certain processing when a Scintilla editor first becomes 'dirty' before the document actually changes.
The SCN_SAVEPOINTLEFT notification seems like the obvious candidate, but unfortunately this is fired after the change that made the document dirty has occurred.
Looking through the other available notifications, SCN_MODIFIED also is fired after the change has happened (and the same is true of SCEN_CHANGE of course).
The best I can think of is to start macro recording in response to SCN_SAVEPOINTREACHED (i.e. when the document is saved or all changes are undone). Then when I detect the first change with SCN_MODIFIED, I stop recording, undo all changes until I get back to the save point, perform my custom processing (which happens to be modifying a date field in the document), then replay the recorded macros to restore the undone changes.
This seems horribly convoluted. Is there an easier way? (Maybe it would be simpler to create my own custom version of Scintilla with a SCN_BEFORECHANGE notification, but I'd prefer to avoid creating a fork. And a cursory glance through the source suggests that there are a great many points from where this notification would have to be sent, making it easy to miss some.)
Update: The real requirement was that when the user executes 'Undo' after first modifying the document, the 'automatic' edit and the user's first edit are not in the wrong order in the undo buffer. The simplest solution turned out to be, not to force the automatic update to be first, but to coalesce these two actions into a single undo action using SCI_BEGINUNDOACTION/SCI_ENDUNDOACTION. See my comment below on how I did this.
The SCN_MODIFIED notification does seem to fit your spec. The modificationType field provides information about what has been done, including:
SC_MOD_BEFOREINSERT 0x400 Text is about to be inserted into the document.
SC_MOD_BEFOREDELETE 0x800 Text is about to be deleted from the document.
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).
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.
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