CODEWITHSUNDEEP
perforce
Rob Gordon
Rob Gordon

Reputation: 68

Can't delete a user due to an orphaned changelist

While trying to delete a user through the Perforce Admin program, I think that put us into an odd state where we can't delete the user due to an existing changelist, but we can't revert the changelist because the workspace no longer exists. Here is a chain of command line calls that illustrates the state we are now in:

# try to delete the user
C:\>p4 user -fd swilson
User swilson has file(s) open on 1 client(s) and can't be deleted.

# Show files opened for edit by swilson
C:\>p4 opened -u swilson
//depot/ProjectName/UnityProjects/ProjectSettings/EditorSettings.asset#1 - edit change 174603 (text) by swilson@repo

# Try to delete the changelist
C:\>p4 change -fd 174603
Change 174603 has 1 open file(s) associated with it and can't be deleted.

# Try to revert the changelist server-side
C:\>p4 revert -k -c 174603 //...
Change 174603 belongs to client repo.

# Try to revert it again, this time specifying the mystical "repo" workspace
C:\>p4 revert -k -c 174603 -C repo //...
repo is a depot, not a client.

# Attempting to change client field of changelist
C:\>p4 change -f 174603
Error in change specification.
Change has files open, client cannot be modified.

As far as we can tell, the "repo" client/workspace is not a client/workspace that exists.

It also isn't a depot either as a "p4 depots" in the command line didn't show a "repo" entry.

An attempt to create a workspace named "repo" so that I could revert the changelist fails with the error "repo is a depot, not a client".

Given that the changes in this changelist do not need to be retained, how can we clean up the changelist so that we can delete the user? For bonus points, what is this "repo" workspace?

Upvotes: 0

Views: 1569

Answers (1)

Samwise
Samwise

Reputation: 71542

The thing of files being open on a client that doesn't exist and can't exist because it's already a depot is pure evil. I'm not sure how that mad genius swilson managed to get files into that state, but it's pretty hard to get out of it since renaming a depot is not a lightweight operation. (Note I'm assuming that repo is an active depot; if it's not, delete that sucker and create a client by that name and I think you're home free.)

My approach here would be to just journal-surgery it. Grep a checkpoint for db.working and db.locks entries for swilson (there should be one of each, corresponding to that one open file), replace @pv@ with @dv@, play 'em in with p4d -jr. No more evil open file.

Upvotes: 0

Related Questions