How to do parallel streams?
Sorry if these questions have been asked before. I've carefully read the InfoCenter and searched the forum, but I still don't quite get it. I'm pulling my hair out to find a crisp definition of how this works. I would be happy to read any pointers you can give me.
I currently have one stream, trunk. All the developers' workspaces have trunk as the flow target. It has been working great thus far, but we are at the point where we need to grow. What I want to have is a separate stream, "v1". The idea is that v1 represents trunk at the time of our first customer deliverable. It's a branch. We want to continue active development for future deliverables on trunk, but v1 basically gets quiet after v1 ships, while the future action is happening on trunk. However, a customer may find a bug in v1. We'd like to be able to load v1 into a workspace, fix the bug, and deliver a changeset of the fix to v1. In most cases, we may want to propagate the same changeset to trunk. I'm pretty sure there will be a few cases where we don't want to propagate a fix from v1 to trunk. But I don't think we'll want to propagate changesets in the opposite direction from trunk to v1 - maybe but unlikely. I currently have 4 components, and all 4 components are in trunk. Specifically, when I open the definition for the trunk stream it says that the stream has baseline #1 (Initial Baseline) for all these components. I haven't changed which baseline that this stream uses, even though months and hundreds of Delivers have gone by. Is this normal, or should I update the component list in trunk to use more recent baselines? Since we are using the RTC build engine, it appears that new baselines are implicitly being created for each build. From reading other posts, it appears it is recommended that we use the same component in each stream, as opposed to creating a new component in each stream for its different version of the same source code. Makes sense. So I set up a v1 stream in RTC. Compared to trunk, how should I select the components to be added into v1? Should I select baseline #1? Or do I pick a baseline implicitly created by the build that we actually shipped? Or do I select from a snapshot? If one of the latter two, how do I achieve true parallel development if the development team works on the big next version on trunk while some souls continue to polish v1 before it ships? Coming from perforce/cvs/svn, basically what I am is how does the branch occur? Are there changelists that get piled on top of a baseline in the v1 stream that don't flow back to a different baseline in the trunk stream? When I try to add baseline #1 of my components to v1 (which are already in trunk), then I get an error during build: "TeamRepositoryException: Component xyz is accepting changes from multiple flow targets." Is each baseline in a component essentially a branch? Or is each baseline a point along a single linear collection of changelists? I understand that changesets don't flow directly from stream to stream, a transitory workspace must be between them. So to propagate a bug fix changeset from v1 to trunk, I load the transitory workspace, set the workspace flow target to v1, accept the bug fix as an Incoming changeset, set the workspace flow target to trunk, and Deliver the same changeset which should be in the Outgoing list, correct? Anything else I need to be aware of, or better ways to do this? If I mature a bit more and have a test team that wants to test code from trunk that is known to be stable instead of random points in time on trunk, I could set up a trunk-stable stream. So when I get a build on trunk that I'm pleased with, should I promote a snapshot of it to trunk-stable, and then do a build of trunk-stable for the test team? Or is there a better way to share stable builds? Sorry to take up bandwidth here, but the InfoCenter and even the article http://jazz.net/library/article/40 doesn't really explain it satisfactorily. Thanks in advance for your help! |
5 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Feb 26 '10, 5:23 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Comments below:
marcelk wrote: I currently have one stream, trunk. All the developers' workspaces All good so far. But I don't think we'll want to Correct. I currently have 4 components, and all 4 components are in trunk. If you created baselines in the stream, they would be there. If you created them in a workspace, and then delivered them to the stream, they would be there. But note that there is no requirement that you have any baselines in the stream after the initial one. Since we are using the RTC build engine, it appears that new baselines A build creates a snapshot, which in turn creates baselines. But unless you explicitly deliver those baselines to the stream, they will just stay local to the build workspace. From reading other posts, it appears it is recommended that we use the Yes, that is a must, or you won't be able to flow changes between these streams. So I set up a v1 stream in RTC. Compared to trunk, how should I select Any of the above is OK, but I'd suggest creating a snapshot of trunk, and then when adding the components to v1, select the baselines in that snapshot. If one of the latter two, If you do anything other than the snapshot approach I describe above, then the first thing you will need to do after creating v1 is to accept the trunk into some workspace, and then deliver that workspace to v1. This will make v1 up-to-date wrt the current state of trunk (assuming that's what you want ... if you want to start v1 at an earlier state of the turn, configure your workspace to contain that earlier state of the trunk, and deliver that. Coming from perforce/cvs/svn, basically what I am is how does the Yes ... change sets don't flow from v1 to the trunk unless you explicitly deliver them to the trunk from some workspace. When I try to add baseline #1 of my I've never gotten that error message, so we may need the RTC SCM guys to explain it, but look at the flow targets of your build workspace ... if there are more than one, delete all but the one you want it to get its baselines from. Is each baseline The latter ... a point along a single linear sequence of change sets. I understand that changesets don't flow directly from stream to Nope, you got it right. Note that you don't need to create a new workspace when you want to do this ... just have some repository workspace (I'd suggest calling it a "promotion workpspace") with trunk and v1 as its flow targets (trunk being the default flow target), and use that workspace whenever you need to promote a change set from v1 to trunk. If I mature a bit more and have a test team that wants to test code Having a separate trunk-stable stream for the "good build" snapshots is very reasonable. Cheers, Geoff |
marcelk wrote:
I currently have one stream, trunk. All the developers' workspaces To create stream v1, you start with a snapshot, probably a snapshot that was created by the build that you want to be your branch point. That will populate stream v1 with the correct components and the correct content. Once stream v1 is created, development happens normally. Developers doing v1 work will have a repository workspace that flows with stream v1. They will check in and deliver their changes to the v1 stream just like they would with the trunk stream. There are several ways to get the v1 changes into the trunk stream. Different strategies work better for different teams. My recommendation would be that developers who make v1 changes also be responsible for getting those changes into the trunk stream. In many cases, the same change set can be delivered to both streams without any conflicts or merges. (To do this, the developer would go to his trunk workspace, open the work item that has the v1 change sets attached, accept those change sets into his trunk workspace, make sure everything still works, and deliver to trunk.) Sometimes, when the files in question already have newer changes in trunk, additional merge change sets will need to be created to get the original change sets delivered into the trunk stream. Once in a while, the trunk stream changes will be significant enough that the original change sets can't be delivered and entirely new change sets will have to be created for the trunk work. It is also possible to have a dedicated person whose job it is to migrate changes from the v1 stream to the trunk stream, rather than leaving it up to each developer. The procedure would be essentially what you described: In a workspace that is synchronized with the trunk stream, change the flow target and accept changes from the v1 stream. Do any necessary merges, fixing, and testing, and then deliver the changes to the trunk stream. when I open the definition for the trunk stream it says It is normal for the stream to not contain any baselines. Don't worry about it. Though it won't do any harm to occasionally create baselines and deliver them to the stream, if that will make you feel better. A baseline is nothing more than a set of change sets. It's just a snapshot of the state of a component within a workspace or a stream at a particular point in time. From reading other posts, it appears it is recommended that we use the Yes, definitely. You do not want to create new components simply to do parallel development. If I mature a bit more and have a test team that wants to test code You could create a trunk-stable stream and occasionally replace its contents from a snapshot of a build that you are pleased with. But I would recommend that testers simply create a new workspace from the build snapshot. Repository workspaces are relatively easy to create and destroy. I don't see that having a trunk-stable stream will buy you much. |
|
Many thanks! These answers have been tremendously helpful. I have now successfully created a branch, created workspaces for those branches, created build definitions for those branches, and promoted a change set from a branch to trunk.
The product docs (ie InfoCenter) just aren't helpful for these topics, they are way too thin. I'd suggest that they include a scenario on parallel streams that does a walkthrough and provides explanation like what is in this forum entry. |
Hi,
Thank you Marcel for the question, I am currently facing the same dilemma... The answers did help but there are still a few practical questions I would like addressed. Article http://jazz.net/library/article/40 seems to imply that it is easy to swap between the trunk stream and stream v1 by simply changing the flow target through the same workspace. I have tried this and while it works it seems a bit messy and prone to errors. Assuming same developer is working on both trunk and v1, scenario as follows: 1 Set my flow target to v1, apply a simple 'bug fix 1' change and deliver (to v1) 2 Set flow target to main trunk, get asked to deliver change made in step 1 (which I don't) - I discard those changes and make a simple 'feature 1' change and deliver 3 Set flow target back to v1, get asked to deliver changes made in step 2 (which I don't) - I discard changes and have to accept changes made step 1. As can be seen above this approach relies on a constant discarding and accepting of changes each time the flow target is redirected which will get very confusing as those changes/developers increase. I realise that there might not be a way around this but wanted to confirm; was this the intended approach suggested in article http://jazz.net/library/article/40 or am I supposed to have seperate (local and remote) workspaces for trunk and v1? What is the recommended as best parctice? Is there an article or any other material that explains in a bit more detail how this is done? Thanks, Francois |
As can be seen above this approach relies on a constant discarding and accepting of changes each time the flow target is redirected which will get very confusing as those changes/developers increase. It's easier to have multiple remote workspaces. Discarding is an unnecessary step. If the two streams are similar, then you can keep the same local workspace and load them when you switch collaborations. Our load will only download different resources, so the load and subsequent build should be quick. If the two streams are quite different, it's probably worth keeping two different local workspaces as well. If the two streams are dramatically different (a 1.0 versus a 2.0 release, for example), then the load and build will take longer than changing your eclipse workspace. e |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.