We are working with Integrity 10.5. I have seen that in 10.8, there are no project.pj files in the sandboxes anymore (all sandboxes kept in local database).
Does this mean that we could have multiple sandboxes (from the same project) in the same folder?
We are especially interested in having multiple sandboxes from different user PCs pointing to one sandbox on a network drive.
This could help replacing our shared sandboxes...
Any info is appreciated.
Hello Stephan Saul,
The project.pj database now exists in the client, which will prevent multiple sandboxes from that client from existing in the same sandbox. You could, of course, get around that by using a different client for each user, but that operation is not supported. You'll note that shared sandboxes also no longer exist in Integrity 10.8.
I'm curious to know what your use case is for having multiple users using the same sandbox directory? Is it really something that you can't get from each user having their own sandbox(es)?
we used shared sandboxes as described here Integrity 10.7: Shared Sandboxes deprecated - PTC Community
Why is "using a different client for each user" not supported?
Hi Stephan Saul,
In the future, you checkpoint your code and create an immutable build sandbox on the network for your field guys to flash from. Your developers can collaborate on branched development paths and merge those changes back to the mainline when QA is happy with how the branch tested. Since you can create a build sandbox of any checkpoint including a non-mainline development path, you don't even have to merge back to allow the field guys to get it, just create the build sandbox on the network drive. Since it's a build sandbox, it should be immutable (all read-only), so you don't have to worry about someone changing things compared to what's in the checkpoint.
As I mentioned, shared sandboxes are gone as of ILM 10.8.
A different client for each user on the same sandbox directory isn't supported because trying to figure out why a build is failing from that sandbox when it worked in a clean sandbox involves too many variables and is easy to prevent in the first place. Development sandboxes are intended for one user to use, and that reliability goes out the window when more than one user is using a sandbox at the same time.
Even shared sandboxes were only intended for one user, just possibly working from different locations (e.g. office computer and home computer via VPN or PPP).
What you've done sort of works, and would probably continue to work in the future, but only if your developers are very careful with what they do, and don't take extra efforts not to clobber each other's changes.
Hi Kael Lizak,
Your proposed solution has one drawback for us:
The build sandbox on the network will be created and maintained by a most probably different user (maybe an admin) than the user adding his new software for production.
That means additional overhead for the build sandbox owner - he must react on every action that any user does on the project.
This was easier with a shared sandbox (and would be with multiple sandboxes in the same network folder) - the user could add his new software for production without any need for a build sandbox owner to react.
Hello Stephan Saul,
Yes, I can see how that could be a problem. Coming up with an automated deploy solution would work around it, but that takes time. That's probably why someone in the other thread suggested Jenkins.
Thanks for sharing that background with us. Those of us in Support don't always get as good an understanding of the big picture issues our customers face as we would like.