Jump to content

mysterious file deletions after rollback, sync


  • Please log in to reply
1 reply to this topic

#1 sdiverdi



  • Members
  • Pip
  • 2 posts

Posted 28 September 2015 - 01:43 AM

I'm experiencing a very strange behavior with perforce (using p4v) that I can't understand, hoping someone can shed light on the situation.  I have a depot with a last good CL, call it CL 1000, and a few bad CLs afterwards (head is CL 1005, doesn't build).  I'd like to rollback to CL 1000, and it's not working.  Here's what I did before:

1) Start a new workspace.
2) Sync to head, CL 1005.
3) Create rollback CL to 1000.
4) Auto-resolve all files to keep the target.
5) Check that it builds now.
6) Submit rollback CL.

That all seems fine, right?  But then, I sync to head again and some files are deleted, breaking the build!  How is that possible?  I just submitted the latest CL (and no other CLs have been submitted in the meantime, I'm the only one working on this depot for now).  Here's what I've done to repeat the behavior:

1) Sync to head (CL 1006 now, which should be the same as CL 1000).
2) Check that it doesn't build.
3) Create another rollback CL to 1000.
4) Auto-resolve all files to keep the target.
5) Revert all unchanged files, which reverts all the files in the CL.
6) Check that it builds now.
7) Sync to head -- files get deleted again!
8) Check that it doesn't build anymore.

Also, if I create two new workspaces and sync one to CL 1000 and the other to CL 1006 (which was the rollback to 1000 CL), I can do a diff on the directories and see that there are files missing from 1006.

It may be important that the missing files all have a @ in the name.  This is an xcode project where the higher resolution image resource files are tagged with @2x, so like spinner.png and spinner@2x.png.

Any ideas what's wrong here?  I want to completely restore the depot state to the point of CL 1000 and then move forward from there, but the commands I'm using don't seem to be achieving that result.

#2 sdiverdi



  • Members
  • Pip
  • 2 posts

Posted 28 September 2015 - 06:45 PM

Looks like I figured out the problem here, and it was the files with @ in the name.  At CL 1000, there was a file in the depot, say //spinner@2x.png, and in CL 1001 that file was removed.  Unfortunately, it seems the rollback command in p4v is unable to handle this case properly.  What it does is sync to 1000, open files for edit, or add or delete, then sync to head and resolve keeping the workspace versions.  The problem is when opening files for add, it fails to add files with @ in the name, giving an error that -f is needed, but there's no way for the rollback command to specify this flag.  I had to manually re-add the files (to do this, I went through my steps above: sync to head, rollback, resolve, revert unchanged, and then instead of syncing to head again, I did p4 sync -n to see which files would be deleted, and then added them with p4 add -f).

This seems like a bug in the rollback command, or at least a feature request for the future!

Also tagged with one or more of these keywords: rollback

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users