Can perforce create another workspace with a clone of an existing workspace that is maintained separately?

Question

I have an interesting question in which someone has developed some code using perforce as a repository and have made several changes to the source code that has not been checked in. Rather than check the code in over the original however, they want to create a separate "workspace" that is a clone of the current workspace with the files still synced, but newly created files.

I know this is not exactly how perforce should be used, but it is just a question I have to see if it's even possible or if there are better ways to to mitigate this situation in the future. It seems like it should be possible because that's why you have separate clients each with their own "local" copies. What not two "local" copies on the same machine?

Answer 1

In Perforce, workspaces (clients) themselves serve only to create a mapping between the user's local copy and the copy on the server. So, if your files came from //depot/projectA, your client would have a map such as:

//depot/projectA/... //workstation/...

In a situation where you have substantial changes and want to check them in as new code, you've got a couple of options. Most commonly, you'd do this by branching the original files and then checking in the modified versions. If you know exactly when the files were checked out (such as a label or changelist #), you can do this pretty easily by branching the current projectA into projectB:

p4 integrate //depot/projectA/...@<change# or label> //depot/projectB/...

This will basically create projectB as a new project, but containing all of the resources from projectA.

Now, to work on projectB, you're either going to have to add a new mapping to your existing client, or you're going to have to create a second client for that machine. In answer to your question, it's entirely reasonable to have a second client on a machine for a different copy of the source code or even different projects. However, as far as Perforce is concerned, it's the equivalent of a second user on that machine working in the same (or a different) portion of the repository.

So, for this, let's say you opted to create a new client. Do so, but use a different root location on your hard drive, and map projectB instead of projectA (assuming the client name is workstation2:

//depot/projectB/... //workstation2/...

Keep in mind that you'll need to be careful to use the correct client when working with perforce. This can be done in a number of ways, including setting environment variables (if using a shell), or changing the "workstation" in p4v.

Now, for the final part, moving your changes from the checked-out version of projectA into projectB. Since the integrate command above took the copy at the time of the original checkout, you now need to either copy the files over or shelve and unshelve them.

As long as you're doing this on the same machine, a copy is straightforward, and you'd want to follow the following basic steps:

1. Make sure you have retrieved the latest copy of projectB (p4 sync ... in workstation2)
2. Copy the modified files from your original location to the workstation2 directory
3. Use the p4 reconcile ... command to check out for edit any files that have been modified
4. Use p4 commit ... to check your modified files into the projectB repository from workstation2

Now that you've safely checked in the modified files in a new project, you'll probably want to revert any changes in the original project so that directory is not left in a confusing state. To do this, switch to the old workspace and use p4 revert ....

The process if you don't want to keep the connection to the older code will save you a couple of steps (basically you create the new client, copy the files and then p4 add ... them, but since you know the origin of the files, keeping the history is probably worthwhile.