Setting up the environment:
Identify remote depot and conversion directory
Identify a remote Subversion depot you wish to synchronize with. The freebsd repository is at http://svn.freebsd.org/base. I am using /Users/nmorse/freebsd for the conversion directory.
Make sure subversion is set up on your system by running these commands:
$ svnadmin --version
$ svn --version
If you don't have it, download and install it from www.collab.net/downloads/subversion/
Get a copy of p4convert-svn.jar into your conversion directory:
Make sure java 1.6 is installed
$ java -version
Make sure p4perl is installed with the Getopt extensions
$ perl -MP4 -e "print P4::Identify()"
You'll need some additional scripts:
lockNrun.sh
You'll need a "lockrun" binary on your path
I've included "lockrun.c" which will need to be compiled for your OS.
Create and initialize a "clone" of the remote svn repository
I recommend using the "svnsync" utility to clone the remote svn repository locally.
It is possible to use rsvndump but it is hideously slow, so I recommend svnsync now.
svnadmin create svndepot
cd svndepot/hooks
cp pre-revprop-change.tmpl pre-revprop-change
svnsync needs special permissions to run, edit pre-revprop-change , changing the last few lines from:
if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then exit 0; fi
echo "Changing revision properties other than svn:log is prohibited" >&2
exit 1
to
if [ "$USER" = "svnsync" ]; then exit 0; fi
echo "Only the svnsync user can change revprops" >&2
exit 1
chmod +x pre-revprop-change
cd ../..
svnsync init --username svnsync file:///Users/nmorse/freebsd/svndepot http://svn.freebsd.org/base
You will see a response like: "Copied properties for revision 0"
Create a perforce environment on localhost
Create a perforce server, Remember the port you specified. The server must start empty.
Create a perforce workspace in ./p4_client
In ./p4_client make sure that you can access the new perforce server from the command line by setting
a $P4CONFIG environment variable and creating a P4CONFIG settings file, mine looks like this:
P4USER=perforce
P4CLIENT=svn-client
P4PORT=4446
Configure your scripts
Edit cron-p4import.pl, Look for "my $cvtRoot = 'path' and make sure it contains the full path to your conversion directory, like this:
my $cvtRoot = '/Users/nmorse/freebsd';
The $batchSize and $timeout variables may also be modified to change the desired "chunk size" for each time the cron job runs.
A bigger chunk size will import faster, but hog more system resources.
Customize your converter configuration file
Edit config.txt and make sure the following entries are correct for your choice of perforce server port and conversion directory.
The order of entries in the config file is not important except that the last two entries
(com.p4convert.svn.start and com.p4convert.svn.end) need to remain at the end of the file.
com.p4convert.p4.port=localhost\:4446
com.p4convert.p4.clientRoot=/Users/nmorse/freebsd/p4_client/
com.p4convert.log.out.filename=/Users/nmorse/freebsd/logger.txt
com.p4convert.svn.avd.p4root=/Users/nmorse/freebsd/p4_client/
You will also want to edit "crontab.src" to set the path and frequency with which the
converter will be called.
Controlling the conversion
On ubuntu, you can manage this script using cron
crontab -l Show existing crontab entries
crontab crontab.src Set up a cron job
crontab -r Remove a crontab entry
Files generated by the conversion
logger.txt - verbose output from the cron job
convert.log - output from the converter
changeMap.txt - A table mapping Subversion revisions to Perforce change IDs
audit.log - A log of each file converted, used for validation
current.dump - A partial subversion dump file, generated for use by the converter
lock.lockrun - A lock file to prevent concurrent execution of the converter
Bugs and Problems
1. Be consistent about which user runs the conversion (manually and from cron)
if a bunch of files get written by root, you will not be able to run again as a non-privileged user.
Feedback:
There are few things which would be really useful and easy to add:
1. configurable sleep time to prevent next job to start immediately
2. E-mail report in case of the failure
3. Lock file (separate from existing lockNrun) which would remain in the work
folder after crash, which would prevent cronjob from resuming work after the
failure.
I think that adding these mods will greatly improve reliability of the whole
process. If you think you can implement them, or even suggest where to add them,
I'd be happy to work with you on it.