(1) When you right click on a stream or repo workspace in Eclipse, you
get to pick an arbitrary stream or repo workspace ... the "loaded" ones
are just used to give you a couple of easy picks (use search strings to
find others). When I do a compare (in 3.0) in Eclipse, I see all
change sets that differ listed under each component, and am given the
option of showing the changes as "files" rather than change sets.

(2) You might have multiple workspaces if you are concurrently working
on multiple platforms (it's best to have a given workspace loaded into a
single sandbox at any one time). Or if you are concurrently working on
two significantly different changes, and want to keep those
configurations "cached" in two different Eclipse workspaces.

(3) The term "local workspace" is deprecated. The correct term is
"sandbox". And it is almost never a good idea to have multiple
sandboxes concurrently associated with the same repository workspace,
because refreshing a sandbox after the repository workspace has been
updated by a different sandbox is very slow.

Cheers,
Geoff

On 2/7/2011 5:53 AM, swatoon wrote:

Hi,

Few questions to clarify.

1. I can only see the details of comparison between 2 loaded
repository workspace. I can't seem to compare an unloaded repository
workspace with a stream/repository or compare 2 streams. The change
explorer only shows the components. How do I expand to view the
changesets?

2. Under what typical scenarios do we create multiple repository
workspaces of a single stream?

3. Under what circumstances is it beneficial to create multiple local
workspaces of a single repository workspace?

Thanks.

Hi Geoff,

I am also looking at multi-stream development and hope to clarify how it works.

Here's the flow diagram scenarios I come across

1. Acme_wkspc_tim_dev -> Acme-Development -> Acme-release_1-1 -> Acme-release-1-0

Just want to confirm that this does NOT imply that whenever Tim delivers his changesets to Acme-Development, the changes will automatically be delivered to Acme-release_1-1 and Acme-release-1-0. Tim will still have to change his repository workspace flow target to Acme-release_1-1 or Acme-release_1-0 if he wants the same changes to be applied to that stream. Is that correct?

2. Acme_wkspc_alan_dev --> Acme-release-1-0 (dotted link)
Acme_wkspc_alan_dev -> Acme-Development (default and dotted link)

Here we have 1 repository workspace pointing to multiple streams (release 1.0 and Development)

Assuming Alan is working on the development stream and a fix is required for release-1-0. But the repository workspace contains the development code base. Apart from changing his flow target to point to the Acme-release-1-0, what does he need to do to change his repository workspace code base to that of Acme-release-1-0? Hope I am making sense here.

Also, what exactly does default link mean here? Does it imply that it is the first stream linked to that particular workspace repository?

Thanks for your clarification.

1) Correct. Changes only flow into a stream through an explicit
"deliver" operation (either through the GUI or through a script).

2) If a workspace has multiple stream flow targets, you have two choices
WRT how this is shown in the Pending Changes view (configured by your
preferences):
- one at a time (the default, and the simpler display ... you issue a
"change flow target" operation to see your workspace's relationship with
a different flow target)
- all at once. Makes it easier to get an overview of your workspaces
relationship with all of its targets, but therefore a more complex display.

But then back to your question, two of your choices when you change to a
different flow target are:
- accept incoming changes form the new flow target ... this effectively
"merges" within your workspace the content of the new flow target with
the previous content of your workspace from the previous flow target
(this is probably the most common choice). You would then deliver the
results of the merge (once you have resolved any merge conflicts) to one
or both of your flow targets.
- "replace" the contents of your workspace with that of the new flow
target. This gives your workspace the state it would have if you'd
never had the first flow target as a flow target.

The "default" marking on a flow target is just your way of telling the
GUI what flow target you "normally" deliver your changes to. If you
execute a "deliver" operation to any of your non-default flow targets,
the GUI will pop up a confirmation box saying "are you sure you want to
deliver to a non-default target". Note that this is the *only*
semantic effect for the default marking.

Cheers,
Geoff




On 2/7/2011 9:53 AM, erwl88 wrote:

Hi Geoff,

I am also looking at multi-stream development and hope to clarify how
it works.

Here's the flow diagram scenarios I come across

1. Acme_wkspc_tim_dev -> Acme-Development -> Acme-release_1-1
-> Acme-release-1-0

Just want to confirm that this does NOT imply that whenever Tim
delivers his changesets to Acme-Development, the changes will
automatically be delivered to Acme-release_1-1 and Acme-release-1-0.
Tim will still have to change his repository workspace flow target to
Acme-release_1-1 or Acme-release_1-0 if he wants the same changes to
be applied to that stream. Is that correct?

2. Acme_wkspc_alan_dev --> Acme-release-1-0 (dotted link)
Acme_wkspc_alan_dev -> Acme-Development (default and dotted
link)

Here we have 1 repository workspace pointing to multiple streams
(release 1.0 and Development)

Assuming Alan is working on the development stream and a fix is
required for release-1-0. But the repository workspace contains the
development code base. Apart from changing his flow target to point
to the Acme-release-1-0, what does he need to do to change his
repository workspace code base to that of Acme-release-1-0? Hope I
am making sense here.

Also, what exactly does default link mean here? Does it imply that it
is the first stream linked to that particular workspace repository?

Thanks for your clarification.