Posted 27 May 2015 - 07:07 PM
My team has been experiencing some strange file behavior from Perforce these past couple of months and I can't seem to track what could be causing it.
The problem we have been experiencing is with files being submitted after several revisions, and then opened for edit, only to find that the file has reverted or rolled back to a previous revision before all of their most recent changes were made. Since it appears to be happening multiple times with different files, I thought I would ask if anyone could tell me what might be the cause of this, or if anyone else has experienced this and found a solution; without having to go back and redo hours of work? I want to make clear the fact that the intention was not to submit a rollback. All submissions were made with recent updates to those files.
I've thought about just doing a simple rollback to the most up to date version, but that still means re-changing things that should already have been changed in those files. If possible, I'd like to find out why the most up to date files in the depot are being overwritten with older versions of that file. It's been causing us quite a bit of grief. I'm pretty sure my team is familiar with Perforce workflow by now and how to submit their changes, so I don't think it can be chalked up to the usual user error, but maybe I'm wrong.
In any case, if anyone could shed some light on what might be going on, I would greatly appreciate the assist!
Posted 27 May 2015 - 09:11 PM
Sorry you are having file issues. To know which file operations have been done (who reverted the file and when etc), the server log can tell us these details, but let's see if we need to go there yet.
Knowing the following will help us better trouble-shoot and be able to check for solutions for your specific environment and version:
a] Which version of the server and client are you using? (See version details in P4V Help -> System Info)
b] You mentioned the files went through a 'Rollback'. If you select the file in P4V and do View -> History, does the changelist description have the actual text 'Rollback' in it to confirm this was done?
c] Does your server have any +Sn file type modifiers enabled? To confirm, what is the command output of:
p4 typemap -o
- How To Rollback An Integration
- Backing Out Submitted Changelists
- Backing out a changelist after multiple subsequent changes
Posted 27 May 2015 - 10:53 PM
A.) Client Version:Perforce Visual Client/NTX64/2014.3/1007540
Server: P4D/NTX64/2014.2/978861 (2014/12/19)
B.) Unfortunately not. This would be far simpler if it was a simple rollback call that was done intentionally. No in our case it seems that the file was reset to it's original state when it was first added to the Depot; In all the cases this has happened this has been the same. And there was no description in the file history about a deliberate rollback.
C.) Well this is embarrassing. I didn't want to have to ask this but it appears I have no other alternative since all of my searches are not turning up anything helpful. How do I input that command using P4V?
Posted 27 May 2015 - 11:05 PM
As for C], no need to be embarrassed. This is done on the command-line and is information about a server setting that is not displayed in P4V. If you have the p4 command line client installed, you can right-click a file/folder in P4V and from the context menu select 'Open Terminal Window Here' and then type the command. If you are using Windows, the context menu item may have slightly different text.
Can you please send the file history for one of these files in question? You can either send a screen-shot of the file history from P4V (Select file and then click menu View -> History; OR Select file and right-click and select from the context menu 'File History'); Or you can run the command:
p4 filelog //depot/path/to/filename
from the command line and copy and paste the output to send.
Posted 27 May 2015 - 11:24 PM
Don't know if this will display correctly, but here is one that happened most recently. The file that is highlighted is the troublemaker. I also have another that has a longer history and was worked on by multiple people where this has also occurred if you would like to see that too.
Posted 28 May 2015 - 05:56 PM
1) File is synced to an older revision (or file is synced to head before changes are submitted from another workspace).
2) File is checked out and modified (or not).
3) File is either submitted or synced. This will schedule a resolve.
4) File is resolved with the "accept yours" option. (This is important -- the user needs to explicitly choose "accept yours" to discard "their" changes.)
5) File is submitted.
The point at which the newer changes are discarded is step 4, where the user does the required "resolve" and opts to ignore the newer changes. With a text file you'd handle this by doing a "merge"; with an unmergeable binary file this isn't an option, which would explain why users are doing "accept yours" instead (even though this means losing the other users' changes).
To prevent this situation there are two things you can do:
1) Make sure to "get latest" on files before checking them out. You're probably already doing this, since Perforce will warn you about checking out files that aren't already up to date in the workspace, and I think P4V will even prompt you to sync them prior to checking them out.
2) Don't edit binary files concurrently. Again, Perforce will warn you when you're checking out a file that someone else has already checked out, but users might be ignoring this. You can force the issue by changing the file type to "binary+l", which forces exclusive checkouts -- once one user checks out a file, everyone else is blocked from checking it out until they either revert or submit.
Posted 01 June 2015 - 04:11 PM
Posted 01 June 2015 - 06:23 PM
p4 edit -t binary+l yourfile.fbx
Also tagged with one or more of these keywords: Rollback, Revert
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users