[sf-perl] one install path, multiple repository paths
extasia at extasia.org
Tue Apr 29 08:07:40 PDT 2008
i do tools for our release engineering group. i'm looking for
ways to improve my deployment packaging code (i.e., suck code out of
repository in order to spew onto machines). the following is
something about which i'd like to pick your brains.
say you have a single install path for which you have multiple
repository paths. how do you lay out the files in your repository?
do you differentiate the versions by filename? by the tree they're
in? do you tokenize a single repository copy and have some program
replace the tokens with values specifc to a given environment before
certain files, we like to keep under a "root tree" in the repository.
that is, a directory literally called 'root' to indicate that the path
of a file under this tree is the install path (sort of...).
assume that 'some-service' is a service that starts one of our
in-house applications. it's startup script will be installed on all
machines as </etc/init.d/some-service>. if we had only a single
version of it, we'd keep it in a root tree as:
however, we have environment-specific versions of it that we keep in
the repository as:
to further complicate matters, different hosts within an given qa or
production environment play different roles (db, mail server,
app-specific roles, etc.). in some cases we keep environment- *and*
we refer to the directories prod, qa-env-NN, role-NN, as "qualifier"
directories, with the idea that the install path of a file is its
repository path under 'root' with the qualifier directory components
removed. all of the repository paths in the examples above would be
installed to </etc/init.d/some-service> on the appropriate host. i
suppose we could just as easily keep all versions in
.../root/etc/init.d/ and qualify the file basenames rather than
qualify the directory path components.
i figure there are a bunch of folks on the list that run into this
situation. i'm curious what your approach is.
 a perl island in a sea of java :-(
 versions, as in, simultaneously existing repository files with
different content that share a single install path. not, as in,
revisions over time of a given repository file.
Live in a world of your own, but always welcome visitors.
More information about the SanFrancisco-pm