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.
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 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. ;)
I have this requirement : My WL application have a set of static pages that might be updated any time. Originally the source of all static content is a desktop page that will be transformed by xsl to a mobile friendly content. The problem that I don't want to do that on each request (HA requirement).
I want to get some inspiration on how to architect that without using direct update mechanism (don't want the end user to get notified of these updates).
I should note that pages will change rarely every few month maybe.
I'm thinking about 2 ways of doing that :
1- Making the transformation on adapter side and rely on WL caching so that transformation is not made each time (does that exist ?). But how the adapter will get notified of page change and flush the cache ? Should I program some advanced java based adapter ? (Storing in the cache and having a kind of a job that scans every day for content changes ?)
2- Doing it mobile side but I don't know how to get notified of changes !
Is your only problem with Worklight's Direct Update that the user is being notified and is required to explicitly approve the transfer?
In this case why not use the option of Silent Direct Update?
The property you're looking for is updateSliently set to true in initOptions.js.
For this to work it is required, obviously, that connectOnStartup will be set to true as well.
perhaps what is doable is to use an adapter to fetch the HTML (or whatever it is) and save it to the device's local storage and then have the app display this content, this way you do not alter the app's web resources and not trigger Direct Update.
i am trying to work out a method to have component level variants in RTC.
Requirement is that there should be say at least two lines of development for the component. If there is an bug-fix on the parent line, i need to merge that change into the second line. I could not bring up yet a method using the streams. Any suggestions?
2 lines of developments means two stream.
You can easily add, in the flow target of the repo workspace, another stream.
I would recommend adding the parent stream to the flow target of repo workspace on the second stream.
That means you would accept changes coming from the parent stream (each time you set that stream in the flow target section as the "current" stream).
Once you have accepted those changes (and merged them in your local workspace or sandbox), you set again your second (and "default") stream as the current one, and are ready to deliver the change set you just accepted back to the second stream.
See an illustration in the section "How do I use the "new" method to accept from an integration stream instead of delivering to it?":
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).