One thing I'd suggest trying is to go to the
" Team -> Jazz_Source_Control -> Changes"
preference, and select the
"Flow Targets : show all (advanced)"
option.

Then all the flow targets will be shown, instead of just the "current" one.

Cheers,
Geoff

On 11/17/2010 9:23 AM, yaron wrote:

Hello,

I have a scenario of a multiple stream developement.
I would like to be able to work with "dev" stream for
several users, and also perform a deliver to "bugfix"
stream.
My solution was to create a "special" repository WS that
it's default targer is "dev" stream and additional flow is
for "bugfix".

When an update to "bugfix" stream is needed, I will change
current flow to "bugfix".

I know it works well.
The problem is with the terminology.
**Both actions are called "deliver".
In ClearCase, for example, there was a "deliver to
alternate" operation.

Is there a way to create a new action such as - right click - deliver
to alternate.
Of course, it should be enable when 2 or more flow target
congiguration is in use.

It may be much easier for users to understand.

Also, if there is a better way doing it, please let me know.

Thanks,

Yaron

Hello,

lets say that 3 users are implementing FEATURE 1. They have their personal repository workspace for that.

Lets say that they will share that using a stream.
Now they need to integrate it to the main stream (remember that they developed FEATURE 1).

Also, the integration activity can be done by several team members. the team just choose one of the team members for that activity, and he needs to integrate it.
What is the best way doing it?

I know that each user can have flow target from his personal repository workspace to the main stream. but it is confusing regarding the pending changes view.
That is the reason why we thought that a shared repository workspace (only for the integration activity) will be a good solution.

I know that the concept is having a personal repository workspace, and I am open minded for a simple solution for that use case.

@gmclemm- Can you please relate to that?

Thanks,

Yaron

Geoff will have a much better answer but let me give it a try. It sound like you need a stream for Feature 1, then when you are happy with the feature, have one person create and load a new repo workspace with the Feature 1 and then deliver to the Main stream. Otherwise, you are using repo workspaces as a stream - which is not really the intention.

anthony

One first general comment. In UCM, you need a development view and an
integration view. In RTC, you only have a single workspace, in which
you do both development and integration.

Specific comments below:

On 4/4/2011 7:38 AM, yaron wrote:

... lets explore my options:
Please also remember that I would like that each user that developing
FEATURE A will be able to perform that "integration"
activity.

Yes, every developer can just do that integration in their own
development workspace ... as indicated in the beginning, there is no
need to have a separate integration workspace for doing integration.

Option #1:
I will have a repository workspace that has 2 flow targets: one for
the FEATURE A and the other for the integration steam.
For integration: I need to set current to the FEATURE A stream, take
all incoming.

Note that this is just your development workspace.
So that normally is caught up to the latest on Feature A, so you usually
don't have anything to accept from the Feature stream.

Them to change flow target to integration. Deliver / accept.

