Automatic change flow between streams?
I would like to have 2 source code streams where one is a subset of the other (is one has all the components, the other has a subset of components). I want to keep the common components in sync between the 2 streams. Is there a way to have changes flow automatically between the 2 streams (either in one direction or both)?
6 answers
amulholl wrote:
No. A person needs to use a repository workspace to move the changes
between the two streams.
If there are no merge conflicts, it's pretty easy to do. I think it's
nine mouse clicks to synchronize changes both ways. It becomes more
involved if there are merge conflicts. It would be nice if this could
be more automated, but the lack of this feature shouldn't be a show stopper.
I would like to have 2 source code streams where one is a subset of
the other (is one has all the components, the other has a subset of
components). I want to keep the common components in sync between
the 2 streams. Is there a way to have changes flow automatically
between the 2 streams (either in one direction or both)?
No. A person needs to use a repository workspace to move the changes
between the two streams.
If there are no merge conflicts, it's pretty easy to do. I think it's
nine mouse clicks to synchronize changes both ways. It becomes more
involved if there are merge conflicts. It would be nice if this could
be more automated, but the lack of this feature shouldn't be a show stopper.
There is no built-in mechanism for this, but you probably could
implement something like this as a post-delivery process hook.
Alternatively, you could just document in the rules of the road for that
project that users should declare in their workspaces that the common
components flow from a common stream, while the non-common components
flow from different streams. Then no "automatic flow" is needed.
Cheers,
Geoff
amulholl wrote:
implement something like this as a post-delivery process hook.
Alternatively, you could just document in the rules of the road for that
project that users should declare in their workspaces that the common
components flow from a common stream, while the non-common components
flow from different streams. Then no "automatic flow" is needed.
Cheers,
Geoff
amulholl wrote:
I would like to have 2 source code streams where one is a subset of
the other (is one has all the components, the other has a subset of
components). I want to keep the common components in sync between
the 2 streams. Is there a way to have changes flow automatically
between the 2 streams (either in one direction or both)?
Hi Geoff,
Is it possible to configure build engine from two streams then? Any example?
Regards,
Roman
Is it possible to configure build engine from two streams then? Any example?
Regards,
Roman
There is no built-in mechanism for this, but you probably could
implement something like this as a post-delivery process hook.
Alternatively, you could just document in the rules of the road for that
project that users should declare in their workspaces that the common
components flow from a common stream, while the non-common components
flow from different streams. Then no "automatic flow" is needed.
Cheers,
Geoff
amulholl wrote:
I would like to have 2 source code streams where one is a subset of
the other (is one has all the components, the other has a subset of
components). I want to keep the common components in sync between
the 2 streams. Is there a way to have changes flow automatically
between the 2 streams (either in one direction or both)?
The workspace used for a build is declared in the build definition. To
use the "shared component" approach, you would configure this build
workspace (using the RTC workspace editor) to flow the appropriate
components with the appropriate streams. When you select the "accept
before build" option, it will accept changes from the declared flow
target for each component. Note that you need to be careful to have
only a single flow target (stream) for a given component, or else the
stream to accept from will be ambiguous.
Cheers,
Geoff
roman.smirak wrote:
use the "shared component" approach, you would configure this build
workspace (using the RTC workspace editor) to flow the appropriate
components with the appropriate streams. When you select the "accept
before build" option, it will accept changes from the declared flow
target for each component. Note that you need to be careful to have
only a single flow target (stream) for a given component, or else the
stream to accept from will be ambiguous.
Cheers,
Geoff
roman.smirak wrote:
Hi Geoff,
Is it possible to configure build engine from two streams then? Any
example?
Regards,
Roman
gmclemmwrote:
There is no built-in mechanism for this, but you probably could
implement something like this as a post-delivery process hook.
Alternatively, you could just document in the rules of the road for
that
project that users should declare in their workspaces that the
common
components flow from a common stream, while the non-common
components
flow from different streams. Then no "automatic flow" is
needed.
Cheers,
Geoff
amulholl wrote:
I would like to have 2 source code streams where one is a subset of
the other (is one has all the components, the other has a subset of
components). I want to keep the common components in sync between
the 2 streams. Is there a way to have changes flow automatically
between the 2 streams (either in one direction or both)?
Ok, but only one stream can be set as current - does it mean "Accept all" function checks out the latest changes from all streams configured (= flow targets of the workshpace)?
What if there is any conflict between streams?
Or shall I replace component manually (Remove component from workspace definition, Add new from stream...) without configuring Flow target?
Thanks!
Roman
What if there is any conflict between streams?
Or shall I replace component manually (Remove component from workspace definition, Add new from stream...) without configuring Flow target?
Thanks!
Roman
The workspace used for a build is declared in the build definition. To
use the "shared component" approach, you would configure this build
workspace (using the RTC workspace editor) to flow the appropriate
components with the appropriate streams. When you select the "accept
before build" option, it will accept changes from the declared flow
target for each component. Note that you need to be careful to have
only a single flow target (stream) for a given component, or else the
stream to accept from will be ambiguous.
Cheers,
Geoff
I'm not an expert at this (so I hope the build gurus will correct me if
I'm wrong), but my understanding is that when you set the "accept before
build" option on your build, it will accept from all the flow targets,
not just the "current" one. So you should configure your flow targets
to be "selective" (i.e. only flow with specific components), and make
sure that no two flow targets flow with the same component.
Cheers,
Geoff
roman.smirak wrote:
I'm wrong), but my understanding is that when you set the "accept before
build" option on your build, it will accept from all the flow targets,
not just the "current" one. So you should configure your flow targets
to be "selective" (i.e. only flow with specific components), and make
sure that no two flow targets flow with the same component.
Cheers,
Geoff
roman.smirak wrote:
Ok, but only one stream can be set as current - does it mean
"Accept all" function checks out the latest changes from
all streams configured (= flow targets of the workshpace)?
What if there is any conflict between streams?
Or shall I replace component manually (Remove component from workspace
definition, Add new from stream...) without configuring Flow target?
Thanks!
Roman
gmclemmwrote:
The workspace used for a build is declared in the build definition.
To
use the "shared component" approach, you would configure
this build
workspace (using the RTC workspace editor) to flow the appropriate
components with the appropriate streams. When you select the
"accept
before build" option, it will accept changes from the declared
flow
target for each component. Note that you need to be careful to have
only a single flow target (stream) for a given component, or else
the
stream to accept from will be ambiguous.
Cheers,
Geoff
roman.smirak wrote:
Hi Geoff,
Is it possible to configure build engine from two streams then? Any
example?
Regards,
Roman
gmclemmwrote:
There is no built-in mechanism for this, but you probably could
implement something like this as a post-delivery process hook.
Alternatively, you could just document in the rules of the road for
that
project that users should declare in their workspaces that the
common
components flow from a common stream, while the non-common
components
flow from different streams. Then no "automatic flow" is
needed.
Cheers,
Geoff
amulholl wrote:
I would like to have 2 source code streams where one is a subset of
the other (is one has all the components, the other has a subset of
components). I want to keep the common components in sync between
the 2 streams. Is there a way to have changes flow automatically
between the 2 streams (either in one direction or both)?