The dilemma of shared/team workflow

All of the below is true, except that in 3.0.1, the ability to
deliver/accept directly from one stream to another is now supported (a
stream can be loaded into the Pending Changes view), so setting a
stream's flow target now does have a practical use.

Cheers,
Geoff

On 7/26/2011 9:23 PM, crvich wrote:

Are both of these assumptions correct?

1. Streams do not allow discarding of individual change sets, nor can
you deliver or accept a change set to/from one Stream to another
Stream directly (i.e., you must use a Workspace to do so, thus
setting a stream's flow target doesn't really have any practical
use).

2. Workspaces can only be owned by a single userid, not a project area
or team area...thus they cannot be used as shared/integration work
areas (that multiple users can deliver to).

All of the below is true, except that in 3.0.1, the ability to
deliver/accept directly from one stream to another is now supported (a
stream can be loaded into the Pending Changes view), so setting a
ple users can deliver to).

Alas, the new solution still doesn't permit discarding changesets from a stream. Imagine the typical flow:

Dev workspaces --> Shared Team "work" stream (candidates for a build) --> Builder Workspace --> Committed Release Stream

There is no way for a developer, after delivering to the stream, to take his changesets back out of the shared stream if he realizes there is a problem. Thus the builder has no automatic way of knowing that certain changesets shouldn't be included in a build.

How can one solve this? Why don't streams permit discards?

I should say for clarity that it isn't really the part about the builder knowing which changesets are eligible for a build that is critical (since the user could add text to the changeset comment to say it's not ready), but rather that there is no "undo" from a stream (AFAIK). There is a concern that many IBM teams would be impacted by this, since simply re-delivering changes will create co-dependencies that should not exist. For example:

Dev A changes foo.asm, delivers.
Dev B accepts foo.asm, makes their own changes, delivers.

Now if dev A realizes their changes are incorrect (or ill-advised in general), they cannot literally back them out. At this point dev A could only undo locally (carefully maintaining dev B's changes) and re-deliver. But that creates a dependency (A on B) that should not exist. In the IBM service world, the process is for both developers to undo from the shared repository/stream, and then dev B would re-deliver his changes alone. CMVC supports this process model, for example.

RTC encourages you to make your changes (both additions and
discard/reversals of change sets) in a personal workspace and verify
that the new configuration is valid (run personal builds, for example),
before making the changes public in a shared artifact like a stream.

An exception is made for changing the configuration to be that of an
existing baseline (which assumedly has already been verified as a valid
configuration). That you can do directly on a component in a stream
with the "replace" operation.

In addition, discarding a change set is often not what you want ...
since that leaves those change sets as outgoing changes in the Pending
Changes view of the other workspaces and streams that flow with that
stream. Instead, you often will want to "reverse" the change set
instead, and that can only be done in a workspace, since it involves the
creation of a new change set.

Cheers,
Geoff

On 8/4/2011 6:53 PM, crvich wrote:

gmclemmwrote:
All of the below is true, except that in 3.0.1, the ability to
deliver/accept directly from one stream to another is now supported
(a
stream can be loaded into the Pending Changes view), so setting a
ple users can deliver to).

Alas, the new solution still doesn't permit discarding changesets from
a stream. Imagine the typical flow:

Dev workspaces --> Shared Team "work" stream (candidates
for a build) --> Builder Workspace --> Committed Release
Stream

There is no way for a developer, after delivering to the stream, to
take his changesets back out of the shared stream if he realizes
there is a problem. Thus the builder has no automatic way of knowing
that certain changesets shouldn't be included in a build.

How can one solve this? Why don't streams permit discards?

You can undo from a stream ... you just need a workspace to do it.
Discard the change set from your workspace, and then use the "replace"
operation to back up the stream to the current state of your workspace.

Alternatively, you can "reverse" the change set in your workspace, and
then you can just use the normal "deliver" operation to effectively back
out that change.

