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.
Posted 17 October 2018 - 04:06 AM
One doubt : If we want to work on old version we can simply sync to that particular version which results to place the files in our old path in our client. Our build scripts & config files are referring to new file paths location, Which results to build failure. As you explained above with example saying that p4 sync & resolve will help us moving that file to new path before submission.Yes, That is clearly understood. But file will get the new revision changes right ? We actually want to work on old revision file which don't have recent changes.
Example : If cl#100 (After movement) is culprit and we know that cl#96 is stable (old path).
i will sync the file to cl#96 which will place the file in older location in my client. Now i trigger build to verify same. Our build scripts are referring to new path and breaks the build right?
Let me know if i am missing something here. Actually this is first time i am handling this file movement in perforce.
Posted 17 October 2018 - 09:42 AM
If you're working on an old version, shouldn't you sync the build scripts/config to the old version as well? In general any time you're working on an old version I'd think you'd want to sync everything to the old version since there can be all sorts of dependencies between files that will break if you sync them to different versions (and many of them have nothing to do with filename changes).
I still don't understand this use case at all (what are you doing with this old version and why isn't it in a branch??? isn't overwriting all the newer changes in your mainline file going to break a bunch of things??? this all seems like a terrible way of doing something that is more easily done some other way if only I knew what it was you were trying to do) but you can do what you describe by resolving the filename with one action and the content with another -- "p4 resolve -Am -at" followed by "p4 resolve -ay" to preserve the filename change but ignore all other changes.
Posted 17 October 2018 - 11:02 AM
For that i am just concern about the history & working with older revisions of files. As per this new folder structure we made the changes in our build scripts accordingly. So, I was thinking if still file (old version) exist in older location build breaks.
" "p4 resolve -Am -at" followed by "p4 resolve -ay" " -> Answers my question.
We can take the older revision of our build scripts when we are working with older revision of files . But if we know that there is only one file which is causing some failures. We will get only that particular file's old revision not all. In this case all other files are in new location except that one file. Which wont work for build. So, we if we want to work on older revision of some file. We should sync our whole client to that revision right?
Though we get the older revision of the file we want that file to be in newer location in our client to make it work while running build
Posted 17 October 2018 - 03:12 PM
Making changes to an older revision of a file is not a very typical workflow unless you're backing out a mistake, since you'll lose all the newer changes. Typically if you need to maintain something like an old release (for example) you branch the entire project at the older point and then make the change to the branch, so you don't lose any newer changes in the mainline file. Branching the entire project (including the build config etc) makes everything work the way it did in the older version, but you can still merge the changes from the older version to the latest version without losing any work.
Posted 18 October 2018 - 04:09 AM
We decided to use p4 move for achieving the same. After moving ,though we don't loose the history of the file, File version is again staring with revision #1. When we do 'p4 annotate' on moved file it is showing whole file changes are marked with revision #1. Is there any way to show the revisions specific to the change.
Posted 18 October 2018 - 04:32 AM
For that use case, you'd definitely want to sync the entire project (build config and all) to the older version -- right? You shouldn't need to do any special sync-resolve steps if you do that.
If syncing the entire project to an old version doesn't include rolling the build config back to that version, there's an easy fix for that -- put your build config under version control!
Use "p4 annotate -i" and it will show you the history through moves (and branches), with each version annotated as a changelist number rather than a file-specific revision number.
Posted 18 October 2018 - 09:30 AM
Sorry, i didn't get the point. we have build configs/Gnumakefiles in perforce version control itself.
Posted 18 October 2018 - 05:00 PM
Sorry, i didn't get the point. we have build configs/Gnumakefiles in perforce version control itself.
Okay -- so if you need to reproduce a customer issue on an old version, you sync the entire project to the old date (or changelist or label or whatever) and that includes the build configs. Right?
So you have the old version of the build config that points at the files in their old location -- you shouldn't need to fast-forward the move operation or anything like that. Right? In fact, if you did move the files to their newer location, the old build config would be looking for them in the wrong place -- right?
The only way that wouldn't work would be if either the build config or the move weren't versioned correctly, which is why the fact that there was ever a problem here confuses me. If something's not being versioned and that makes it get out of sync with something that is versioned, you should usually solve that by versioning the thing that's not versioned rather than not versioning the thing that is versioned.
Posted 20 October 2018 - 10:19 AM
>>So you have the old version of the build config that points at the files in their old location -- you shouldn't need to fast-forward the move operation or anything like that. Right? In fact, if >>you did move the files to their newer location, the old build config would be looking for them in the wrong place -- right?
Yes, if people want to work with some older revision of source file. We will tell people to sync the build configs & whole client to older revision. Otherwise build fails right
Last paragraph in your comment confuse me
We will do source file movement and build config changes at the same time. I mean we will submit both at one with single change list Suppose lets consider the submission cl of both moved files and build config changes is cl#100. If any one wants to work on older revision of files syncing the client to cl#99 should not help ?
Regarding 'p4 annotate' we don't have any other way to get the revision number instead of change list?
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