Before configuring P4Sandbox, consider the following questions:
Am I going to continue to use my Standalone Sandbox and occasionally push my files to a central server?
If your answer is "Yes", then take another look at "always connected" option to see if this option is a better fit for your needs.
Is this a "one off" project you want to work on in a private environment?
If "Yes", then you do not need to continue reading this article, unless you decide to submit your work in to a central Perforce server when completed. If you need to push your work to a central Perforce server, then this article will provide the steps to accomplish this task.
Note: The following assumes that you are using Linux. However, the same steps can be used on Windows with only minor modification. The P4PORT setting is 4321.
Create a standalone sandbox as instructed by P4Sandbox User's Guide:
p4sandbox init -p 4321 -u test -c test_client
Perforce sandbox broker starting on localhost:4321 ...
To confirm that P4Sandbox is running, run a p4 info command against the specified port (4321 in this example) and localhost:
p4 -p 4321 info
User name: test
Client name: test_client
Sandbox broker version: P4SANDBOX/LINUX26X86_64/2012.1.BETA/411339
Sandbox broker port: localhost:4321
Optionally, you can check if the Perforce database (db.*) and other files have been created by listing the contents of the ".p4sandbox" directory:
db.archmap db.config db.group db.ixtext db.resolve db.revdx db.stream db.view p4sandbox.audit.log server.locks
db.bodtext db.counters db.have db.label db.rev db.revhx db.template db.working p4sandbox.audit.log.lock
db.change db.depot db.integ db.locks db.revbx db.review db.trigger journal p4sandbox.scheduler.log
db.changex db.domain db.integed db.protect db.revcx db.revsx db.user p4d.log p4sandbox.scheduler.log.lock
Confirm the "local" stream has been created:
Stream //streams/local mainline none 'local'
At this point a local Perforce server is up and running, along with a "local" stream created for us by P4Sandbox. Files can now be added without any additional configuration, such as creating a workspace client specification:
echo "1" > file1
echo "2" > file2
echo "3" > file3
p4 add file*
//streams/local/file1#1 - opened for add
//streams/local/file2#1 - opened for add
//streams/local/file3#1 - opened for add
p4 submit -d "adding files to StandAlone Sandbox"
Submitting change 1.
Locking 3 files ...
Change 1 submitted.
Integrating Standalone Sandbox Files into a Central Perforce Server
Using P4Sandbox Only:
Create "remote" connection to your Central Perforce server:
p4 remote -p <central_server_address>:<port number>
Use this "remote" connection to create a "mirror" and a new "local" stream in the local sandbox:
p4 merge //remote/streams/P1/... //streams/mirror/...
Copying 8 files from 'remote' to '//streams/mirror'.
p4 merge //streams/mirror/... //streams/localO/...
- At this point, you should have two "mainline" and one "development" streams, which can be confirmed using the p4 streams command:
Stream //streams/local mainline //streams/localO 'local'
Stream //streams/localO development //streams/mirror 'localO'
Stream //streams/mirror mainline none 'mirror'
Note: the original "local" stream is a "mainline" type by default. While this presents a problem it will be addressed in later steps.
Launch and connect P4V to your Sandbox. Enable streams graph to see all your streams:
Connect the two unrelated "local" streams (referred to as "re-parenting") and prepare for committing your work in to central server.
In this example, we chose "//streams/local0" to become the parent for "local" stream and we change "local" stream type to "development". This is done with p4 stream command on the command line:
p4 stream //streams/local
The specification for this stream is opened in your default editor:
Change the Parent and Type fields:
Save those changes and quit the editor, confirming that the stream specification is saved:
Stream //streams/local saved.
At this point, you are back into familiar "streams" territory. Your streams are all connected and you can "merge down/ copy up", which can be confirmed using the stream graph view in P4V:
Note: it is sometimes necessary to push files up/down/between the streams even when the file's content has not changed. A good example might be when you checked out a file and checked it back in without making any changes. After submitting, the file had its revision counter incremented; the file looks to be a good candidate for copy/merge. With P4Sandbox using this copy/merge paradigm, you cannot merge such files unless you are using p4 integrate. For example:
p4 diff2 //streams/local/file1#5 //streams/local/file1#4
==== //streams/local/file1#5 (text) - //streams/local/file1#4 (text)==== identical
p4 integ -n //streams/local/... //streams/localO/...
//streams/localO/file1#2 - integrate from //streams/local/file1#4,#5
Using P4V Reconcile
Note: Before using this option, please consider the following caveats:
This option applies to both "classic" and "stream" depots.
Only a single version of your work is going in to the central Perforce depot unless you choose to submit every revision that exists in your sandbox individually. The "individual revisions" case is not covered in this article.
The "sandbox" file history will likely be lost.
Once the files are in the central Perforce server database, you can always re-sync them into another P4Sandbox instance.
Note: If necessary, you need to choose where you want your files to appear in the central server depot and properly map the destination in the workspace specification. You can choose a new depot directory to add your files to, or any other existing folder that already contains files. Adding the files you worked on from the sandbox workspace to an existing folder that already has the files might introduce completely new content for files that already exist in the central Perforce database.
Connect to the central Perforce server and create a workspace that is at the same location as your P4Sandbox workspace.
If you are mapping the sandbox files to an existing location, update the Perforce server using the p4 sync -k command:
p4 sync -k <files>
The "-k" flag updates the Perforce server, the client's "have "records without copying the depot files to the workspace.
P4V Reconcile Method:
Using the "p4 reconcile" Command (2012.1 or later):
Note: The following command assumes that the P4USER, P4CLIENT and P4PORT settings are using the user, workspace (as created in the earlier steps) and host:port setting for the central Perforce server.
Note: Regardless of which option is used, please pay special attention to "deleted" files on the central server and "missing", if any, files from your Sandbox workspace.
Working Disconnected From The Perforce Server" approach
This option works well with all Perforce releases. We discuss this method in great details in this knowledge base article.
- Start P4V.
- Open a connection to the central server using the newly created workspace.
- Right-click on the local directory containing the files to be pushed to the central server:
- Log in to the central Perforce server.
- Run the p4 reconcile command:
p4 reconcile <files>
This will create a default changelist containing any changed files (if they already exist), add files that do not exist, and delete files:
p4 reconcile <files>