Efficient switching between streams
Our engineers are actively developing the unreleased version 2.0 of our product, but still doing bug fixes on version 1.0 of our already deployed product.
A developer came to me today asking to create a 'common user' whose credentials would be used on a shared workstation so that the devs wouldn't have to change their workspaces in order to submit change sets to the 1.0 stream and then change back to continue work on the 2.0 stream. The dev said this would make their lives better, since switching workspaces takes a long time. Since I'm the Systems Engineer and Administrator, I have to be aware of issues of accountability. The suggestion of practically anonymous commits sounds like a bad idea, and hasn't been needed with the other SCM systems I've managed in the past. However, it is in our business's best interest to provide an environment where the devs can do their work efficiently, and these guys are usually pretty patient, so I believe it when they say that this is costing them time. Although I don't want to create a common user, I also have no better solution for them. Can someone in the forums comment on both my fears about sharing accounts, as well as whether there is some more efficient way of switching between streams on the devs' workstations? |
7 answers
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 16 '09, 10:13 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
WRT a "common user", your instincts are right ... that is never the
right answer in RTC. First thing to find out is what exactly the developer is referring to when they say "switching workspaces takes a long time". In particular, if they load their 1.0 and 2.0 repository workspaces into separate Eclipse workspaces, then it just takes a couple of seconds to switch (for the virtual memory to swap in and out). Cheers, Geoff jman wrote: Our engineers are actively developing the unreleased version 2.0 of |
Would changing the root folder of the project for each release be an
option? We're moving development of a product into RTC from PVCS. In PVCS, each subsequent release would be stored under a different project name in PVCS. Example, ProductX has two releases code named Foo and Bar. A singles component was created in RTC (name matches the product name of "ProductX"). The first release was imported into RTC and the root folder name set to "Foo"... a separate stream was created for this so maintenance could be done on the release. In the "Latest development" stream, the project root folder was changed to "Bar". As such, workspaces for both streams can be loaded as the same time. Brian |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 23 '09, 9:54 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Brian,
With RTC-2.0, you can load different workspaces into different folders in the file area, so there's no need to rename the project root folder to do this. But note that assuming you are using .project files, Eclipse won't let you load into the same Eclipse workspace two projects with the same name in their .project file. Cheers, Geoff Brian Gillan wrote: Would changing the root folder of the project for each release be an |
|
Thanks Geoff, In our case, I believe the project name is changed in the
..project file as well, for each new release. However, I think we will still have an issue for maintenance streams in the same release, so it's good to know this function is coming in 2.0. It should facilitate delivering changes to multiple streams for the same project. Brian |
|
Actually, after I thought about what you said, The RTC 2.0 function
won't help if you want to load two different workspaces associated with the same "project" (for example to do delivery to multiple streams associated with the same "project"). So, I'm wondering what benefit this will be? I guess it will be a benefit for cases where the work isn't being managed as an Eclipse project? Brian |
|
Geoffrey Clemm (30.1k●3●30●35)
| answered Apr 24 '09, 10:03 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Brian:
I'd strongly encourage you to find out from the developers why they think "switching workspaces" is expensive. It sounds like they have some notions of how things should be done based on using non-RTC SCM systems. For those other SCM systems, the only way to do a "compare" was to load both variants of the system into the same workspace, so they can select the two files and "compare" them. This is not the case with RTC ... it has a wide range of powerful compare capabilities, where you can compare the version you have loaded in your workspace with an arbitrary version in the repository (no reason to have those other versions loaded into your workspace). In particular, their unnecessary "workarounds" (changing the project name specified in each of their .project files for each release) will severely hamper any kind of inter-system or inter-release sharing (because of the introduced project name mis-matches and inconsistencies). It also disrupts the powerful compare capabilities of RTC, because of these unnecessary differences between the .project file contents. Cheers, Geoff Brian Gillan wrote: Thanks Geoff, In our case, I believe the project name is changed in the |
Our engineers are actively developing the unreleased version 2.0 of our product, but still doing bug fixes on version 1.0 of our already deployed product. Completely agree with your concern about the anonymous accounts. Geoff (as usual) has good ideas. Depending on how your RTC projects are set up - you might be able to use the Suspend/Resume capability. This might help "switching workspaces". Take a look at this (the Help does describe how this works)- and see if it will help your colleagues switch from 2.0 work to 1.0 work. anthony |
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.