Why am I unable to accept a change set into a downstream release in an Eclipse Project?
Wendy Murphy (151●26●33)
| asked Jan 31 '14, 12:09 p.m.
retagged Jan 31 '14, 1:56 p.m. by Sonia Dimitrov (271●5●9)
We have parallel development with two major code streams v10 and v11. The code base structure is identical. We started in SVN and migrated the code base by release into RTC. What we found was our eclipse projects have no top level folder that retains the Project Name. Our code structure is top level so when the .project file is read in every release has the same name.
We tried the work around of using the package explore to locally separate our releases using the load as function. As developers load multiple releases from streams into a one local sandbox. We make a change in v10 and want to accept that changeset into the v11 workspace. With the above configuration this works. But developers have to constantly do the load as and set locally the project names in their package explore as we do not have a top level directory that reflects a unique Project Name. We tried creating a top level directory to apply the project name and re imported the code bases so we have top level v10 top level v11 the code structure is the same below that top level in both releases we make a change and deliver to v10 we go to the work item change our workspace to v11 and do accept of the change set into the v11 workspace. Nothing happens.... We are guessing that because the changeset has kept the top level directory and it is unique it can't resolve the path so it does nothing. How do you do parallel development if you can't deliver from one stream to another because of the project top level directory? We have found the only solution is to remove the top level directory and then we are back to the overhead for developers to make them unique in package explorer? |
Accepted answer
Arne Bister (2.6k●1●28●32)
| answered Jan 31 '14, 4:29 p.m.
JAZZ DEVELOPER edited Jan 31 '14, 4:30 p.m.
Wendy,
first, you can reduce any overhead with "Load As ..." by doing it once, creating load rules and then have everybody load with load rules instead. This is described in article 1015. As for "reimporting" the code into a new top level directory - I believe the correct way should be to do a move in the SCM system (from with in Eclipse). Then delivering change sets between streams should work as before, independent on which version of the directory structure they have. What RTC version are you using? In case you continue having the delivery trouble, please open a defect on jazz.net and attach some screenshots of the steps you took so this can be resolved. You might find more valuable info in article 1016. If this answers your questions please mark it as accepted answer. Thanks, Arne Wendy Murphy selected this answer as the correct answer
Comments thanks for the response we just figured out the load road scenario and are much better off now thanks. I appreciate the link to the information as well. |
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.