Is there a way to make automatic accept to private Workspace every morning?
3 answers
You can have a look at the SCM control line interface: http://pic.dhe.ibm.com/infocenter/clmhelp/v3r0/index.jsp?topic=%2Fcom.ibm.team.scm.doc%2Ftopics%2Fc_scm_cli.html
Comments
Each developer would need this script and some sort of scheduler on the developer's system to execute the script. This has its advantages where the sandbox can be updated and the developer would be ready to go in the morning. However, the developer would need the system to be running all the time.
Comments
For a build to accept changes into a repository workspace, the JBE needs to be logged into the server as the same user that owns the workspace. To have every developer's workspace updated every morning, there would have to be a separate JBE process running for each developer, and that JBE would have to know the developer's credentials (which could be a problem in some environments). There would be problems if accepting changes resulted in any merge conflicts. (I don't remember what the build does if there are merge conflicts, but I know that there is no mechanism for manual merges.) And even after the build accepts the changes into the workspace, the developer would still need to do something manually to get those changes into the sandbox on his local machine. While using builds to accept changes into workspaces could be made to work, I would not recommend it.
This wouldn't scale as you would need a build definition for each developer. It would also put each developer's sandbox out of sync with the repository workspace.
Comments
David Olsen
May 13 '13, 4:49 p.m.I would advise your customer to not do that. While it generally good practice to regularly accept changes into your development workspace, there are periods of time (often a few hours, but sometimes stretching to a couple days) where you do not want to accept any incoming changes (such as when you are deep into a serious debugging session). RTC makes it very easy for developers to accept changes, easy enough that decent developers will do it frequently. Automating the process is unlikely to save time and is more likely to lead to frustrated developers.
Tim Mok
JAZZ DEVELOPER May 13 '13, 4:56 p.m.It's certainly possible but the benefits might not be worth the trouble you create for yourself and your developers.
You run into potential problems of sandboxes out of sync with repository workspaces, losing unresolved changes, and scalability in deployment or maintenance.
Piotr's solution would have issues deploying to all your developers. The script would also need to run with the developer's credentials in order to run the accept on the workspace. The alternative is running with an admin account. If the script runs on a different system for all developers, you'll cause out of sync issues to your developers.
Josh's solution would run on a build engine and not the developer's system. This would cause out of sync issues and could mean every developer would have to reload out of sync projects every morning. The build only runs on one workspace at a time and post-build deliver only works on one stream/workspace. You run into scalability issues creating a build for every developer.