If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 19/Sep/13 02:10 AM
Updated: 20/Sep/13 12:38 AM
|
|
Component/s: |
None
|
Affects Version/s: |
5.0.14
|
Fix Version/s: |
None
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
Environment:
|
Windows
|
|
From time to time we have to clean the workspace for a configuration. e.g. This can happen if you stop a build during a subversion check-out and the working copy is broken. The configuration is unusable until it is cleaned and it often isn't possible to manually call subversion to clean up the workspace. The easiest way is to clean the workspace in Quickbuild but it completely locks the server down while the data is deleted, and no subsequent requests are responded to. For large workspaces, the server can be unresponsive for a long period of time (5+ minutes).
Why is it necessary for the server to deny all other server requests while this action is performed?
|
Description
|
From time to time we have to clean the workspace for a configuration. e.g. This can happen if you stop a build during a subversion check-out and the working copy is broken. The configuration is unusable until it is cleaned and it often isn't possible to manually call subversion to clean up the workspace. The easiest way is to clean the workspace in Quickbuild but it completely locks the server down while the data is deleted, and no subsequent requests are responded to. For large workspaces, the server can be unresponsive for a long period of time (5+ minutes).
Why is it necessary for the server to deny all other server requests while this action is performed? |
Show » |
|
You may consider to script pre-execute action of subversion checkout step to clean up workspace if previous build is canceled,or add an extra step before checkout step to call subversion clean up command under desired condition. Either way you do not need to do this manually each time a build is forcibly stopped.