[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

How to manage client configurations for Rails project

From: John Almberg <jalmberg_at_identry.com>
Date: Mon, 18 Feb 2008 16:37:56 -0500

Howdy,

I have been using SVN to manage development of a Rails application.
The main line of development is in a repository called /svn/ts/
trunk/. I use Capistrano to automate deployment to my webserver.

I've now licensed this application to a number of clients. All these
clients will use the same code -- except for certain bits, such as
the files in the /config, /public/stylesheets, and /app/views/layouts
directories. These need to be different for each client, so each
client has his own database, etc., and his own graphic design.

Here is what I'd like to do:
        - use SVN to manage the main development in /svn/ts/trunk (this works)
        - use SVN to manage the client-specific code. Right now, the client-
specific code is not in SVN, simply because I can't figure out how to
do it correctly.
        - issue quarterly releases to all clients, which would include the
combination of trunk code, plus client-specific code for each client

For working on the client-specific code, I need to be able to check
out a combination of the trunk code + the client-specific code into a
project directory, so I can run Mongrel and script/console, and all
the other Rails goodies. In other words, I need a project directory
with the complete set of code for that client.

For doing releases, I need to be able to deploy the same set of code
to the webserver.

In the project directory for the main trunk, I want a generic set of
code, so I can do development, testing, etc.

Pretty straight forward stuff, but I'll be darned if I can figure out
how to use SVN to achieve this. I'm currently using a kludgy manual
procedure to prevent deployments from the trunk from blowing away
the client-specific code. That worked with the first couple of
clients, but I really need to figure out the correct way to handle
this, before the next client deployment.

Any hints, much appreciated!

Brgds: John
Received on 2008-02-18 22:38:25 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.