Perforce move operation with no effect in histroy.P4 move
Posted 08 October 2018 - 11:08 AM
We have recently planned to move some folders from one location to other. We are using 'p4 move' to achieve the same. Below is the problem which we are facing.
i moved the file <fileA> from '//depot/src/devops/dir/' to '//depot/src/devops/dir/temp/' , After moving the file i can see that file is treated with revision#1 and it is marked as new file addition '+' symbol in p4v. The history of change-lists are shown with 'x' symbol mark for delete . PFA for clarity.
Here the problem is if we want to have some older change-list of the file we are not able to get that in out client. As the file is treated as delete.
Is there any other way to move the files from on location to other without effecting the history ?
Posted 08 October 2018 - 05:21 PM
I don't quite understand what problem you're describing. If you do:
p4 sync @OLDCHANGE
then you will get the older version of that file, under its older name. This does require that the older name be mapped in your client, but as long as you didn't change your client mapping after renaming the file, it should still be there.
In addition, if you do "p4 filelog" of any of the moved files, it will automatically display the older versions of the file (under the old name) as part of the history of the "new name" file. P4V operations like "file history" and "time-lapse" view etc will do the same thing.
The only way to move files without affecting the history (i.e. retroactively changing the names of the older versions) is the way you're already doing it.
It is possible to move the history itself (which obviously does affect it) by combining the "p4 duplicate" and "p4 obliterate" commands. This is significantly more likely to have negative side effects, so you should only do it if you have a good understanding of the external dependencies on your history (again, the default "move" command will always preserve your existing history and won't break anything that depends on it -- "obliterate" offers no such guarantees).
Posted 09 October 2018 - 06:00 AM
Just to give the clarity -> I am not actually renaming the file. I am moving the file from one location to other. Lets say the movement happened at 100th changlist. And if i want to sync cl#98 of that file on my client it is marking as delete. As it was pointing to older depot path of that file. i have that path as well in my spec. But if we do 'p4 sync' to that original file path it is marked for delete as we have deleted and moved that file to new location.
As you are saying "This does require that the older name be mapped in your client" , if we have that it will point to original location where it was earlier. Again it will create a file which don't work for me. Is there any way that even after moving the files to other location. We can sync to the older changelist which point to new path to work on it?
Edited by Naveen kumar pet, 09 October 2018 - 06:42 AM.
Posted 10 October 2018 - 05:19 AM
It sounds like you've tried syncing the newer path to @98, and the older path to @now. What happens if you sync both paths (or easier yet, your entire workspace) to @98?
Posted 11 October 2018 - 10:11 AM
if i try syncing the old path to cl#98 it marks that file as added as expected.
In my case,i fell the only way is to use 'p4 duplicate' which helps in having linear history (Not like above which marks the file as delete in old location and added in new path with 'p4 move' command). For some days we will keep the older path without obliterating them. once we are stable enough with new path we will delete old path files/folders. Is that a good idea?
You mentioned -> 'you have a good understanding of the external dependencies on your history for running 'p4 duplicate' ' -> external dependencies means?
Can you give some example ? What needs to be taken care before running 'p4 duplicate' command?
Posted 11 October 2018 - 07:15 PM
There are a lot of things that might potentially get broken when you do that "obliterate" command. (Or, if you do a "delete" on the old path, a lot of things that will be very confused, since there will be no connection to the duplicate files.) Without knowing everything about your environment and tooling it's impossible for me to tell you what might break. If you never create any branches or labels and you don't have any build scripts or manifests that reference depot paths you should be fine.
If it's not obvious to you what sorts of things might get broken, then either there are no such things, or you're in for some fun surprises after you execute this maneuver. Personally, my recommendation would be to do the normal "move" since everything in the system is designed to handle "moved" files correctly but there are a lot of things that may behave strangely if you go the "duplicate" route. (Or they might not! Depends on how much risk you're willing to take with the thing that's the source of truth for all your source code.)
Posted 12 October 2018 - 03:18 AM
Coming to external dependencies, Recently (few months back) we have migrated from Clearcase to perforce. And there are not much branches created and i guess we don't have labels created . And we have made changes in All makefiles & scripts in our local test environment referring to new path and able to build successfully.
We planned to make this change in 'main' branch. But the thing is we need to make this folder reorg on all the branches which are created from 'main'. Otherwise while integrating from main branch to other branches it will fail
Is there any hacks with p4 move command to get it done same like p4 duplicate ?
Posted 12 October 2018 - 05:51 AM
This isn't true, as you said:
if i try syncing the old path to cl#98 it marks that file as added as expected
So when you sync the whole file (i.e. both paths), you get the old version, under the old path. Which is what you need in order to work with the older version, right?
Just make sure that when you sync, you're including the old path. (An easy way to do this is to sync the entire workspace/stream as a unit; then you'll never "miss" part of a changelist, or an old-named variant of a file, etc.) It's no different from syncing to any other old file revision, except that the name is different from the head revision.
Posted 12 October 2018 - 08:21 AM
I agree that we will get the old version under old path. Syncing to old revision and make check-ins will again causes adding those files in old path in perforce. We want to completely move the folders/files and start working on that new path.
And another issue is all the build scripts are modified/updated according to new path. Making changes in old path files wont make any sense. So, we have to work only in new path files .
Posted 12 October 2018 - 08:47 AM
This is also not true. When you sync in order to resolve the new revisions (as you always have to do when editing an old revision), "p4 resolve" will help you move the changes to the new path. Here's an example of making an change to an old revision of a moved file:
C:\Perforce\test\move>p4 filelog new //stream/main/move/new ... #1 change 100 move/add on 2018/10/12 by Samwise@Samwise-dvcs-1509687817 (text) 'move' ... ... moved from //stream/main/move/old#1,#2 //stream/main/move/old ... #2 change 99 edit on 2018/10/12 by Samwise@Samwise-dvcs-1509687817 (text) 'edit' ... ... moved into //stream/main/move/new#1 ... #1 change 98 add on 2018/10/12 by Samwise@Samwise-dvcs-1509687817 (text) 'add' C:\Perforce\test\move>p4 sync ...@98 //stream/main/move/new#1 - deleted as c:\Perforce\test\move\new //stream/main/move/old#1 - added as c:\Perforce\test\move\old C:\Perforce\test\move>p4 edit old //stream/main/move/old#1 - opened for edit ... //stream/main/move/old - warning: edit of moved file C:\Perforce\test\move>echo "a change" >> old C:\Perforce\test\move>p4 sync old //stream/main/move/old#3 - is opened and not being changed ... //stream/main/move/new - must resolve #1 before submitting C:\Perforce\test\move>p4 resolve c:\Perforce\test\move\old - resolving move to //stream/main/move/new Filename resolve: at: //stream/main/move/new ay: //stream/main/move/old Accept(a) Skip(s) Help(?) at: a //stream/main/move/new - moved from //stream/main/move/old c:\Perforce\test\move\new - merging //stream/main/move/new#1 Diff chunks: 0 yours + 0 theirs + 0 both + 1 conflicting Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) e: e Accept(a) Edit(e) Diff(d) Merge (m) Skip(s) Help(?) am: am //Samwise-dvcs-1509687817/move/new - merge from //stream/main/move/new C:\Perforce\test\move>p4 opened //stream/main/move/new#1 - edit default change (text)
The "filename resolve" is where the move is taken into account -- when I selected "a" (the default option), my "old" file (with my edit) got moved to the "new" path.
Posted 12 October 2018 - 08:54 AM
is also not true. Here's an example, using the same file:
C:\Perforce\test>p4 integ move/...@98 move-branch/... //stream/main/move-branch/old#1 - branch/sync from //stream/main/move/old#1 C:\Perforce\test>p4 submit -d "branched from before move" Submitting change 102. Locking 1 files ... branch //stream/main/move-branch/old#1 Change 102 submitted. C:\Perforce\test>p4 integ move/... move-branch/... //stream/main/move-branch/old#1 - integrate from //stream/main/move/new#1 (remapped from //stream/main/move-branch/new) C:\Perforce\test>p4 resolve -am c:\Perforce\test\move-branch\old - merging //stream/main/move/new#1 Diff chunks: 0 yours + 1 theirs + 0 both + 0 conflicting //Samwise-dvcs-1509687817/move-branch/old - copy from //stream/main/move/new c:\Perforce\test\move-branch\old - resolving move to //stream/main/move-branch/new //stream/main/move-branch/new - moved from //stream/main/move-branch/old
Look, no failure -- "p4 integrate" knows that the two files are the same and "p4 resolve" handles the move automatically. (This will definitely not work if you use "p4 duplicate" -- if you don't do the same operation on every branch at the same time, every integrate is going to re-branch every file.)
This also works if you integrate in the other direction, or if you decide to "ignore" the move rather than allow integrate to replicate it, or if you cherry-pick an edit from after the move, or if you cherry-pick an edit from before the move, or any other scenario I was able to think of -- but it only works if you actually use the "move" operation and not some more primitive substitute.
Also tagged with one or more of these keywords: P4 move
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users