The question of keeping a change (such as Dev B's change to foo.asm)
while backing out a change it was based on (such as Dev B's earlier
change to foo.asm) is a different question. That requires a
"subtractive merge" which can require human review (such as when the
later change modified a line that had also been changed by change being
backed out). RTC calls this situation "creating a gap". And I agree
that RTC should improve the way it handles gaps. This is being tracked
in several work items, such as 128329 "Need to be able to handle gaps
via standard accept mechanism, and not patch mechanism".

Cheers,
Geoff

On 8/4/2011 8:08 PM, crvich wrote:

I should say for clarity that it isn't really the part about the
builder knowing which changesets are eligible for a build that is
critical (since the user could add text to the changeset comment to
say it's not ready), but rather that there is no "undo"
from a stream (AFAIK). There is a concern that many IBM teams would
be impacted by this, since simply re-delivering changes will create
co-dependencies that should not exist. For example:

Dev A changes foo.asm, delivers.
Dev B accepts foo.asm, makes their own changes, delivers.

Now if dev A realizes their changes are incorrect (or ill-advised in
general), they cannot literally back them out. At this point dev A
could only undo locally (carefully maintaining dev B's changes) and
re-deliver. But that creates a dependency (A on B) that should not
exist. In the IBM service world, the process is for both developers
to undo from the shared repository/stream, and then dev B would
re-deliver his changes alone. CMVC supports this process model, for
example.

I am attempting to undo from a stream, remove a changeset from which another changeset depends on, using a workspace. When I get to the step of merging the only option that allows me to successfully merge is removing both changesets. There does not appear to be a mechanism to "mark it resolved" as you would in SVN. I am betting that I am missing something but here is my setup:

**This required 2 workspaces. Each workspace must be created from the same stream.

(1) Using workspace 1 create a class with nothing in it. Checkin and deliver the changeset.
(2) Using workspace 1 add a 1 line comment to the class created in step 1. Checkin and deliver the changeset. I added a comment but DID NOT associate the delivery with a work item.
(3) Using workspace 1 add a 1 line comment under the comment created in step 1 to the class created in step 1. Checkin and deliver the changeset. I added a comment but DID NOT associate the delivery with a work item.
(4) Using workspace 2 you see 3 incoming changes; the class creation, comment 1 and comment 2. Accept all 3 changesets.
(5) Using workspace 2 right click on the class created in step 1 and select Team -> Show History. The History dialog displays the 3 changesets that were delivered to the stream.
(6) Right click on the middle changeset, comment 1, and select Reverse. A patch appears under the pending patches root node inside of the Pending Changes view.
(7) In the Pending Changes view open the pending patch hierarchy until the file with the patch is displayed. Right click the file and select "Merge into Workspace...". Click "OK" on the first dialog.
(8) A "Auto Resolve" dialog appears. It says "None of these changes could be accepted. You will have to merge them manually."... Click "Ok"
(9) In the file name "(file contains conflicts)" appears. Double click the file to open the source compare/merge view.

This is where I am stuck. I have a view with 2 files displayed with no version info. I am assuming the file on the right is the first changeset (from creating the class) and the file on the left is the final changeset. The file on the left both changesets are highlighted with a red box. I edit the changeset I do not want, comment 1, yet the box is still red as it does not match the file on the right. Should I not have the ability to edit the file with whatever I want then mark it as resolved?

Is it possible to remove changesets that are not the most recent changeset applied to a file? If yes how?

Any help would be appreciated.

My version of the RTC Client (3.0) did not include the right-click menu item "Resolve with proposed". This was resolved by installing the latest RTC Client (3.0.1.2)

In order to undo from a stream, reverse a change set that has been accepted, that will produce conflict(s) I used the following workaround:
(1) Select the change set you wish to reverse in the file history, right-click on it, and click on "Reverse".
(2) Inside your Pending Changes view an entry under "Pending Patches" is created. It will be named "Reverse:change set name"
(3) Right click "Reverse:change set name" and click "Merge into Workspace...". You will receive a message "None of these changes could be accepted...", click "OK".
(4) Expand the files under the patch. You will see the files that are in conflict.
(5) For each conflicted file, double click on it and perform the edits you want. Save each file.
(6) You will see that each time you save a file an outgoing change set is created. Deliver each outgoing changeset.
(7) Right click on "Reverse:change set name" and click "Remove from View"

This is a workaround and likely not good practice as you never apply the patch and have little tractability that you actually created a patch.

Craig

I'm not sure if that work flow can be improved to not require the conflict resolution but merging the patch would create a change set anyway. Either way, you'll end up with a change set that reversed the changes. It's still a change set that you're delivering so the traceability is the change set that is delivered and any work items associated with it.

I think the workflow for resolving conflicts could be more intuitive. Resolving the conflict(s) (manually) introduced by a patch then add the changes automatically to the patch. Then allowing the patch to be applied as is. It would also be great if the patch maintained the original conflicts and the change set(s) used to remedy them.

The part of the current workflow I don't like is that the patch mechanism is not present in the history. Even though a change set is recorded I would like to see that someone attempted to remove a change set using the "Reverse" mechanism.

These issues should be addressed by work item 128329, which is high
priority for the release following 4.0 (unfortunately, it did not fit
into the schedule for 4.0.

Cheers,
Geoff

On 1/26/2012 11:23 AM, craffel wrote:

I think the workflow for resolving conflicts could be more intuitive.
Resolving the conflict(s) (manually) introduced by a patch then add
the changes automatically to the patch. Then allowing the patch to be
applied as is. It would also be great if the patch maintained the
original conflicts and the change set(s) used to remedy them.

The part of the current workflow I don't like is that the patch
mechanism is not present in the history. Even though a change set is
recorded I would like to see that someone attempted to remove a
change set using the "Reverse" mechanism.