We may get issues with shelves that fail to delete, e.g.:
Failed to remove shelved CL 2658688
Executing: p4 -s shelve -df -c 2658735
error: No shelved files in changelist to delete.
exit: 1
Failed to remove shelved CL 2658735
Executing: p4 -s shelve -df -c 2658756
error: No shelved files in changelist to delete.
exit: 1
Failed to remove shelved CL 2658756
I don't know how to fix these. Maybe a journal patch???
When we delete a user that's the last in a group:
Removing User 'ralph'.
Executing: p4 -s user -df -F -D -y ralph
error: User ralph is the last member of group ProjectXWrite and cannot be deleted.
error: Delete the group via 'p4 group -d -F ProjectXWrite', then try again.
exit: 1
Error: Failed to remove user 'ralph'.
To fix these: If we get that specific error message "User <User> is the last member of group <Group>", then we spew the user spec, add the fixed user name 'p4admin' as an Owner of the group. This should make it so p4d does not complain about removing the last user of a group.. Then try the 'p4 -s user -df -F -D -y <User>' command again. Then if it still fails, report that as an error and move on.
Attempting to delete depots with 'p4 -s depot -d <Depot>' fail to delete depots. In our scenario here, when those whose file paths have been eliminated via path-based replication filtering, give errors indicating they're not empty, even when they effectively are. This may require a journal patch to delete the depot spec from at least the db.domain table.
For this, a one-liner journal (one line per depot) patch may be needed.
So, for any depot the script fails to delete with the front door method (i.e. the 'p4 depot' command), we append to a journal patch file.
In the summary, we should not that a journal patch has been created, and what applying that patch will do (e.g. "Applying journal patch will delete 15 depots."
The journal patch should be called something like trim_excess_metadata.<timestampe>.jnl, created in the directory the script was executed from, with the full path to the patch being displayed when the file is created, and again in the summary at the end.
Some jobs may refuse to be deleted because they're associated with changelists. (Digression: In P4 parlance, a "fix" (ala p4 fix and shown by p4 fixes) is a link between exactly one job and exactly one changelists. The relationship between jobs and changelists is inherently many:many, so a changelist that has 3 jobs associated with it will have 3 fixes. A job that a dozen changelists associated with it will have a dozen fixes.) If p4d refuses to delete jobs due to existing fixes, just delete all relevant fixes first, then delete the job happens, delete the associations with p4 -x fix -d -c <CL> <Job> for each reported fix. To list the jobs, do something like:
for FixCL in $(p4 -ztag -F "%Change%" fixes -j "$Job"); do p4 -s fix -d -c "$FixCL" -j "$Job" done
But do that with the style of the trim_excess_metadata.sh script, i.e. using the cmd() function to make calls that affect data.
After all jobs are deleted, reset jobspec to p4d default. That's stored in the default_jobspec.p4s file, and can be loaded with:
p4 -s jobspec -i < default_jobspec.p4s
Delete ALL server specs EXCEPT for p4d_ffr_gf:
for ServerSpec in $(p4 -ztag -F %ServerID% servers); do
[[ "$ServerSpec" == p4d_ffr_fg || && continue
p4 server -f -d "$RemoteSpec"
done
Delete ALL remote specs. This is similar to removing labels and branches. Unlike labels and branches, we don't need a "Keep" file for remote specs -- blast them all.
List remote specs with something like:
for RemoteSpec in $(p4 -ztag -F %RemoteID% remotes); do
p4 server -f -d "$RemoteSpec"
done
Scan Protections, and:
p4 protect -o | grep -v ^# | grep -v ^Update:<AccessLevel> group <KeptGroup> or <AccessLevel> user <KeptUser>. Delete all other lines.super user p4admin 127.0.0.1 //... and super user perforce 127.0.0.1 //...# To Do for Trimming
## Known Trimming Issues
### Some Shelves Cannot Be Deleted
We may get issues with shelves that fail to delete, e.g.:
Failed to remove shelved CL 2658688
Executing: p4 -s shelve -df -c 2658735
error: No shelved files in changelist to delete.
exit: 1
Failed to remove shelved CL 2658735
Executing: p4 -s shelve -df -c 2658756
error: No shelved files in changelist to delete.
exit: 1
Failed to remove shelved CL 2658756
I don't know how to fix these. Maybe a journal patch???
### Some Users Cannot Be Deleted
When we delete a user that's the last in a group:
Removing User 'ralph'.
Executing: p4 -s user -df -F -D -y ralph
error: User ralph is the last member of group ProjectXWrite and cannot be deleted.
error: Delete the group via 'p4 group -d -F ProjectXWrite', then try again.
exit: 1
Error: Failed to remove user 'ralph'.
To fix these: If we get that specific error message "User <User> is the last member of group <Group>", then we spew the user spec, add the fixed user name 'p4admin' as an Owner of the group. This should make it so p4d does not complain about removing the last user of a group.. Then try the 'p4 -s user -df -F -D -y <User>' command again. Then if it still fails, report that as an error and move on.
### Most Depots Cannot Be Deleted
Attempting to delete depots with 'p4 -s depot -d <Depot>' fail to delete depots. In our scenario here, when those whose file paths have been eliminated via path-based replication filtering, give errors indicating they're not empty, even when they effectively are. This may require a journal patch to delete the depot spec from at least the db.domain table.
For this, a one-liner journal (one line per depot) patch may be needed.
So, for any depot the script fails to delete with the front door method (i.e. the 'p4 depot' command), we append to a journal patch file.
In the summary, we should not that a journal patch has been created, and what applying that patch will do (e.g. "Applying journal patch will delete 15 depots."
The journal patch should be called something like trim_excess_metadata.<timestampe>.jnl, created in the directory the script was executed from, with the full path to the patch being displayed when the file is created, and again in the summary at the end.
## New Features
### Handle Jobs
* Delete ALL P4 jobs
* Some jobs may refuse to be deleted because they're associated with changelists. (Digression: In P4 parlance, a "fix" (ala `p4 fix` and shown by `p4 fixes`) is a link between _exactly one_ job and _exactly one_ changelists. The relationship between jobs and changelists is inherently many:many, so a changelist that has 3 jobs associated with it will have 3 fixes. A job that a dozen changelists associated with it will have a dozen fixes.) If p4d refuses to delete jobs due to existing fixes, just delete all relevant fixes first, then delete the job happens, delete the associations with `p4 -x fix -d -c <CL> <Job>` for each reported fix. To list the jobs, do something like:
for FixCL in $(p4 -ztag -F "%Change%" fixes -j "$Job"); do
p4 -s fix -d -c "$FixCL" -j "$Job"
done
But do that with the style of the trim_excess_metadata.sh script, i.e. using the cmd() function to make calls that affect data.
* After all jobs are deleted, reset jobspec to p4d default. That's stored in the default_jobspec.p4s file, and can be loaded with:
p4 -s jobspec -i < default_jobspec.p4s
### Handle Typemap
* Reset triggers to p4d default (empty triggers table). That is simply the word Typemap followed by a colon on a line, and nothing after.
### Handle Triggers
* Reset triggers to p4d default (empty triggers table). That is simply the word Triggers followed by a colon on a line, and nothing after.
### Handle Server Specs
Delete ALL server specs EXCEPT for p4d_ffr_gf:
for ServerSpec in $(p4 -ztag -F %ServerID% servers); do
[[ "$ServerSpec" == p4d_ffr_fg || && continue
p4 server -f -d "$RemoteSpec"
done
### Handle Remote Specs
Delete ALL remote specs. This is similar to removing labels and branches. Unlike labels and branches, we don't need a "Keep" file for remote specs -- blast them all.
List remote specs with something like:
for RemoteSpec in $(p4 -ztag -F %RemoteID% remotes); do
p4 server -f -d "$RemoteSpec"
done
### Help With Protections Table Cleanup
Scan Protections, and:
* Capture the initial Protections table with: `p4 protect -o | grep -v ^# | grep -v ^Update:`
* Keep any line that looks like: `<AccessLevel> group <KeptGroup>` or `<AccessLevel> user <KeptUser>`. Delete all other lines.
* Append a line to the end: `super user p4admin 127.0.0.1 //...` and `super user perforce 127.0.0.1 //...`
| # | Change | User | Description | Committed | |
|---|---|---|---|---|---|
| #2 | 32740 | C. Thomas Tyler | Added more details in ToDo.md, and supporting files. | ||
| #1 | 32735 | C. Thomas Tyler | Added set of needed fixes. |