
Key: |
QB-644
|
Type: |
New Feature
|
Status: |
Resolved
|
Resolution: |
Won't Fix
|
Priority: |
Major
|
Assignee: |
Robin Shen
|
Reporter: |
Robin Shen
|
Votes: |
0
|
Watchers: |
2
|
If you were logged in you would be able to see more operations.
|
|
|
QuickBuild
Created: 26/Sep/10 12:30 PM
Updated: 11/Nov/10 01:33 AM
|
|
Component/s: |
None
|
Affects Version/s: |
None
|
Fix Version/s: |
3.0.7
|
|
Original Estimate:
|
Unknown
|
Remaining Estimate:
|
Unknown
|
Time Spent:
|
Unknown
|
|
From end user,
We have a problem with this scenario: A user submits a proof build. Local changes are copied to the agent. Also, on the agent, a sync with the latest changes happens. Code is compiled, but this may take 1 hour, for example. During that time, the developer might have changed his local files. Now, let's say the build is successful, and proof build was configured to submit code if build is successful. Quickbuild will submit the local code to Perforce, but since the local files were changed since the build was triggered, the copy to be submitted to Perforce is not the same as the local copy that was used to run the build.
For Perforce, there is a mechanism called shelving. Shelving has many usages, but proof build can be one of them. In shelving, a user can take his local changes, and place them on a 'shelve' on the server. They still remain checked-out locally, but they can be access by other users/processes via command line. So Quickbuild can use the users' shelved files to run a build, and if build is successful, QB can submit the files from the shelve. During that time, the user can continue to work and make changes to his local files.
You can read about P4 shelving in:
http://blog.perforce.com/blog/?p=1872
http://www.perforce.com/perforce/doc.current/manuals/cmdref/shelve.html
|
Description
|
From end user,
We have a problem with this scenario: A user submits a proof build. Local changes are copied to the agent. Also, on the agent, a sync with the latest changes happens. Code is compiled, but this may take 1 hour, for example. During that time, the developer might have changed his local files. Now, let's say the build is successful, and proof build was configured to submit code if build is successful. Quickbuild will submit the local code to Perforce, but since the local files were changed since the build was triggered, the copy to be submitted to Perforce is not the same as the local copy that was used to run the build.
For Perforce, there is a mechanism called shelving. Shelving has many usages, but proof build can be one of them. In shelving, a user can take his local changes, and place them on a 'shelve' on the server. They still remain checked-out locally, but they can be access by other users/processes via command line. So Quickbuild can use the users' shelved files to run a build, and if build is successful, QB can submit the files from the shelve. During that time, the user can continue to work and make changes to his local files.
You can read about P4 shelving in:
http://blog.perforce.com/blog/?p=1872
http://www.perforce.com/perforce/doc.current/manuals/cmdref/shelve.html |
Show » |
No work has yet been logged on this issue.
|
|