Perforce replication is already a tremendous help for those of you who have large user bases, remote teams, or aggressive build automation.
The 2013.1 release adds the capability to chain replicas together. Now replicas can assimilate even more of your offices.
Why is this so useful? Well, consider this scenario. You have your main repository in California, and have remote offices in Hong Kong and Singapore. You want to have a read-only replica in both remote locations to support build processes. Up until now, you'd have to have both replicas pulling data directly from the main office in California. Shipping data over an ocean twice is a little wasteful.
Now, you can set up the Singapore replica to pull from California, and the Hong Kong replica to pull from Singapore. You're only transmitting data once over the ocean, and if your repository has terabytes of data, you're less likely to run into bandwidth problems as you add more replicas to your deployment.
Or, if you just want to set up several replicas in Singapore to support a really big build farm, you can have one replica pulling from California and feeding the rest. With the ability to chain replicas, you just have a lot more flexibility to build out a Perforce deployment that meets your needs.
How does this work? It's easy: our first replica sets its P4TARGET to the master repository in California, and the second replica sets its P4TARGET to the first replica.
p4 configure set replicaSingapore#P4TARGET=master:1666
p4 configure set replicaHK#P4TARGET=replicaSingapore:1666
Use common sense when planning your deployment. For example, pointing a forwarding replica at a read-only replica isn't going to work. (A forwarding replica accepts write operations, while a read-only replica does not.)
Now, a word of advice: make sure you're comfortable with replication before you try setting up a very complex deployment. Contact Perforce Support if you want to bounce your ideas off an expert, too. Once you're ready, grab the 2013.1 release and give it a go.