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:
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:
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
Solved! Go to 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.
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
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.
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.
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.
So this behaviour is by design. check
Does any one know a reasonable use case that would be worth the risk?
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
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?