# Looking for perforce files moving one location to different location without losing labels and history information.

3 replies to this topic

### #1 linux3250

linux3250

Newbie

• Members
• 1 posts

Posted 04 March 2020 - 02:55 PM

Hi All,

I want to move the perforce files from one location to different location in the same depot without losing the labels and history details. Kindly help me to share the steps and procedures. Thanks

### #2 Sambwise

Sambwise

• Members
• 1037 posts

Posted 05 March 2020 - 05:44 PM

When you say "without losing the history", I would assume that means you want to retain the history of the files' original location -- e.g. if you sync back to an earlier label, you should get the files in their historical location, to make sure that old builds with dependencies on those labels and those file locations continue to work.

For this, you want the normal "p4 move" command.  Here's an example of a file "foo" with history and a label:

C:\Perforce\test\move>p4 files @foo_label
//stream/main/move/foo#2 - edit change 143 (text)

C:\Perforce\test\move>p4 filelog foo
//stream/main/move/foo
... #2 change 143 edit on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'edit foo'
... #1 change 142 add on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'add foo'

To move it to a different location I'll open it for edit (like any time I'm modifying an existing file) and then "p4 move" it to the new path.  I'll move it to a filename called "bar" in the same folder, but I can move it anywhere in the repository, including another depot, as long as it's mapped in my workspace.  Note that if I'm using branches I wouldn't want to "move" it to another branch since then I'd really be removing it from the branch rather than moving it; in that case I'd probably want to branch and/or delete it as independent actions, or maybe not do anything to the depot file at all but instead modify the branch/stream view to reflect the new branch relationship.

C:\Perforce\test\move>p4 edit foo
//stream/main/move/foo#2 - opened for edit

C:\Perforce\test\move>p4 move foo bar
//stream/main/move/bar#1 - moved from //stream/main/move/foo#2

C:\Perforce\test\move>p4 submit -d "moved foo to bar"
Submitting change 144.
Locking 2 files ...
move/delete //stream/main/move/foo#3
Change 144 submitted.

The history is preserved; if I do "p4 filelog bar" I will see the old revisions of foo:

C:\Perforce\test\move>p4 filelog bar
//stream/main/move/bar
... #1 change 144 move/add on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'moved foo to bar'
... ... moved from //stream/main/move/foo#1,#2
//stream/main/move/foo
... #2 change 143 edit on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'edit foo'
... ... moved into //stream/main/move/bar#1
... #1 change 142 add on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'add foo'


And if I sync to my label, the file is put back exactly how it was in the label (including the fact that it's called "foo" at that point in time rather than "bar"):

C:\Perforce\test\move>p4 sync ...@foo_label
//stream/main/move/bar#1 - deleted as c:\Perforce\test\move\bar

C:\Perforce\test\move>p4 filelog ...#have
//stream/main/move/foo
... #2 change 143 edit on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'edit foo'
... ... moved into //stream/main/move/bar#1
... #1 change 142 add on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'add foo'


### #3 Matt Janulewicz

Matt Janulewicz

• Members
• 217 posts
• LocationSan Francisco, CA

Posted 06 March 2020 - 10:48 PM

I almost hate to mention it because it's undocumented and goes against the purpose of a source control tool, but 'p4 duplicate' might come in handy in certain circumstances (flubbed branch name checkin, sensitive info being checked into a public area, etc.):

https://community.pe.../s/article/3099

Just, you know, be careful with that. Do a dry-run or two. And also remember that this literally duplicates files in the same/previous changeless. You would ultimately (maybe) go back and obliterate the 'wrong' files. And again, be really careful with that because obliterate is forever.

Basic ideas:

1. 'p4 move' preserves history up to the point of the move.
2. 'p4 duplicate/obliterate' makes it as though that history was always in the 'correct' place.

Alternately, off the top of my head, I think you might be able to use Perforce's built-in DVCS capabilities to do a similar thing as above, but you would end up with new changelists. (p4 clone then p4 push to/from different paths/specs.)
-Matt Janulewicz
Currently unemployed, looking for work in Boise, ID!

### #4 Sambwise

Sambwise

• Members
• 1037 posts

Posted 07 March 2020 - 04:17 PM

Note that "p4 duplicate" won't duplicate the label entries:

C:\Perforce\test\move>p4 duplicate foo baz
//stream/main/move/baz#3 duplicated from //stream/main/move/foo#3
//stream/main/move/baz#2 duplicated from //stream/main/move/foo#2
//stream/main/move/baz#1 duplicated from //stream/main/move/foo#1

C:\Perforce\test\move>p4 files @foo_label
//stream/main/move/foo#2 - edit change 143 (text)


Also, it will merrily duplicate the move/delete and "moved into" records...

 C:\Perforce\test\move>p4 filelog //stream/main/move/baz
//stream/main/move/baz
... #3 change 144 move/delete on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'moved foo to bar'
... #2 change 143 edit on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'edit foo'
... ... moved into //stream/main/move/bar#1
... #1 change 142 add on 2020/03/05 by Samwise@Samwise-dvcs-1509687817 (text) 'add foo'

which is definitely going to be problematic if you don't obliterate the other path since it violates the move atomicity invariants.

#### 0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users