Working with a shared sandbox

You could do that, but it would be simpler just to have two different
repository workspaces, each with their own sandbox. Then you don't have
to shut one down in order to work on the other platform (and don't need
to mess with shared storage).

Cheers,
Geoff


On 10/25/2011 10:23 AM, yaron wrote:

Hello,
I have a project that is multi- platform developed.

I Thought to create a repository workspace for a user from Linux and
locate the sandbox at a shared storage, such as NetApp.

then development done by:

1. Open Eclipse from Linux and use RTC.
Exit Eclipse wokspace (to avoid lock)
2. Open Eclipse from windows (same eclipse workspace and sandbox).

Is it supported?

If not, what is the best practice for multi- platform development?

Thanks,

Yaron

Hi,

A -
I have tried the following :
Create the sandbox from linux on shared storage.
Use same workspace from windows.
When using this sandbox from windows I have got some unexpected errors:
1. error message such as "not a known sandbox"
2. unresolved files from Linux did not appear as "unresolved" using the same sandbox from windows.

Do you know whether this configuration was tested?
I also suspect that there are unix/win "/" issues within the changeset that can cause to problems.

B -
I have adopted the 2 repositories solution - one for each platform.
I have tried the following:
Linux - change and create a changeset
Windows - Try to accept the changeset for mltiplatform development.
** you can not "accept" unless you "complete" the changeset from Linux.
So, the procedure for a user that should perform that activity becomes:
- change at Linux
- "complete" the changeset.
- go to windows and "accept"
- back to linux - and use a new changeset.

Please note that you'll create a new changeset each time you'll "switch" environment.
We will finish with lots of changesets that from the user perspective should be ONLY one chnageset.

Now, When you would like to "take" this change to other stream you'll need to "take" all those chnagesets.
__________________________________________

Is there a better solution for that scenario?
ClearCase solution was: Create dynamic view at Linux. mktag at windows --> start working.

Thanks,

Yaron

You can suspend the change set and resume in the other workspace without closing it.

Thanks for the response.
So, is this the reccomended solution for a multiplatform development?
User will have seperate workspaces, and share information using suspend?

If not,

What is the basic procedure for handling that scenario?

Yes, that would be the recommended solution.

Note that the flow is slightly smoother if you do the suspend from the
Eclipse workspace that currently holds the change set. But if you
forget to do so, you can do the suspend from any Eclipse workspace ...
when you return to the original Eclipse workspace, it will tell you to
"resync" the workspace ... that will apply the suspend to the original
file area.

Cheers,
Geoff

On 10/29/2011 12:23 PM, yaron wrote:

Thanks for the response.
So, is this the reccomended solution for a multiplatform development?
User will have seperate workspaces, and share information using
suspend?

If not,

What is the basic procedure for handling that scenario?

Thanks,

I am not convinced that it will be a good solution.
Note that when "resync" the workspace the user may loose his all Unresolved ("temp") work.

Lets start over:
Use case is: user develops same software on both Linux and Windows environment.
What is the RTC configuration that he should use?

Thanks again,

Yaron

Use case is: user develops same software on both Linux and Windows environment. What is the RTC configuration that he should use?

Use multiple repository workspaces, i.e. treat the user as two users. You can btw have two repository workspaces even if you only develop on one machine, this makes it easier to test your own changes in separation from other changes (yes, RTC offers a build engine, which can be used for the same goal, but that's beside the point). You can also flow changesets between workspaces, just remember that you don't "deliver" but only "accept". Delivering is basically useless, see work item 179832.

Uli

Hi,

It looks like we are trying to find solutions that will only fit the constrains of RTC.

The need is very simple:
The user needs to develop same set of files from both platforms.

Now, because RTC uses Eclipse as the "Source Control GUI" and because of the way that RTC manages it, the user should do the following:

1. Have two separate environments on disk and two repositories.
2. use different changesets (yes, they can be linked to one WI).
3. Every "switch" to other environment (by deliver / accept) will cause the changeset to be "completed", and there is a need to create new changeset.
4. Share all the time with deliver / accept, instead of just work on share disk / sandbox.
5. If you use the "accept" between repositories, you have to remember to first perform "complete" to the changeset you want to accept (from the other Eclipse client and other platform.

Yes, you can do it, but I think that it is not a good solution to introduce to the users.

Yaron

When I do multi-platform development myself, I just use one workspace,
on one machine and have multiple build engines, one for each platform I
want to build on. Is there a reason why you want/need to do your
actual editing from each platform?

Cheers,
Geoff

On 11/1/2011 7:08 AM, yaron wrote:

Hi,

It looks like we are trying to find solutions that will only fit the
constrains of RTC.

The need is very simple:
The user needs to develop same set of files from both platforms.

Now, because RTC uses Eclipse as the "Source Control GUI"
and because of the way that RTC manages it, the user should do the
following:

1. Have two separate environments on disk and two repositories.
2. use different changesets (yes, they can be linked to one WI).
3. Every "switch" to other environment (by deliver / accept)
will cause the changeset to be "completed", and there is a
need to create new changeset.
4. Share all the time with deliver / accept, instead of just work on
share disk / sandbox.
5. If you use the "accept" between repositories, you have to
remember to first perform "complete" to the changeset you
want to accept (from the other Eclipse client and other platform.

Yes, you can do it, but I think that it is not a good solution to
introduce to the users.

Yaron

Hi,

The reason is that the user is developing at both environments (Linux / win).
He is developing with QT. He performs changes at Windows and then check it also at Linux and would like to be able to perform changes there as well.
Using the other option (different repositories)- he would be needed to deliver - accept each time.