Create Sandbox inside a Sandbox now possible?!?

[mrump]

Hello all,

I've been using Integrity for years now and recently got a little confused.

One thing seemed to be craved in stone, when it comes to creating a sandbox:

"You cannot and must not create a sandbox inside (below) and existing sandbox".

The Sandbox creation dialog, prevents this "possibly dangerous" usage, by checking the target directory and it's parent directory for an already existing *.pj file.

This strategy did not change officially:

• I checked the release notes back to 2009 and up to I10.6.
• I checked all user and admin manuals up to 10.6 I could find.

Nevertheless in our current 10.6 installation, we can create a sandbox wherever we want. The only warning that is shown by Integrity occurs when creating two sandboxes in the same directory that have the same name for the .pj file (e.g. "project.pj").

Are we facing a bug, or is this "works as designed" ?

If so WHEN did the traditional design change and WHY?

Any Ideas ( different or same experiences ) are welcome.

Thank you in advance Matthias

[KaelLizak]

Hello Matthias Rump‌,

When I try to create a new sandbox in an existing sandbox, I get "MKS125327:  The operation could not be completed because the new sandbox already exists." with both Integrity 10.5 & 10.8.

Regards,
Kael

[JoeBartlett · Accepted solution]

Maybe we need some clarification. That error appears if you attempt to create a sandbox inside a directory where a project.pj file already exists. Example, if you have the below project structure:

/Top/project.pj

     Sub1/project.pj

A sandbox for this project could exist on the filesystem like "C:\Sandbox\Top\Sub1" with project.pj files in the Top and Sub1 folders.

However, let's create a new subfolder within the Sub1 directory called "UnderSub1": C:\Sandbox\Top\Sub1\UnderSub1

If we attempt to create a new sandbox within the UnderSub1 folder, it is successful (at least in 10.7 when I tried). I think this is the way the behavior has always worked but if the second scenario used to produce that error, then it could be investigated.

EDIT: Confirmed this is the same behavior in Integrity 2009 SP7.

[mrump]

Thanx for the fast reply     

The Scenario is as follows:

I have a Sandbox:

/Top/project.pj

       /Sub1/project.pj

                /UnderSub 11/project.pj

                /UnderSub 12/project.pj

       /Sub2/project.pj

                /UnderSub 21/project.pj

                /UnderSub 22/project.pj

Now I create a new sandbox  at

/Top/project.pj

       /newSandbox/Project.pj

more or less "in between" the others.

[JoeBartlett]

This scenario would also result in no error message since the new sandbox folder "C:\Top\newSandbox" would not have any project.pj files inside.

This is not new, but nesting in this way is strongly recommended against since if the user decided to drop the "Top/project.pj" sandbox and delete everything, then they would also lose the contents of the newSandbox folder.

[mrump]

So this behaviour is by design. check

Does any one know a reasonable use case that would be worth the risk?

[kthierer]

One reasonable use case i could imagine:

    ..../App/project.pj (regular subsandbox)

    ..../App_Build_1.3/project.pj  (Build Sandbox)

This way you can use your favourite difftool to compare the current state with a previous build resp. checkpoint.

     Jürgen

[kthierer]

BTW there are even more risky resp. odd things you can do wih subprojects on Integrity 10.4

d:\PtcTest>si createsubproject --project=d:/Server/PtcTest/project.pj ./project4.pj

project4.pj is then a subproject of project.pj but is on the same "directory level" than project.pj

after this some CLI-commands get confused

d:\PtcTest>si projectinfo

Implicit sandbox is ambiguous

Enter the project name:

*** A value for "--project" is required.

You can even add subprojects to project4.pj

d:\PtcTest>si addsubproject --project=d:/Server/PtcTest/project4.pj d:/Server/PtcTest/aaa/project.pj

All this things can also be done with the GUI.

Any ideas for a reasonable use case?