Branching or baselining strategy - for selective build

Hi All,
Currently we have flow-targets set between streams and these are shared between developers. So, when we want to baseline and build a set of changes - which would not be latest ones - based on requirement - its causing problems as the baseline flows to the incoming streams of other developers as well - and if they accept it, it will overwrite the latest changes with older versions.

Whats the best strategy in this scenario to achieve selective builds? Is it good to create a snapshot and build on it? - which is easier?

I'm not quite sure what you mean by overwriting the latest changes with older versions. Do you mean the developer sees an incoming baseline that has changes that are old and unwanted?

It sounds like you'll be ok accepting the baseline. It will put the baseline into the developer's workspace history and include any changes in that baseline. If there are change sets built on the changes in that baseline, those new change sets don't get overwritten.

Hi All,
Currently we have flow-targets set between streams and these are shared between developers. So, when we want to baseline and build a set of changes - which would not be latest ones - based on requirement - its causing problems as the baseline flows to the incoming streams of other developers as well - and if they accept it, it will overwrite the latest changes with older versions.

Whats the best strategy in this scenario to achieve selective builds? Is it good to create a snapshot and build on it? - which is easier?

If you want to build something that isn't the latest in the stream, it is best to create a new repository workspace or maybe even a new stream to hold the stuff that you want to build.

I can't give more precise advice because your description is somewhat vague. I don't understand exactly what you are doing or what problems you are running into.

--
David Olsen | IBM Rational | Jazz Process Team

Hi Dolsen,
I was also thinking of creating a seperate repository workspace only. We want to do a selective build - but currently, since flow-targets are set - once a baseline is created - its visible for all developers in their incoming stream - accepting which would overwrite their latest changes - and they would be developing on a older version.
meaning, the baseline is not the latest set - but its beet cut to do a build alone.

Thanks.

I was also thinking of creating a seperate repository workspace only. We want to do a selective build - but currently, since flow-targets are set - once a baseline is created - its visible for all developers in their incoming stream - accepting which would overwrite their latest changes - and they would be developing on a older version.
meaning, the baseline is not the latest set - but its beet cut to do a build alone.

That's what I don't get. I can't picture how you are setting things up so that you run into this problem. How are your flow targets set up? Why are the other developers seeing the baseline with the older stuff as an incoming change to their own repository workspaces? If you are creating a separate repository workspace to use to build the older stuff, how are baselines getting from that workspace into other streams and workspaces? Does accepting the suspect baseline into a workspace really wipe out all the newer changes, or does it just add that baseline to the set of baselines and change sets that are already in the workspace?

--
David Olsen | IBM Rational | Jazz Process Team

Hello David,
The scenario is:
Say, there is a shared functional stream and 3 developers are working on it. So, when developers check-in something to the stream, it will be available to other developers in their incoming. Baseline created has to be put into the shared stream - so that build managers can use it for the build - at this point, this change would be available to all the developers as well.

Change Override meaning:
Say, Baseline is cut off by me - after accepting some changes - if other developers accept this baseline by mistake, it would override the latest changes with the baseline versions - which is not ideal for them - they would still want to work with the latest changes.

Say, there is a shared functional stream and 3 developers are working on it. So, when developers check-in something to the stream, it will be available to other developers in their incoming. Baseline created has to be put into the shared stream - so that build managers can use it for the build - at this point, this change would be available to all the developers as well.

The baseline with the older stuff should not be delivered to the stream that is supposed to have the latest stuff. That changes the purpose of the stream. If you need a stream in order to run the build, then create a new stream to hold the older stuff.

I can only give general advice because I feel like we are using slightly different definitions for some terms. I still don't have a good sense of your setup or exactly what you are trying to do.

--
David Olsen | IBM Rational | Jazz Process Team