It's all about the answers!

Ask a question

cross platform development

Todd Kornely (111) | asked Mar 06 '12, 5:49 p.m.
I have been been developing software for 15 years, and my company has switched to using RTC, and I am struggling to understand the expected workflow when trying to code, build and test a solution on multiple platforms.

I have no problems on Windows, which is my main development platform, but I also need to build and test on Solaris and Linux.

Here is my attempt at a reasonable workflow, and my typical use case.

1. Create clean, fresh workspace on Windows
2. Build, and install my product.
3. Load and build same workspace on Linux and Solaris, using the cmdline scm tools. Installing my software on those platforms too.
3. I code a solution for some defect I am working on, checking the changes into a CS and associating the CS to a WI. This is done on my main dev machine on Windows.
4. I build and test this on Windows.

No problems so far.

5. Now, since I am currently satisfied with my solution, I need to build and test on Linux and Solaris.

This is pretty much where I get stuck... How to 'import' these changes into the sandboxes on my Linux and Solaris machines?

I can get a bit farther if I skip step #3, and do fresh, complete build on Linux and Solaris, but what happens if my testing proves bad, or it doesn't build? How do I 'incrementally' build?

As you might have guessed, my product is very large, millions of lines of code, 50k+ source files, and takes hours to build and install. I can't be doing full builds all the time, and I don't want to have separate workspaces, as then I need to 'complete' my CS before acceptiing the changes. Many times I find problems on other platforms that make for a very iterative process, and I don't want to have dozens of changesets that makeup my solution( as these are then impossible to code-review, as the changes can be minuscule and there is no way to combine the CS's for review, right? ).

Please help!


One answer

permanent link
Tim Mok (6.6k38) | answered Mar 07 '12, 9:10 a.m.
You're allowed to create as many workspaces as you want. If you suspend the change set instead of completing it, you may resume the change set in another workspace. This allows you to "import" your changes to your other dev platforms.

In fact, using one workspace for multiple dev platforms isn't recommended. Your workflow will likely cause the sandboxes to be out of sync with the repository workspace. This means extra time to reload the projects that are out of sync.

As for building, I don't really understand the issue of full builds occurring. Accepting a change set only changes those files so your incremental build should detect which files have changed since the last build.

Having many change sets for review is also acceptable. Users can select multiple change sets and open them in the Change Explorer. This will aggregate the changes so that they can all be seen at the same time in the compare editor.

Your answer

Register or to post your answer.