It's all about the answers!

Ask a question

How to discard changeset on the stream?


Jia Jia Li (8057140190) | asked Dec 31 '11, 11:14 a.m.
Hi,

I have deliver some change set to the stream, but I want to discard the change set. How can I do it?

7 answers



permanent link
Geoffrey Clemm (30.1k23035) | answered Dec 31 '11, 1:53 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Discarding change sets is done in a workspace.
So you would:
- create a new workspace on the stream (or "replace" the content of an
existing workspace with that of the stream),
- discard the change sets from the workspace, and then
- "replace" the content of the stream with that of the workspace.

Cheers,
Geoff

On 12/31/2011 11:23 AM, sakulisalee wrote:
Hi,

I have deliver some change set to the stream, but I want to discard
the change set. How can I do it?

permanent link
Ulrich Eckhardt (23612223) | answered Jan 05 '12, 4:56 a.m.
As a follow-up to this, I'm a bit surprised by how this looks for other users after you did that (or for your other workspaces). Based on A, there was B1 in the stream. I then replaced the stream with B2 which is also based on A.

Other users/workspaces now had B1 as "outgoing" and B2 as "incoming (replaced)". The way to handle that was to discard the outgoing changeset and then accept the incoming changeset. What I was wondering was whether there is an easier way to simply accept the replacement that took place in the stream.

Requiring two operations makes sense from a technical point of view, but from a mere user's point of view it doesn't. In addition the red conflict icons increase adrenaline emissions ("Oh $DEITY! Something is broken here! Halp!!1!"), even though nothing is really wrong. Some guidance would be helpful here...

Cheers!

Uli

permanent link
Geoffrey Clemm (30.1k23035) | answered Jan 05 '12, 10:38 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
To avoid users being given the choice of re-delivering the discarded
change-set, you can use the "reverse" mechanism. Right click on the
change-set you want to discard, and select the "reverse" operation.
This creates a new change-set that reverses all the changes. Then other
users will just see this "reverse" change set as a regular incoming change.

Cheers,
Geoff

On 1/5/2012 5:08 AM, ulricheckhardt wrote:
As a follow-up to this, I'm a bit surprised by how this looks for
other users after you did that (or for your other workspaces). Based
on A, there was B1 in the stream. I then replaced the stream with B2
which is also based on A.

Other users/workspaces now had B1 as "outgoing" and B2 as
"incoming (replaced)". The way to handle that was to
discard the outgoing changeset and then accept the incoming
changeset. What I was wondering was whether there is an easier way to
simply accept the replacement that took place in the stream.

Requiring two operations makes sense from a technical point of view,
but from a mere user's point of view it doesn't. In addition the red
conflict icons increase adrenaline emissions ("Oh
$DEITY! Something is broken here!
Halp!!1!"), even though nothing is
really wrong. Some guidance would be helpful here...

Cheers!

Uli

permanent link
Ulrich Eckhardt (23612223) | answered Jan 06 '12, 5:36 a.m.
To avoid users being given the choice of re-delivering the discarded change-set, you can use the "reverse" mechanism.


Also, this will clutter the history with unnecessary noise, making it harder to find out when and by whom the code was written. Also, the discarded changesets that maybe fix a bug are still present while their code effectively isn't. Lastly, I don't think there is a link between the reverse changeset and the one it reverses.


Cheers!

Uli

permanent link
Geoffrey Clemm (30.1k23035) | answered Jan 06 '12, 10:23 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
WRT cluttering the history, RTC currently gives you two choices:
- use the "replace" method which removes the change-set from the stream
history, and each user that currently has that change-set in their
workspace history is made aware that they are going to lose that change-set.
- use the "reverse" method, which leaves the change-set in the history,
but adds a reverse change-set to the history. In this case, the
discard happens silently, but the information is still in the history so
a user can find out what happened.

It sounds like you are asking for an approach which silently removes the
discarded change set from the workspaces of users that currently have
that change set. I believe that result in (justifiable) unhappiness on
the part of users that are having changes disappear from their
workspace, with no warning or record of them ever having been there. Or
did you have something else in mind.

WRT the fact that there should be a link between a reverse change set
and the change set(s) that it is reversing ... I agree. This is
requested in work item 173309. Please feel free to add a comment
indicating your interest/support.

Cheers,
Geoff

On 1/6/2012 5:38 AM, ulricheckhardt wrote:
gmclemmwrote:
To avoid users being given the choice of re-delivering the discarded
change-set, you can use the "reverse" mechanism.


Also, this will clutter the history with unnecessary noise, making it
harder to find out when and by whom the code was written. Also, the
discarded changesets that maybe fix a bug are still present while
their code effectively isn't. Lastly, I don't think there is a link
between the reverse changeset and the one it reverses.

permanent link
Christophe Cornu (47123) | answered Jan 07 '12, 8:46 p.m.
Please have a look at the following entry in the Source Control FAQ:
How do I remove a change set from a stream?

HTH,
Christophe Cornu

permanent link
Ulrich Eckhardt (23612223) | answered Jan 09 '12, 9:34 a.m.
It sounds like you are asking for an approach which silently removes the discarded change set from the workspaces of users that currently have
that change set. I believe that result in (justifiable) unhappiness on
the part of users that are having changes disappear from their
workspace, with no warning or record of them ever having been there. Or did you have something else in mind.


Firstly, I think the idea behind the way that a replacement is propagated is correct, this is a solid base. In other words, the results are also correct and useful. It is only the UI that is a bit awkward here.

The point is, from a naive user's perspective (not everyone has any clue or even cares how version control systems work!), replacing something in a stream is no different than any other change to the stream. So, when someone else did that, it should be easy and painless to understand what happened and accept those changes into the workspace, but it isn't.

First, you have to understand that the outgoing part is not something that you created and that you deliver, but something that was removed from the remote flow target.

Then, there is a remote change coming in, but not via the incoming queue. Also, instead of accepting the change in the flow target, you have to discard something from your outgoing queue.

Lastly, there are conflicts. These just cause additional stress and they require you to perform certain actions in a certain order. This is different from normal workflow, where you simply accept incoming changes to bring your WS in sync with the flow target.

I have a suggestion how this could be displayed to the user. Firstly, RTC obviously knows that something was replaced, as it shows a "(replaced)" behind the incoming queue. If it could somehow determine those changesets that were replaced and display them not in the outgoing queue but as anti-changeset in the incoming queue, this would all be much clearer. The user would then have an anti-CS and a normal CS in the incoming, making it clear that one was removed while the other was added. Also, they could simply accept this queue as a whole with RTC performing the according operations.

I could also imagine such an anti-CS being a first-class server-side object and not just a client-side visualization. That way, there wouldn't be any need to baseline the stream before replacing, because the first-class object would be part of the stream's history.

Thanks for the link to work item 173309, that would indeed make reversals more convenient to use!

Uli

Your answer


Register or to post your answer.