Jump to content


Problem branching a moved file: "The system cannot find the file specified"

integrate move

  • Please log in to reply
14 replies to this topic

#1 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 01:35 PM

I am getting an error resolving a file after integrating to a branch. The file in question was moved to a new directory using the Move/Rename option in P4V. It was then edited in this new folder. Now when I come to integrate to the other branch again I get a "The system cannot find the file specified" error and I can't find a way of resolving.

Example:
I have two branches, BranchA and BranchB. I create File1.txt in BranchA and integrate to BranchB
BranchA\Dir1\File1.txt
BranchB\Dir1\File1.txt

I then move File1.txt to a new directory: Dir2
BranchA\Dir2\File1.txt

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.

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 19 January 2018 - 04:36 PM

Can you post the integrate command you used?  What should happen is that BranchB/Dir1/File1.txt should be opened for integrate (not delete), and when you resolve it should get moved to Dir2.  It sounds like instead it got integrated twice, with the first integrate opening it for delete (that might have happened if you tried to integrate that file on its own, possibly with one of the deprecated -D flags, or maybe the "copy command) and the second trying to schedule the move (but it failed because the file had already been deleted).

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.

#3 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 06:02 PM

Thanks for your reply.

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.

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 19 January 2018 - 07:21 PM

Assuming you haven't put a lot of work into your resolves, here's the easy solution:

1) Revert everything.
2) Integrate the whole branchspec.
3) Resolve.
4) Submit.

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.

#5 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 07:34 PM

Integrating the whole branch spec is what I did originally and caused the problems. It seems that integrating the moved files first and then integrating the other folders does work. Yes, I think you're right, the error can be ignored and the other files seem to have been resolved ok. I'm concerned that I will keep getting an error on that folder though (on future integrates), will it keep trying to delete the moved file that doesn't exist anymore? I can't submit my integrate yet so I can't test this.

If I want to move files in the future is there a better way of doing it that won't cause these integrate problems?

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 19 January 2018 - 07:49 PM

I'd need to see a little more of the file's history (like some filelogs or a revision graph screenshot) to say what exactly it is that's potentially unusual about this file.  What you're describing sounds like maybe there was more than one thing going on -- you moved the file, you added another file on top of it, you deleted that file, something like that.  Then when you try to integrate, it's having to deal with multiple logical files bearing the same name.  Does that sound plausible?

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.

#7 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 19 January 2018 - 08:53 PM

FWIW, given a normal integrate command like you described earlier:

Quote

p4 integrate -b BranchB

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 B) 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).


#8 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 09:12 PM

As far as I'm aware I followed the steps in my example, although it's possible that I did something that I've forgotten. Although I'm not sure how I could have caused this specific problem. The problem happened before I upgraded, and still happened after, so I don't think that is related.

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 Image
www.puredevsoftware.com/timespan.jpg

#9 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 09:18 PM

Thanks for the explanation, that matches up to what I assumed would be happening. It sounds like the delete (15) after the move/delete is the problem. I wonder how I managed that?! :)

#10 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 19 January 2018 - 09:35 PM

Yeah, that #15 looks like a bug -- submit shouldn't have let that go in.  D'oh!  (I'm guessing it was open for delete before the file got moved or something like that.  Or maybe there was an add before it, and the add got obliterated, in which case it's not submit's fault, and shame on the admin who did that obliterate.)  I'd recommend obliterating that revision, as there's a chance it'll otherwise cause more surprises in the future.

#11 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 09:43 PM

well, I'm the only one using this depot, and I didn't know that it was possible to obliterate changes :) Yes, that was going to be my next question, how to remove that delete.

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.

#12 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 09:45 PM

thinking about it, I may have been doing some shelving/unshelving around the time I made the change, so maybe that caused it. Maybe I unshelved over the top of the move or something. Just guessing though.

#13 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 09:50 PM

ah, I see, I can obliterate a single revision:
p4 obliterate //depot/scl/Code/Apps/FramePro/TimeSpan.cs#15

#14 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 846 posts

Posted 19 January 2018 - 09:50 PM

You can obliterate a single revision: p4 obliterate //depot/whatever/path/TimeSpan.cs#15,15

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.

#15 Stewart Lynch

Stewart Lynch

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 19 January 2018 - 09:57 PM

got it - thanks.

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