CODEWITHSUNDEEP
version-controlperforce
TheBeardedBerry
TheBeardedBerry

Reputation: 1766

How to make a new Perforce workspace recognize a previously sync'd depot's data?

So I have run into this a few times. Lets say I have WorkspaceA and I have sync'd to the latest CL (thousands of files, several hundred gb of data at least). Now I need to make a new workspace WorkspaceB pointing to a different depot but with identical data. How can I force WorkspaceB to recognize all of the existing data?

DepotA -> WorkspaceA -> MyPC (E:/Files)

In this initial config, WorkspaceA sees the connection between the files in E:/Files and the data from the Depot.

DepotA -> (Cloned) -> DepotB -> WorkspaceB -> MyPC (E:/Files)

In this config, WorkspaceB doesn't see that the Depot files in E:/Files are identical. Of course this makes sense, a fresh workspace has no metadata to connect everything. However, I have to assume there is a p4 command (ui or commandline) that will allow me to regenerate the metadata and search for all the existing files.

So my question is: How do I make WorkspaceB see the connection between DepotB and the files in E:/Files the same way that WorkspaceA sees the connection between DepotA and the files in E:/Files?

Upvotes: 0

Views: 18

Answers (2)

Jase
Jase

Reputation: 406

This is possible, but I would not recommend doing it exactly as you described. Having two workspaces pointing to the same files will inevitably cause issues, because if you make a change in one workspace, the server won't know that the change has been made in the other, so you'll constantly have issues of files getting stomped, or issues checking out, or many other things like that.

That said, the command you're looking for is p4 flush some studios will do something a bit similar to speed up creating new workspaces. Normally it would be done to create multiple workspaces pointing to the same depot/stream, like this:

  1. One user runs p4 sync files from the client workspace firstworkspace.
  2. The other users copy the newly-synced files from the first user’s client workspace into their own client workspaces using their local OS file-copying commands.
  3. The other users run p4 flush files@firstworkspace, which quickly brings their client workspaces' have lists into sync with the files copied into the client workspaces in Step 2. Because p4 flush moves no files across the slow link, this is much faster then running the same p4 sync command ten separate times.

Adapting that to your example would look something like this:

  1. DepotA -> WorkspaceA -> MyPC (E:/WorkspaceA)

  2. DepotA -> (Cloned) -> DepotB (using p4 populate, most likely)

  3. Copy files locally from E:/WorkspaceA to E:/WorkspaceB

  4. DepotB -> WorkspaceB -> MyPC (E:/WorkspaceB)

  5. Then to tell the server to just assume everything is up to date, you can run p4 flush ...#head

This is an alias for p4 sync -k read more in the documentation: "Use p4 sync -k only when you need to update the have list to match the actual state of the client workspace."

Upvotes: 2

Samwise
Samwise

Reputation: 71542

First: I'm assuming these are two different machines, or two different directories on the same machine, and you have two independent (but identical) copies of the files rather than a single directory with two workspaces pointed at it. Do not have multiple workspaces pointing at one local root. Perforce will not explicitly stop you from doing this, but it does not work.

To tell Perforce "just assume I already synced all these files", do:

p4 sync -k

The -k flag is for "keep everything in my workspace instead of actually sending me the updated files".

If you want to tell Perforce "actually, I'm not positive I have everything you think I have, can you look at what's actually in my workspace and fix anything that doesn't match?" do:

p4 clean

Either command accepts a file argument so you can limit it to a specific depot path or client path.

Upvotes: 2

Related Questions