Going through this step by step:
A user syncs to the #head and "file.txt" is at version 8 (file.txt#8).
The file is in their workspace at version #8. It is not open for any action.
Another user submits a change such that in the depot, it's now "file.txt#9".
The file is still in the user's workspace at version #8, still not open.
The first user shelves file.txt#8
Wait -- how did the user shelve it without opening it? I'm going to fill in a gap here and assume that they:
- opened the file for edit (
p4 edit)
- made a change to the file (so now it has a change relevant to
file.txt#8). I'll call this "change X".
moves to another directory where he syncs the head of the whole depot (including file.txt#9). That workarea now has #9.
Wait -- is this another directory within the same workspace, or is this a whole different workspace? If it's the same workspace, it doesn't matter that they're in a different directory. Since you say that they have file.txt#9 I'll assume it's another workspace, since I'm already assuming that the file is open in the original workspace and a sync wouldn't actually pull down the new revision if the file was already open.
I'll call the original workspace "client A" and this new workspace "client B".
Then he does a p4 unshelve and file.txt#8 is now in the default changelist.
Okay, cool. So now the state that we're in is that the file has been effectively synced back to file.txt#8, and it's open for edit, and the workspace has change X in it. When you unshelve a file, it's always synced to the same version that it was shelved at, even if you previously had a later version synced in the workspace. (If you previously had a later version synced and opened, then the unshelve immediately schedules a resolve instead, but that's not what happened in the case you're describing.)
In other words, with respect to file.txt, client A and client B are in the exact same state. It's open at #8 and change X is in the workspace.
At this point, the user is worried about a conflict with something that might have slipped in after #8, so he does a "p4 resolve -am". What would you expect to see at that point ?
Nothing happens, because the file is still synced to #8. A resolve isn't scheduled until you sync to the newer revision that requires resolution. (This allows you to choose which revisions you resolve and when -- if multiple newer changes have been submitted, you can "cherry-pick" which ones to resolve by syncing only those changes, or resolve all of them together by syncing to #head.)
And I'm wondering if we have to "schedule" a resolve by doing some sort of sync after the unshelve. But if we do the sync, will the changes in file.txt#8 still be preserved somehow or will the sync clobber them ?
Yes, you have to do the sync, and no, the sync won't clobber X, because it's open for edit. Sync will schedule the resolve, and the resolve's job is then to merge #9 (theirs) with X (yours).
The fact that the change got there via an unshelve is immaterial -- the important thing is that when a file is open for edit at an older revision, syncing to a newer revision schedules a resolve against that revision. You'll see the same behavior whether you do this in client A or client B, because both have the exact same state (file open at #8).
