[sf-perl] one install path, multiple repository paths

Michael Friedman 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  
files from:



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.

Good luck!
-- Mike

On Apr 29, 2008, at 8:07 AM, David Alban wrote:

> greetings,
> i do tools[1] 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[2] 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
> deployment?
> 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:
> .../root/etc/init.d/some-service
> however, we have environment-specific versions of it that we keep in
> the repository as:
> .../root/etc/init.d/prod/some-service
> .../root/etc/init.d/qa-env-01/some-service
> .../root/etc/init.d/qa-env-02/some-service
> 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:
> .../root/etc/init.d/prod/role-01/some-service
> .../root/etc/init.d/prod/role-02/some-service
> .../root/etc/init.d/qa-env-03/role-01/some-service
> .../root/etc/init.d/qa-env-03/role-02/some-service
> 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.
> thanks,
> david
> [1]  a perl island in a sea of java  :-(
> [2]  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
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm

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 mailing list