[sf-perl] one install path, multiple repository paths
friedman at highwire.stanford.edu
Tue Apr 29 08:55:20 PDT 2008
My group is going through this exercise right now of how to organize
"files that are installed based on their svn path, but can be
customized/overridden by another path". The discussion has been along
the lines you were talking about: files vs. directories. It looks like
we are going to end up with a little bit of both. So, to use your
situation as an example, we're going to end up with:
as the default shared location. Then a script will pull any overridden
Our system is complicated because we're using symlinks in SVN. (I
don't know how they work or what they're really called, that's just
how it was explained to me.) So we do the custom overrides *inside*
SVN. Then deploying is a simple svn checkout. That means we also have:
.../build/prod.role-01/etc/init.d/some-service@ (a symlink)
which is gathered from the previous two items and also stored in SVN.
That would be a symlink to either the root shared file or the custom
file, depending on the existence of a custom file. It gets more
complicated when we deploy both the shared and custom files and
'include' one in the other using apache & tomcat include directives,
but I don't understand that part yet. :-)
In any case, when a change is made to a file in the repository, *any*
file, we will rerun all the builds to make sure they're all up-to-
date. Then we can deploy at will or on an automated schedule.
I don't know if this helps, but we've had a number of
arguments^Wdiscussions about this and this was the winning proposal. I
think it's a challenging problem to solve and no one solution will
work for every situation. YMMV. TIMTOWTDI.
On Apr 29, 2008, at 8:07 AM, David Alban wrote:
> 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*
> role-specific versions:
> 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.
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
Michael Friedman HighWire Press
Phone: 650-725-1974 Stanford University
FAX: 270-721-8034 <friedman at highwire.stanford.edu>
More information about the SanFrancisco-pm