| 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 » |
|
Change by Robin Shen [11/Nov/10 01:33 AM]
|
| Field |
Original Value |
New Value |
|
Status
|
Open
[ 1
]
|
Resolved
[ 5
]
|
|
Resolution
|
|
Won't Fix
[ 2
]
|
|
Only commit file revisions submitted for proof build when QuickBuild commits local changes
1. If unshelved files are modified against old versions, committing at QuickBuild server side will require to resolve/merge first which is not appropriate to be done at server side.
2. if unshelved files are committed successfully at server side:
2.1 files modified after shelving will be put into a conflict state if sync with p4 server.
2.2 files not modified after shelving can be synced with p4 server, and then can be put into a clean state with "reverted without changes" function. However for file rename/move operations, if this operation is submitted at server side, the developer workspace can not be put into a clean state with this approach. Developer needs to determine if the modification can be reverted safely (ie. not renamed/moved/modified again after shelving) in this case and then sync with p4 server.
Do you have any idea on how to work around these difficulties?