Posted 19 January 2018 - 01:35 PM
I have two branches, BranchA and BranchB. I create File1.txt in BranchA and integrate to BranchB
I then move File1.txt to a new directory: Dir2
I then make changes to the file.
I then integrate to BranchB and get this error while integrating:
"open for read: BranchB\Dir1\File1.txt: The system cannot find the file specified."
The file in the new folder has not been marked for add in BranchB. The old file BranchB\Dir1\File1.txt is marked for delete, but needs a resolve. When I try and resolve I get the same error.
So in summary, the file was integrated to a new branch, then moved to a new directory in the original branch, then edited in the original branch, and then I try and integrate to the other branch again. I'd expect that the file in the branch would be marked for delete in the old directory, and add in the new directory. However, it's not marked for add, and the delete needs a resolve which I can't get to resolve.
I was on version 2015.2 of the server and P4V when this problem happened. I've tried updating to 2017 but I still have the same problem. All moves and integrates are being done from P4V using the default options. I've tried resolving using source and target from both P4V and the p4 command line, but nothing will work. Let me know if I can provide any more information.
Can anyone suggest a way to fix this and allow me to integrate and resolve?
Thanks for any help.
Posted 19 January 2018 - 04:36 PM
If you can't remember how to recreate the integrate, revert the file and re-run the integrate (from the command line preferably so you have control over exactly what gets executed and can see the exact output). Note that since you're on 2015.2 the integrate command needs to include both files (so you'll want to integrate using a branchspec and maybe a change specifier, not on a single file) -- I think it's as of 2016.1 you can just do the integrate on the BranchA/Dir2 file and it'll do the transitive cleverness to find BranchB/Dir1.
Posted 19 January 2018 - 06:02 PM
I'm integrating from the branch spec in P4V, this is the command line it uses:
p4 integrate -b BranchB
The BranchB branch spec has the old and new directories.
I've since upgraded to the latest version of server and P4V (2017) to see if that would resolve the problem.When I integrate now I'm getting this warning::
//depot/BranchB/Dir1/File1.txt - resolve move to //depot/BranchB/Dir2/File1.txt before integrating from //depot/BranchA/Dir1/File1.txt
I tried reverting my integrate and just doing the integrate on the new folder BranchA\Dir2 using the branch spec:
p4 integrate -b BranchB -s //depot/BranchA/Dir2/...
I can now resolve this, and it has correctly deleted the files from the old directory and added them to the new directory. So far so good.
I now try integrating the original directory (I still have other files in there):
p4 integrate -b BranchB -s //depot/BranchA/Dir1/...
and I get the error "can't integrate (already opened on this client). I assume I have to submit my first integrate before I can integrate Dir1? This isn't ideal because I really need to submit this integrate as one operation. I guess I could just integrate each file in Dir1 individually.
Posted 19 January 2018 - 07:21 PM
1) Revert everything.
2) Integrate the whole branchspec.
I'd expect that to just do the right thing with no confusion -- trying to integrate different overlapping subsets of files multiple times is what's making things difficult here.
Failing that, based on the sequence of events you've outlined, I think you can just ignore that last error and proceed with resolve+submit. I'd expect that only the files you already had open were prevented from being integrated -- but since they're already open you shouldn't need to integrate them again, right? The rest of the files should have been treated normally since integrate isn't an all-or-nothing operation.
Posted 19 January 2018 - 07:34 PM
If I want to move files in the future is there a better way of doing it that won't cause these integrate problems?
Posted 19 January 2018 - 07:49 PM
But it's hard to tell because I'm following a narrative that includes multiple integrate operations with an unknown number of reverts and resolves in between, and at least one server upgrade, so there are definitely more than a few ways for things to have gotten into an unusually confusing state -- maybe there's nothing unusual about this file at all and you'll never see this problem again with this file or any other.
If you just do a normal move and a normal integrate that covers both parts of the move, you shouldn't have any problems, regardless of server version. The variations in behavior will come with the weird edge cases.
Posted 19 January 2018 - 08:53 PM
and assuming a normally moved file, this is what should happen under the covers:
BranchA\Dir1\File1.txt is mapped to BranchB\Dir1\File1.txt.
Since BranchA\Dir1\File1.txt#head is a move/delete, this pair of files is skipped, with the expectation that somewhere else in the branch spec there will be a matching move/add that will remap here. (If you attempt to integrate this file on its own, you will get an error about needing to integrate the matching move/add.)
BranchA\Dir2\File1.txt is mapped to BranchB\Dir2\File1.txt, which does not yet exist.
Since BranchA\Dir2\File1.txt was moved from BranchA\Dir1\File1.txt, the mapping is consulted for BranchA\Dir1\File1.txt.
BranchB\Dir1\File1.txt is found to have common ancestry with BranchA\Dir2\File1.txt, so the integrate is remapped to use BranchB\Dir1\File1.txt as the target, and to schedule a move resolve to the originally mapped path (BranchB\Dir2\File1.txt).
When the resolve is performed, BranchB\Dir1\File1.txt is moved to BranchB\Dir2\File1.txt, with the final result that both files are open (for move/delete and move/add respectively).
Note that in that very first step, we skip the Dir1 source file because it's a move/delete -- that's why I suspect that either a) there was another deleted file submitted on top of that file or there was an initial attempt at integrating this file with one of the deprecated flags (which forces move/deletes to be treated as normal deletes, which really gums up the works).
Posted 19 January 2018 - 09:12 PM
I've attached the revision graph of the file move. 13 is an integrate to the new folder. 14 is the move/delete. 15 is a delete. 15 happened in a changelist where I edited the file in the new folder. I'm not sure how I could have deleted the file after the move/delete had already been submitted.
I think that the integrate is integrating the move/delete correctly, but then failing on the delete for obvious reasons.
When I move/delete should it also have a delete? If it should, then maybe the delete somehow became separated and put into a different changelist, but I'd have expected a move/delete to be a single operation.
Posted 19 January 2018 - 09:18 PM
Posted 19 January 2018 - 09:35 PM
Posted 19 January 2018 - 09:43 PM
Obliterate: "Removes files and their history from the depot." does that mean I will lose the history for that file? I don't want to obliterate the file, just that delete change.
Posted 19 January 2018 - 09:45 PM
Posted 19 January 2018 - 09:50 PM
p4 obliterate //depot/scl/Code/Apps/FramePro/TimeSpan.cs#15
Posted 19 January 2018 - 09:50 PM
If you're ever able to recreate the situation that led to the creation of that revision (some weird shelving edge case sounds plausible), I recommend reporting it to Perforce support as a bug.
Posted 19 January 2018 - 09:57 PM
Out of the 35 files that I moved, 3 of them had this problem. I've obliterated those revisions and all seems fine now. Thanks very much for your help.
Yes, if I ever work out what I did to cause this I'll let Perforce know. Hopefully it will never happen again though
Also tagged with one or more of these keywords: integrate, move
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users