Importing tasks into another workspace

[pkstormy]

We have 3 workspaces – dscexe-dev, dscexe-prod, and dscsxe-tst. Since I started here (05/08/06), I’ve been receiving several tasks from the developers to promote to the dscsxe-tst workspace and have successfully promoted all of them to dscsxe-tst through RoundTable. The problem is that these tasks should have also been promoted to dscsxe-prod (which was not known until now.) I have a 2 page step-by-step document I’ve been following on promoting tasks to the dscsxe-tst workspace (but nothing describes how to promote them also to dscsxe-prod).

Now we want to promote all the tasks which were promoted to the dscsxe-tst workspace to the dscsxe-prod workspace (which I have a list of about 20 tasks). What I’ve learned so far about RoundTable is that once you promote a task, it is no longer available to import again to promote (see error below when I select the dscsxe-prod workspace and try to build task 757 to import and then compile the files – I also get this if I were to try and import the task again into the same workspace). I have the import analysis reports on all the files which were compiled. I also have a Workspace Differences report on the PCODE files between dscsxe-prod and dscsxe-tst. I’m not sure how the dscsxe-prod workspace was created – only that I need to promote all the same tasks which were imported/compiled to dscsxe-tst.

I’m still learning RoundTable (I’ve read the manual a couple of times now trying to understand the process) and have no clue on how to go about this. Do you have any suggestions? (preferably a beginner’s step-by-step guide).

 

[doreynie]

I'v worked with roundtable for about 2 - 3 years. And the problem you mention there's is what I'v encountered also. More, we had 5 workspaces...

As far as I know, there are 2 solutions for that :

1. (I'm not sure about this (never did it, read the manual please...)) Make your workspace where the tasks were created, a source for your last workspace. Then you can Import the tasks from ws1 to ws3. But, this is dangereous, because in your lowest workspace, you don't work with releases, so it's possible that you import a version of a program, that isn't tested yet.

2. A far safer solution (the one I used all the time) : Someone completes a task in WS1. You import this task in WS2. Immediately after you imported this task in WS2, you make a release, and you name this release after the task you just imported (as a reference for future use). Then, when you're ready to import the task to ws3, you import by release, and not by task. You mention the correct release in the import action, and roundtable compares all the files from WS2, with the files from ws3, upto where roundtable 'flagged' the release. So even if there are newer versions available of one source in WS2, roundtable knows the previous version, because in his release list, he has the reference to the previous version.

Got it?

Maybe my explanation isn't that understandable, but try it with a simple example,and you should get it...

Dominiek

 

[jeffledbetter]

In 9.1D and greater, you do not have to directly source a workspace in order to import from it. It just needs to be in the sources of the workspace from which you are importing.