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