[p4] remote depots
karish at well.com
Fri Dec 28 00:23:47 PST 2001
At 03:34 PM 12/26/2001 -0500, Hutchinson, Karen wrote:
>is new to Perforce. We have a joint development effort between Boston, NY,
>and San Francisco.
>We would like to use remote depots in Boston and San Francisco and have NY
>be a client
>into the San Francisco office. We are not comfortable using one Perforce
>server as it is a
>single point of failure and consistent network connectivity is an issue.
The Perforce remote depot facility gives read-only access to a
depot somewhere across the network. It does not replicate the
data in that depot to another server's disk.
It's possible to maintain mirror servers yourself. If you want
to have them be real backups it's desirable to keep the change
numbers synchronized. This is possible if the mirror servers
are read-only. It's not possible if users at the remote sites are
checking code into them. Look for revml and vcp in the Perforce
Whichever tools your team chooses, it'll be an adventure to
manage a three-site development project. If the teams are working
on distinct parts of the product it may be best to have them check
into development branches on servers in their own offices.
Make sure that your developers learn how to work off-line and to
keep track of their changes without the server's help. There are
tools in the Perforce public depot to help with this, too.
Sync the main line in each remote office to the main line at the
home site every night, and make sure the developers sync to it
every day. Don't worry about keeping the change numbers
synchronized. The checkin times will be enough, if you're
keeping a record of the latest change number that's represented
in each night's sync. Oh, and make sure that the nightly sync is
to a change that's known to build and run.
Frequent releases of working code can be shipped to the site where
the master server is, where someone will do the last merges and the
When your network is healthy and everyone is checking code in to
the same server accountability becomes an issue. You'll need a
system that finds out promptly whether a checkin has broken
something, and you'll need to make sure that all the developers,
remote or local, are available when fixes are needed. If everyone
is conscientious and builds and tests before checking in the
surprises can be kept to a minimum. There's no way to prevent
an occasional collision when to changes are checked in in close
Chuck Karish karish at well.com (415) 317-0182
More information about the perforce-user