# Sample Workspace Cleanup

Here's a sample of a big one-liner to clean up old pending CLs in a workspace prior to deleting it. This was done on an old 13-year old iMac used for many years with many pending CLs to clean up.

## BLUF (Bottom Line Up Front)

The command was:

```
for c in $(p4 -ztag -F %change% changes -s pending -c ttyler.P4Public.P4iMac.sdp); do if [[ $c == 28518 ]]; then echo Skipping this one: $c; continue; fi; for j in $(p4 -ztag -F %Job% fixes -c $c); do echo p4 -s fix -d -c $c $j; p4 -s fix -d -c $c $j; done; echo p4 -s shelve -d -c $c; p4 -s shelve -d -c $c; echo p4 -s change -d $c; p4 -s change -d $c; done 2>&1 | tee clzap.log
```

## Features

* Illustrates exempt CL -- 28518 in this example.
* Deletes job fixes associated with pending CLs.
* Deletes shelves.
* Deletes pending CLs.

## Automation Considerations

If this were extended to better, more generic automation, the following would be considered.

* Revert files. (This had already been done in earlier iterations of the command above in this example, so wasn't needed).
* Safety: Do preflight checks to ensure the job fix to be removed was NOT the last fix for the given job.  Explanation: In a typical code review flow, pending CLs have fixes associated with them early on, when work starts.  Then later the change is shelved; the review CL is created and a job the job fix is associated with the review CL.  So there are 2 fixes for the job.  Then when the review is approived, that job fix is passed on to the submitted CL. At that point there are 3 fixes for the job, the "real" one associated with the submitted CL, the useful one associated with the review CL that's part of the review history, and then superfluous one associated with the pending CL in the workspace where the change originated.  This latter fix is to be cleaned up during this review process.  If it turns out the fix we're deleting is the last one...that means it's not typical, and deleting the fix may actually warrant further investigation.
* Add Summary