It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,785
×6,076

question asked: May 12 '13, 2:59 a.m.
question was seen: 5,159 times
last updated: May 16 '13, 6:14 a.m.

Related questions

FAQ - How this Forum works

Is there a way to make automatic accept to private Workspace every morning?

0
Ziv Rechnitser (9●1●16●18) | asked May 12 '13, 2:59 a.m.
 Hi All,

My costumer want that every morning the developers will get all the latest change sets automatically.
Is there a way to do so? I  thought about a batch file that will do an automatic accept, is it possible?

Thank,

Ziv.
Comments
David Olsen commented 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 commented May 13 '13, 4:56 p.m.
JAZZ DEVELOPER

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.

3 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Piotr Aniola (3.7k●1●17●38) | answered May 13 '13, 5:24 a.m.
edited May 13 '13, 5:26 a.m.
If a batch file is a solution for you, then it's definitely possible.
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
Tim Mok commented May 13 '13, 4:39 p.m.
JAZZ DEVELOPER

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.

0
permanent link
Ziv Rechnitser (9●1●16●18) | answered May 16 '13, 6:14 a.m.
Thank You all,

I think the best solution will be to try motivate the client to drop this idea.
-1
permanent link
Josh Crawford (984●6●15) | answered May 13 '13, 4:13 p.m.
edited May 13 '13, 4:14 p.m.
 Hi Ziv,  another option would be to create a build definition that has the Jazz Source Control pre build participants (like Command Line JBE) that runs on a schedule everyday.   You can tell it to automatically accept the changes here:


Comments
David Olsen commented May 13 '13, 4:40 p.m.

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.

Tim Mok commented May 13 '13, 4:41 p.m.
JAZZ DEVELOPER

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.

Your answer

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.