Load an old changeset with the discard command
Hi there,
I am new to RTC, coming from GIT/Mercurial. I still do not fully understand the discard command. I have read the answers to this question, but they did not help me. All I need to do is put my sandbox in a certain state, identified by a UUID (e.g. git checkout <changesetid>). If I checkin a change and after that I want to rebuild the parent changeset and run some tests, if I use the discard command, the changeset I just checked in is nuked from my remote workspace. I understand that if I delivered the change to the stream my change would still be there. But I do not want to deliver to the stream at that point. Is there an alternative? Perhaps I am too used to the distributed approach of GIT/Mercurial? Thanks, Roberto. |
Accepted answer
In RTC you do that by replacing the component in your repository workspace with a baseline. If you want to get your entire repository workspace into a specific state, you replace your entire repo workspace with a snapshot. If you don't have a baseline/snapshot representing the state you want, then you need to discard change sets back to that point. Practically, a state in time is usually represented as a build, which implicitly creates a snapshot when it runs, so you're probably safe.
I'm not sure what you mean by "rebuild the parent changeset". Change sets aren't a shorthand for a point in time (like git) - they're a collection of changes that are applied to a workspace/stream to put it into a new state. When you checkin, you're creating a delta between the workspace's previous state and the state after the checkin. When you discard, you're removing the change set, which removes the changes from the repo workspace and leaves it in a different state.
Yeah, the stream and repo workspace are two distinct entities. When you deliver to a stream (or accept into a repo workspace), you're adding change sets. Those change sets move files within the workspace/stream from one state to a new state.
RTC SCM is also distributed. ;) It represents changes and states of time differently from git.
Does this help? If not, post a comment on this question and I'll see if I can clear up any ambiguities.
Roberto Cometti selected this answer as the correct answer
Comments Hi Evan,
In RTC you do that by replacing the component in your repository workspace with a baseline. If you want to get your entire repository workspace into a specific state, you replace your entire repo workspace with a snapshot. Baseline/snapshot is a new concept for me. You could say that in my little head, every changeset is a baseline. That is where the confusion came from. I'm not sure what you mean by "rebuild the parent changeset". I think you understood what I meant: git commit git checkout HEAD^ build Change sets aren't a shorthand for a point in time (like git) - they're a collection of changes that are applied to a workspace/stream to put it into a new state. Again this is probably a confusion due to my RTC ignorance. Changesets are a bunch of diff files, applied on top of each others. Checking out a changeset to me means to put my filesystem in the state it was when all the patches up to a certain changeset were applied. Aside: "nuked" is too strong a word. It might be strong, but if I do the following (which is what I would do in GIT, see above): lscm ci lscm discard UUID_of_the_changeset_I_just_checked_in I can kiss goodbye to my changes :D Your answer definitely helped, I just need some time to get used to the new concepts. I might bug you again in the future :D Thanks, Roberto. 
Geoffrey Clemm
commented Mar 19 '15, 6:11 p.m.
| edited Mar 19 '15, 6:11 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Note that if you "discard" a change set in RTC, it removes it from your current workspace, but the change set exists in the database, and you can just "accept" it again to any workspace to apply that delta to the configuration of that workspace. There is a "search" command that makes it relatively easy to find any discarded change set (search by creator, when created, filename of file added/removed/modified, etc.).
Glad I could help!
One of the subtle differences between RTC SCM and git is that there's no notion of "all the [change sets] up to a certain point" in RTC. Instead, a change set knows the previous states of the files before it is applied and the after states that will exist after it's delivered to a stream (or workspace). That means you can deliver a change set anywhere the previous states exist, which makes backporting easier.
Since a change set also knows its previous states, it isn't quite the same as a patch. Even if the patch of the change set would apply cleanly, if the files aren't in the previous state, the change set needs to be merged in. That's essentially a book-keeping operation where we fiddle with the stream (or workspace) to allow the conflicting change set to be applied despite the differences in state.
|
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.