Get back to a specific changeset
An equivalent to 'git checkout 1234567ab' or 'svn checkout url://repo/path@1234'...
I didn't find any equivalent to this option in the scm load command...
One answer
For the unforeseen circumstances, you can discard the change set and everything delivered after it to get your component at the state it was before delivery. You wouldn't be able to tell what the configuration of the other components in your repository workspace was at before delivery though.
Comments
Thanks! This triggers other questions then... What is the cost (on the server) of a snapshot or a baseline? Could I create one after each delivery? Using SCM, how could I discard a given changeset (and everything after it)? Even in the RTC Eclipse client, I don't see how to achieve this...
The cost is minimal. Frequent baselines are good and wouldn't affect regular tasks if you created them for each delivery. It would be more difficult if you wanted to revert to a much older baseline because the UI doesn't have a nice way of searching for a particular baseline but would be easy for more recent baselines.
Snapshots will scale as well. It's standard for the JBE to create a snapshot for every build. Baselines are also required to be created for components that don't have a baseline describing the current configuration.
In the Eclipse client, show the history of the component in your workspace. Select all the change sets down to the change set that you want to get rid of and discard/suspend.
But then, as we would be using the scm tool, I'll have to find the UUID for all the changesets in the repo since the one I want to get back to, and give them to the 'scm discard' command. The reverse (get me back to this specific changeset and discard all the rest) would be much easier, wouldn't it?
I would suggest not trying to use the "find change set and discard later" approach to reproducing a previous configuration. In particular, there are situations where the change set history sequence is reordered by a deliver/accept operation. In RTC a change set is not a new revision of the component ... it is a delta. I'd recommend using the "create baseline" approach for remembering each state of the component you might want to return back to (or "create snapshot" if you care about a configuration that spans multiple components).
I suppose we'll then snapshot after each and every deliver, then... Are there specific reasons why RTC doesn't do it on its own? If there are, they might apply to us also... If there are no, then I should file an RFE...