2006/5/3, Hammed M. firstname.lastname@example.org:
I’d like to set up svn to maintain customizations to my base app for
each client. A simple example would be to have a base CSS file and a
custom one for each client. What is the best way to set up svn so I
can ‘co’ the trunc and then ‘co’ customizations for each client on top
of the base code.
I’ve looked into branches but unless I’m misunderstanding their usage,
they wouldn’t work the way I’d like them to.
Well, you have a couple of options here:
- Use customer branches
- Use svn:externals
- Use svk
- Using Engines
You create a branch per customer, and you have a mainline somewhere
(trunk/) on which you do development. On every commit, you have a
script that merges the changes from trunk/ to each of your customer
branches, and runs the tests. If anything fails, that’s the end of
the world and the whole team steps in to correct the issue.
- Customer changes are isolated from each other
- Anything can be changed on a per customer basis
- Heavy weight
- Need lots of scripting-fu (although Ruby makes that pretty easy)
to make it work
Here, you do your development on trunk/, and you have your custom CSS
files sitting in a sub-folder of public/stylesheets. Something like:
During development, you switch public/stylesheets/custom to the
appropriate repository location to work on the CSS. When you are
ready to deploy to a customer, you copy trunk/, remove
public/stylesheets/custom and set svn:externals on public/stylesheets
to “custom -r2912 /stylesheets/37signals”. You check that in, and
upload this branch to the customer’s site.
- Easier to setup
- Faster to work on
- NO merging
- More steps to release code (although this can be automated with
- Creates lots of dead branches in the tree, although they don’t
take much more space since Subversion is copy-light, and can be
removed to keep a
“svk is a decentralized version control system built with the robust
Subversion filesystem. It supports repository mirroring, disconnected
operation, history-sensitive merging, and integrates with other
version control systems, as well as popular visual merge tools.”
Using svk would be very similar to using branches per customer, except
svk would handle the merging details instead of you having to do it
manually or with scripts.
- Merging is VERY much simplified
- Can use svk to manage externals projects (Rails, plugins, etc)
- New tool to learn (although the command line syntax is similar to
Engines allow you to share models, controller, views and resources as
plugins. Simply deliver a copy of your application with the
“customerA” engine. Then in your layout files, use the
engine_stylesheet helper to load the stylesheets.
This is almost identical to svn:externals above, including advantages
There ya go. If I were you, I’d probably start with engines or
externals, and see where that goes. These two options are the ones
that cost the least to setup.
Alternatively, there was a “productization” generator that would allow
you to have multiple very similar web sites all based on the same code
base. It’s probably almost hopelessly out of date now. You’d have to
bring it up to date to use it.
Hope that helps !