A change set can only be modified by the owner. Multiple developers can work on the same file though. The changes can be merged.

If the modules are separate files, it is even easier to work on Function A concurrently. If they are in the same file, it may help to create module stubs and deliver it first. Then developers can use the stubs to work on his/her current module. If developers want to test out the changes from other developers, they can accept those change sets as long as they are closed.

Hi

In our current library system, we often have multiple developers work on different programs for the same deliverable. From what we've seen RTC does not exactly support this.

While I understand this could be handled as code in a separate stream that you then merge, this does seem a little overkill for what should be a relatively straight forward way of developing the code. For example;

Function A consists of
- module a
- module b

To make the necessary functional change one developer makes the changes to module a and another to module b.

Neither on their own would work and could break Function A and could only be unit tested when both changes are done.

You do not want to single thread the development as that reduces the time to value.

It is almost as if you need a 'Parent Change Set' that each of these developers have a 'Child Change Set' of.

Can this be done or is there a simple solution that can handle this.

Thanks, Nigel.

Is the goal to get the changes from one developer to another developer's workspace? If developer A needs a change set from developer B, developer B can close the change set and deliver it to developer A's workspace. Once the two change sets are tested, they can be delivered to stream.

Developer A can also accept developer B's change set as a patch and merge the changes into his workspace so they can be in one change set.

Or, both developers can create a side-stream and deliver changes to it without affecting the main stream. They can pick up the changes from each other through the stream. When the feature is complete, they can take those changes and deliver it all at once to the main stream. This will avoid breaking other developers or builds during this feature work.

While I understand the ease in which developers can work on separate files, that is not the issue. The problem is when the files are required to be tested together and promoted together, but are developed by separate people.

For example, one program is used to parse an entry that then passes it on to another program to action. They are both functionally useless without the other. If each takes a week to develop it either takes 1 person two weeks to develop or 2 people 1 week to develop. It is this latter example we want to sort out.

My understanding is that each developer will have their own workspace and the two cannot be combined to provide a way of joining these changes into a single change set that can be promoted.

Consider me a change set newbie! Not being able to develop this way seems poor and very un-Agile!

Thanks, Nigel

Note: You cannot deliver a change-set into a workspace owned by another
user. But the other approach ... accepting change sets from another
workspace works fine.

In particular, each developer add the other developer's workspace as a
"flow target". Then when you make that workspace the current target,
you will see incoming change sets (just the way you would from a
stream). When a developer is done with a change, they would complete
the change-set for that change.

The only thing that is clumsy here is that you can't tell by glancing at
the pending changes view when a change-set is ready for you to accept.
But you will find out when you click on "accept", because you'll get an
error message if the change-set is not yet completed.

But one thing you should also do is consider just adding a stream for
this collaboration. A stream in RTC is actually a very lightweight
object (it is one of the few objects you can delete), so you should free
to create as many of them as you need.

Just for interest's sake, why didn't you want to just create a stream
for this collaboration?

Cheers,
Geoff

On 11/12/2010 12:38 PM, tmok wrote:

Is the goal to get the changes from one developer to another
developer's workspace? If developer A needs a change set from
developer B, developer B can close the change set and deliver it to
developer A's workspace. Once the two change sets are tested, they
can be delivered to stream.

Developer A can also accept developer B's change set as a patch and
merge the changes into his workspace so they can be in one change
set.

Or, both developers can create a side-stream and deliver changes to it
without affecting the main stream. They can pick up the changes from
each other through the stream. When the feature is complete, they can
take those changes and deliver it all at once to the main stream. This
will avoid breaking other developers or builds during this feature
work.

NigelLHwrote:
While I understand the ease in which developers can work on separate
files, that is not the issue. The problem is when the files are
required to be tested together and promoted together, but are
developed by separate people.

For example, one program is used to parse an entry that then passes
it on to another program to action. They are both functionally
useless without the other. If each takes a week to develop it either
takes 1 person two weeks to develop or 2 people 1 week to develop. It
is this latter example we want to sort out.

My understanding is that each developer will have their own
workspace and the two cannot be combined to provide a way of joining
these changes into a single change set that can be promoted.

Consider me a change set newbie! Not being able to develop this way
seems poor and very un-Agile!

Thanks, Nigel

I'd suggest starting them with some suitably named collaboration stream
("Joe and Fred's Stream") ... not only is it the easiest way for them to
collaborate, but also it gets them used to the lightweight nature of RTC
streams.

And if they really can't deal with it, then fall back on the "use each
other workspace's as flow targets" approach.

Cheers,
Geoff

On 11/14/2010 2:23 PM, NigelLH wrote:

Hi Geoffrey,

Thanks for the detailed answer. The impression I had from some of my
colleagues was that streams were somewhat of an overhead that this
type of approach might simplify, but it might also be just a
reluctance to adopt a new way of working.

My feeling is that streams should handle it, but that the team have
still some way to go to understand and work with them.

Hence why I said I'd ask and see if this was actually possible.

Cheers, Nigel.