This section is from the "Version Control with Subversion" book, by Ben Collins-Sussman, Brian W. Fitzpatrick and C. Michael Pilato. Also available from Amazon: Version Control with Subversion.
Vendor drops that contain more than a few deletes, additions, and moves complicate the process of upgrading to each successive version of the third-party data. So Subversion supplies the svn_load_dirs.pl script to assist with this process. This script automates the importing steps we mentioned in the general vendor branch management procedure to make sure that mistakes are minimized. You will still be responsible for using the merge commands to merge the new versions of the third-party data into your main development branch, but svn_load_dirs.pl can help you more quickly and easily arrive at that stage.
In short, svn_load_dirs.pl is an enhancement to svn import that has several important characteristics:
It can be run at any point in time to bring an existing directory in the repository to exactly match an external directory, performing all the necessary adds and deletes, and optionally performing moves, too.
It takes care of complicated series of operations between which Subversion requires an intermediate commit—such as before renaming a file or directory twice.
It will optionally tag the newly imported directory.
It will optionally add arbitrary properties to files and directories that match a regular expression.
svn_load_dirs.pl takes three mandatory arguments. The first argument is the URL to the base Subversion directory to work in. This argument is followed by the URL—relative to the first argument—into which the current vendor drop will be imported. Finally, the third argument is the local directory to import. Using our previous example, a typical run of svn_load_dirs.pl might look like:
$ svn_load_dirs.pl http://svn.example.com/repos/vendor/libcomplex \ current \ /path/to/libcomplex-1.1 …
You can indicate that you'd like
svn_load_dirs.pl to tag the new vendor drop
by passing the -t
command-line option and
specifying a tag name. This tag is another URL relative to
the first program argument.
$ svn_load_dirs.pl -t libcomplex-1.1 \ http://svn.example.com/repos/vendor/libcomplex \ current \ /path/to/libcomplex-1.1 …
When you run svn_load_dirs.pl, it
examines the contents of your existing “current”
vendor drop and compares them with the proposed new vendor
drop. In the trivial case, there will be no files that are in
one version and not the other, and the script will perform the
new import without incident. If, however, there are
discrepancies in the file layouts between versions,
svn_load_dirs.pl will ask you how
to resolve those differences. For example, you
will have the opportunity to tell the script that you know
that the file math.c
in version 1.0 of
libcomplex was renamed to arithmetic.c
in
libcomplex 1.1. Any discrepancies not explained by moves
are treated as regular additions and deletions.
The script also accepts a separate configuration file for
setting properties on files and directories matching a regular
expression that are added to the
repository. This configuration file is specified to
svn_load_dirs.pl using the
-p
command-line option. Each line of the
configuration file is a whitespace-delimited set of two or
four values: a Perl-style regular expression to match the
added path against, a control keyword (either
break
or cont
), and then
optionally a property name and value.
\.png$ break svn:mime-type image/png \.jpe?g$ break svn:mime-type image/jpeg \.m3u$ cont svn:mime-type audio/x-mpegurl \.m3u$ break svn:eol-style LF .* break svn:eol-style native
For each added path, the configured property changes whose
regular expression matches the path are applied in order,
unless the control specification is break
(which means that no more property changes should be applied
to that path). If the control specification is
cont
—an abbreviation for
continue
—then matching will continue
with the next line of the configuration file.
Any whitespace in the regular expression, property name,
or property value must be surrounded by either single or
double quote characters. You can escape quote characters that
are not used for wrapping whitespace by preceding them with a
backslash (\
) character. The backslash
escapes only quotes when parsing the configuration file, so do
not protect any other characters beyond what is necessary for
the regular expression.