|
|
|
[
Permlink
| « Hide
]
Robin Shen [17/Nov/14 07:03 AM]
Forget to mention that the "reconcile after build" option in advanced setting of perforce repository does this in QB 5.1
The custom plugin may override repository.buildFinished to do cleanup work in this case.
At my workplace, we use both Git and Perforce. Git has had `git clean` and `git reset --hard HEAD` for years, and Perforce recently added `p4 clean` (which is like a combination of those two git commands)
In the case of Perforce, it's not necessarily sufficient to simply revert open changelists. Files can be deleted from disk without first opening them for delete, and files can be changed on disk without opening them for edit. Also, many files can be created as part of the build, and these will likely not be opened for add, but should be deleted as part of this feature. The challenge that I see with this, at least with some configurations that I've "inherited" from somebody else, is that we sometimes have multiple repositories being synced to the same root directory (i.e. the workspace directory). We might be able to change this in some cases, but not in all cases. It might be possible to interrogate all repositories for each file to see which repositories claim to own the file, and to only delete it if none of the repos claim the file. If only one repository claims ownership, and that repo says that the file needs to be re-synced, you could re-sync that file. And if multiple repos claim ownership, maybe that's an error. Maybe my use case is so specific that this feature can ignore it. Most people probably have a single repository or, if they use multiple repos, they probably keep them isolated in separate subdirectories of the workspace. Those would be reasonable choices. I've actually started working on a custom step to handle this for Perforce repos (since that's the most common type that we have here), but the current (well, 5.1.22) base Repository class makes it hard to create a general solution. It would need to support this notion of "what steps would need to be taken to revert this repo to a 'clean' state", which I don't believe is currently there (there is a "revertLocalChange" method, but that appears to be specifically for proof build support and doesn't handle the Perforce-specific cases that I outlined above). |