p4replicate

This script (p4replicate.rb) is written by Robert Cowham of Vaccaperna Systems Ltd.

License - see license.txt (BSD).

This Utility now deprecated!

This script has not been actively maintained for years, and is now deprecated.

There is a publically available equivalent utility called P4Transfer.py. That utility has unit tests and takes account of more recent Perforce actions include move/add, move/delete and various other permutations. It works in a broadly similar way.

Overview

The script replicates changelists between a source and client p4 server (with caveats - see below).

It is written in Ruby and uses the official version of P4Ruby (2007.3 or 2008.1) - available from the Perforce ftp site, e.g. ftp://ftp.perforce.com/perforce/r08.1/bin.ntx86/.

Configuration File

All the potential fields are shown below. Comments start with "#".

Normal fields require "=" sign to specify, the View field is the only multi-line field.

# I am a configuration file for p4replicate.rb

src_p4port=1777
src_p4client=repl-client-src
src_p4clientroot=c:\work\p4replicate\root
src_p4user=robert
# Comment out if no password
# src_p4password=

# The following is used to record which changelist we have processed.
# Was originally src_counter but users often have more control over dest than src
dest_counter=p4replicate

dest_p4port=1777
dest_p4client=repl-client-dest
dest_p4user=bruno
# Comment out if no password
#dest_p4password=bruno

# The next 2 fields are required if email is to be used for notification of success or failure
mail_server=smtp.somewhere.uk
mail_from=rc@vaccaperna.co.uk
# Comment out either of the following two fields to not receive email notification
# Multiple addresses should be comma seperated
#mail_success_to=success@vaccaperna.co.uk
#mail_fail_to=fail@vaccaperna.co.uk,fail@somehwere.else

# Note that this is a standard Perforce view but LHS is source repository 
# and RHS is destination repository
# All the normal Perforce wildcards can be used.
# If there are spaces in paths then use quotes.
view:
   //depot/repl/src/... //depot/repl/dest/...
   "//depot/repl/src two/*" "//newdepot/repl/dest 2/*"

Usage

Basic usage is either to specify the ini file on the command line or it assumes "p4replicate.ini" exists in current directory.

Give "-v" option to output (lots of) debug info in case of error - otherwise just returns number of changelists transferred.

p4replicate.rb -v
p4replicate.rb --verbose
p4replicate.rb new.ini

c:\work> p4replicate.rb
Number of changes replicated: 1
Last change processed: 2917

c:\work> p4replicate.rb
Number of changes replicated: 0
Last change processed: 2917

Testing

For testing purposes you can use the same p4 server for source and dest. In between runs you will need to reset the p4replicate counter, e.g.

p4 counter p4replicate 0

(or some other value before first changelist to be replicated)

Obliterate the dest files so that area is nice and clean.

Note there is a partial test harness which needs to be considerably enhanced!

Notes

for any changelist that applied to more files than are in the replicate view, only the ones in the view are replicated - this can mean that changelists have different contents in source and target
it can cause problems if you start replicating with a "narrow" view and then try and widen the view later (including more files), since there are now older changelists that have already been partially replicated. Basically it won't cope with this (and it is not obvious what the right behaviour should be - don't do it!).
there is some commented out code to update existing source changelists descriptions but for those the user running the script must have superuser access
it stores processed changelists in a counter and increment after processing (don't zap this counter!)
expects to be only thing using the source/dest clients
creates source and dest clients on the fly or update already existing ones (warning - make sure people don't try and use the clients reserved for this script) - these are done using the replicate view from the config file. Both source and dest clients share the same root directory so the files are synched into source and then are in the right place to be added for dest.
the specified source and target views allow for spaces in filenames
each individual changelist that applies to the source client is then processed and every file in the changelist is handled separately (add/branch -> add, edit/integrate -> edit, delete -> delete). Obviously branching history is lost.
no changelists will be skipped over - so complete history of the file is replicated.
this also copes with things like edit with no changes to files etc
Use standard Windows scheduler ("at" command or Control Panel>Scheduled Tasks) to run on a regular basis as desired

Top