It's all about the answers!

Ask a question

Load an old changeset with the discard command


Roberto Cometti (132) | asked Mar 18 '15, 10:14 a.m.
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


permanent link
Evan Hughes (2.4k1318) | answered Mar 18 '15, 11:41 a.m.
JAZZ DEVELOPER
All I need to do is put my sandbox in a certain state, identified by a UUID (e.g. git checkout <changesetid>). 
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. 

If I checkin a change and after that I want to rebuild the parent changeset and run some tests, if I use the discardcommand, the changeset I just checked in is nuked from my remote workspace. 
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. 

Aside: "nuked" is too strong a word. Let's just say the change set is removed from your repository workspace (and sandbox, if you have the repo workspace loaded). I want to make that distinction to indicate that other users may have the change set in their repo workspaces, and it may be present in one or more streams or baselines. It will also continue to dangle off any work items it is associated with. 

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

Perhaps I am too used to the distributed approach of GIT/Mercurial? 
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
Roberto Cometti commented Mar 19 '15, 5:57 a.m. | edited Mar 19 '15, 6:02 p.m.

Hi Evan,

Thank you for the answer :D

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

To help understand the model, think of each change set as just a Unix "patch file".   No patch file (except for the patch that first creates that file) has the full content of the file ... it just has the diff between the content of the file and the previous content of that file.  So the change set by itself does not have anything you can put on disk ... but you can apply that change set to some configuration (workspace, stream).


Evan Hughes commented Mar 23 '15, 9:34 a.m. | edited Mar 23 '15, 9:41 a.m.
JAZZ DEVELOPER

Glad I could help! 


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. 

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


Register or to post your answer.