It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,882
×12,008
×1,201
×21
×6

question asked: Apr 16 '13, 3:24 p.m.
question was seen: 7,186 times
last updated: Apr 17 '13, 3:46 p.m.

Related questions

Get back to a specific changeset

1
Xavier Nodet (22●4●6) | asked Apr 16 '13, 3:24 p.m.
retagged Apr 16 '13, 4:08 p.m. by Andrei Litvin (23●1●4●9)
Is it possible, using SCM, to get back to a specific changeset for which I have the UUID?  I'd like my local sandbox to be an exact replica of the state of the local sandbox of the other developper when he or she delivered the changeset.  How can I do this?

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

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Tim Mok (6.6k●3●8) | answered Apr 16 '13, 4:29 p.m.
JAZZ DEVELOPER
In the future, your developers could create baselines before delivering to an integration or team stream. This would make it easier to revert to a state before the delivery. You may want to create a snapshot for bigger or riskier changes affecting multiple components.

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
Xavier Nodet commented Apr 16 '13, 4:56 p.m. | edited Apr 16 '13, 4:56 p.m.

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...

Tim Mok commented Apr 16 '13, 5:05 p.m.
JAZZ DEVELOPER

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.

Xavier Nodet commented Apr 16 '13, 5:51 p.m.

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?

Geoffrey Clemm commented Apr 16 '13, 11:50 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

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).

Xavier Nodet commented Apr 17 '13, 3:46 p.m.

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...

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.