It's all about the answers!

Ask a question

change flow target results in incoming becoming outcoming

Darrell Reich (949) | asked Sep 06 '16, 9:29 p.m.
 After accepting incoming changes they are now outcoming and I can't deliver them (again) because I'm not the work item owner. What have I done? How do I fix it? How do I prevent it from happening again?

Our large project has 3 streams
I have two private repository workspaces
I have two local workspace sandboxes
The idea was supposed to be sandbox1 connected to dev stream workspace connected to integration stream
Then sandbox2 connected to patches steam forked off then later merged back with integration stream

Did I get totally confused as to which sandbox I was in when I did Change Flow Target, Accept Incoming. Now everyone elses work items including the build baseline is listed as Outgoing. My only menu choice is to Deliver which doesn't work since I'm not the owner.

More than one work item / owner / change set owns the same file and it is totally tangled up. I tried to merge now get error that would create gap in stream when I try to deliver just the change sets owned by me.

I need to understand what "Change Flow Target" does? It is unclear when my local sandbox vs the repository are being updated.

I can be in sandbox1 or sandbox2 and change flow to any of the three streams then accept incoming. It appears to just make a huge mess and not do what was expected which is sync up with others changes.

One answer

permanent link
Geoffrey Clemm (30.1k33035) | answered Sep 11 '16, 5:12 p.m.
First, note that sandboxes are largely irrelevant for the Pending Changes view, so I suggest focusing this discussion on your workspaces and streams (which are what the Pending Changes view is all about).   That is why workspace and stream names appear in the Pending Changes view, and not sandbox names.   Note that by "workspace", I am referring to a "repository workspace".   There are also "Eclipse workspaces", but they are not relevant to this discussion.
Second, it is good to be explicit (both in your head, and in your post) about what the names and purposes of the workspaces and streams you are dealing with.   So what are the names/purposes of your 3 streams, and what are the names/purposes of your 2 workspaces?

As to what "change flow target" does ... that specifies what shows up in the Pending Changes view, what stream/workspace your change sets will flow to when you hit "Deliver" or "Accept".   So changing your flow target does not change which change sets are in any of your workspaces/streams ... it just determines where changes will be made when you subsequently hit "Deliver" or "Accept".

Note that a file is not "owned" by a work item or change set.   A change set creates one or more new versions of a file, and a work item references one or more change sets (more than one work item can reference a given change set).

Darrell Reich commented Sep 13 '16, 1:49 p.m.

The project we're contributing was setup by others after porting from ClearCase/ClearQuest: Patches stream --> Integration stream <-- Development stream

Intent is to develop version 1.1 in patches while 2.0 in Int. Everything in 1.1 is in 2.0 but everything in 2.0 is not in 1.1.

I have patches & dev private repository workspace. Each of my team has dev workspace. For continuous integration internal builds we deliver to dev. When pass test, I change flow target & deliver to Int. However, incoming change sets become outgoing including the baseline.

In order to create a change set and deliver, I must have a work item assign (owned) by me. therefore the incoming/outgoing changed files also have an owner. I get error you are not the owner of the change set work item when I try to deliver the outgoing. I am unable to reverse, suspect, or discard any of this. I am not the admin, I have not been given access to more than our component directory folders. It appears three people, three work items all changed one file which is causing a conflict gap in stream.

Geoffrey Clemm commented Sep 17 '16, 2:40 p.m. | edited Sep 17 '16, 2:42 p.m.

Your stream setup is reasonable.  
The reason you are running into trouble delivering is most likely that when your flow target is set to Dev, you are accepting all the incoming changes, which includes change sets that other developers have delivered to Dev, but which are not yet ready to deliver to Int.    Then when you change your flow target to be Int, and try to deliver, it is telling you that you cannot deliver other developers changes (which is probably what your project lead thought she wanted, because only the owner of those change sets knows when those changes are ready to be delivered to Int).   The problem is that this approach only works when every file is "owned" by a single developer, and only that developer makes changes to that file (and that clearly is not the case in your organization, since three people have made changes to a single file).

So you have some choices, each of which has some advantages and some disadvantages (i.e. there is no "right" way to handle this).

Probably the simplest choice is to remove the Dev stream, and instead do "personal builds" from your workspace.   To keep things even simpler, each developer would have two workspaces ... a Patch workspace and an Int workspace (depending on which stream your change is intended for).   Then when your personal build succeeds, you deliver to the current stream of that workspace.   The downside of this approach is that while you are somewhat isolated from your other team-members ... you only see their work when it is ready to be delivered to Patch/Int, so you end up having to "merge" more.

To cut back on the amount of merging, you can bring back (keep) the Dev stream.   But then you need to have your project lead turn off the "you can only deliver work items that you own" precondition.   Instead, you would turn on a precondition that requires that a workitem be in a "completed" state before it can be delivered.   You can still be temporarily blocked from delivering (if you have some changes that were made on top of other changes that are not yet complete), but eventually those work items you depend on will be marked as "completed" and you can then deliver your work.

There are other options as well, but these are probably the two most commonly used.

Your answer

Register or to post 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.