Hopefully, you did an accept followed by at least some smoke tests,
before you did the deliver. Also note that you don't have to change
flow targets ... you could just configure your pending changes view to
show all flow targets (i.e. show both the FeatureA and Integration streams.

Then again change back flow target to FEATURE A stream and deliver
all.

Yes, assuming that you are going to keep using the FeatureA stream for
some new purpose (at which point, you'd probably rename it, to FeatureB).

Now please note that it can be done only by the repository owner, so
basically I need to maintain several reposityry workspaces, one per
user.

Yes, every user needs their own repository workspace, otherwise, you
have no way of controlling when you see changes being made by other
people, and when other people see changes that you are making. But note
that each user only needs one workspace ... not multiple (for this
scenario). And in any case, they are going to have their own "sandbox"
(file area on their local disk), unless you are going to have everyone
working on a shared file system somewhere. The purpose of the
(private) repo workspace is to accurately and efficiently capture the
state of the (private) sandbox.

Option #2:
If I will be able to set permission to a repository workspace for a
team (not just user), I will be able to use it as FEATURE A
environment.
By that I will be able to deliver directly from that environment
without the need to switch flow targets. ( think about deliver in
clearcase between child stream to it's default target).

In ClearCase, each developer always has their own view. In the same
way, in RTC, each developer always has their own repository workspace.

Another thing: May be it will be wise to have an option to get
automatically a repository workspace connected to a stream and
updated all the time for that purpose.

Why do you think that auto-updating is a good idea? You will have no
idea whether the builds and tests you have done in your personal
workspace are still valid, if files change out from underneath you
without you requesting it, or being notified. The result will be a much
higher incidence of broken team builds on the integration stream.

Cheers,
Geoff

Comments below inline:

On 4/12/2011 4:53 AM, yaron wrote:

Hi Geoff,

First of all, thanks for the detailed answer.
Regarding the feature integration to the "main"
development.
You wrote:
"Why do you think that auto-updating is a good idea?".
I will explain the concept.
I am aware to the fact that you can configure your own repository
workspace to flow to several streams (to feature stream and
"main" stream).
This is something that the users find very confusing.
They would like to have one flow to one "higher" level.

First, I understand and agree with your desire to simplify change flow
for your developers. But there are a variety of use cases where it is
essential that a developer have control over when (and whether) their
changes flow into the feature stream, or changes from the feature stream
flow into their workspace. For example, without this, the developer
cannot checkin their experiments, because this would disrupt the feature
stream. In addition, the idea of "auto-accept" is problematic in any
copy-based system (i.e. any system other than ClearCase dynamic views),
because this will always result in your copy-based file area being
out-of-sync with the configuration of your workspace.

My personal view on how RTC needs to be improved in this area is
described in work item 33115, i.e. that you need to be able to configure
a workspace as accepting from multiple targets, but delivering to only a
single target.

Moreover, there is an option,as you mentioned, to show all flows in
the pending changes view.
It is not easy to use if you have several components loaded.

I completely agree. I've submitted work item 161867, requesting that
the multi-component display of the all-flows mode be improved. Please
feel free to add comments with any details about either the problems you
currently find in that regard, or ideas about how to improve.

So, we thought that each developer will deliver / accept to the
feature stream. that's works fine.

Yes, until something like work item 33115 is implemented, that's what I
would recommend.

Now, for the scenario of integrating the feature stream to the
"main" stream - we need a solution.
We thought that since you need a repository workspace (you have to be
able to accept) for that, we will have an up to date repository
workspace that has all changes (accept) from the feature stream.since
there is no development activity at that environment the accept should
succeed.
Moreover it can be configured as current target to the
"main".
What do you think? Can it be implemented as an out of the box solution
for that development model?
If you have another way to implement this development model, e.g. -
main stream for Release and Feature streams, please let me know.

In RTC-3.0.1, you will be able to load a stream into the Pending Changes
view, and directly deliver/accept changes between streams. This will
take care of the case where there are no conflicts. But when there are
conflicts, you would have to use a Merge workspace to resolve those
conflicts.


On 4/12/2011 10:08 AM, yaron wrote:

Hi, another comment.
You wrote: "In ClearCase, each developer always has their own
view. In the same
way, in RTC, each developer always has their own repository
workspace."

I think that that is one of the key differences.
In ClearCase indeed everyone uses his own view, but I used shared view
for the integration stream.
By that everyone could use that view for the deliver operation.
I do not have (yet) that capability in RTC.
That forces us to have multiple repository workspaces (one per user)
that their only purpse is to have an environment for deliver and
accept changes between the feature stream and the "main"
stream.

In RTC, a regular developer does not need a "development view" and an
"integration view" as they would in ClearCase UCM ... instead, they do
both development and integration activities in a single RTC repository
workspace.

When promoting changes from the feature stream to the main stream, they
would need to change their flow target to the main stream for the
promotion operation, but that's just for the duration of the promote.

Cheers,
Geoff