[p4] Undoing the effects of "p4 move"

nickappleton perforce-user-forum at forums.perforce.com
Sun Aug 7 16:55:01 PDT 2016


Posted on behalf of forum user 'nickappleton'.

Hi,

Thanks for the reply.



Quote
>   I'm guessing that in this case you were using "move" to change the location of the branch (e.g. you were moving //libraries/ace/A to //libraries/talkhouse/A, which is a change that does not have any significance within the //components/A branch) rather than the location of the files within the branch, and then adjusting the branch mapping to match, so that from the perspective of the target branch nothing has moved at all.  In this case you don't really have anything to propagate back to the parent branch, but just as if you'd done "p4 edit" and then submitted the new revision without any changes, it still shows up as something new to integrate.    
Yes, that is exactly the situation.

Most of us in the past have used "p4 integrate" to branch to the new
location followed by a "p4 delete" in the old location for doing these
kind of "move component within the library" operations and this issue
has only come up recently where some of us assumed that "p4 move" was
an equivalent operation - it actually took quite a long time for us to find this
as being the cause of our issues. I used the revision graph and started noticing
"red" lines indicating branch with edit and assumed that files were
accidentally being checked-out before the commit happened.



Quote
>   The idea behind "p4 move" counting as an edit (indeed, you can only "p4 move" a file that's first been opened for edit) is that you want to version the location of the file (within a relative namespace) as well as its content.    
I'm still not entirely sure I understand what the rationale is for p4 move
behaving the way it does. If I perform an integrate and then delete to move a
file (which is what most of us do), the operation is still tracked i.e. branches
which were made before the operations were performed will be updated the next
time we integrate into them. Why would anyone want to bump the revision of a
file when its contents have not changed at all? Can you help me out with an
example?



Quote
>   I'd do something along these lines:
>    ...    


The workflow you suggested is almost what I was doing now. Thanks for the
"p4 diff -sr | p4 -x - revert" snippet - I like that.

Unfortunately for us, this is a huge amount of effort to fix, the unwanted
behaviour (for us) in the move operation in several of our library branches
makes this a very laborious process to undo. This wouldn't be too bad if we
were sure that we had not made local bug-fixes in some of the libraries, but we
are effectively needing to first validate that no "desirable" updates
have been made in the component i.e.

* integrate the library version of the component back to it's home (which
will want to update every file because of the p4 move behaviour)
* use automatic/interactive resolving to see if there were local changes made to
the component which need to go back
* revert any files in the changelist that have no "real" changes
* if there are any files that needed to go back, commit the changelist
* force integrate from the component home back into the same library
* resolve using accept source
* commit the changes


When each library has many components, this is incredibly arduous. I was kinda
hoping there would be a simplish way to undo this, as it would have never
happened if we had not used p4 move. Anyway, thanks for the suggestions.



--
Please click here to see the post in its original format:
  http://forums.perforce.com/index.php?/topic/4897-undoing-the-effects-of-p4-move


More information about the perforce-user mailing list