# Subversion setup for maintaining customizations to base code **URL:** \ **Category:** Rails\ **Created:** [May 4, 2006, 1:54am UTC](https://www.ruby-forum.com/t/subversion-setup-for-maintaining-customizations-to-base-code/59550 "2006-05-04T01:54:51Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Hammed\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7feea3/32.png) [@Hammed\_M](https://www.ruby-forum.com/u/Hammed_M)\ **Post date:** [May 4, 2006, 1:54am UTC](https://www.ruby-forum.com/t/subversion-setup-for-maintaining-customizations-to-base-code/59550/1 "2006-05-04T01:54:51Z")
To the subversion experts out there: 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. ---
**Author:** ![Hammed\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7feea3/32.png) [@Hammed\_M](https://www.ruby-forum.com/u/Hammed_M)\ **Post date:** [May 4, 2006, 2:46am UTC](https://www.ruby-forum.com/t/subversion-setup-for-maintaining-customizations-to-base-code/59550/2 "2006-05-04T02:46:44Z")
Hi ! 2006/5/3, Hammed M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > 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: 1. Use customer branches 2. Use svn:externals 3. Use svk 4. Using Engines # Customer Branches 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. ## Advantage - Customer changes are isolated from each other - Anything can be changed on a per customer basis ## Disadvantage - Heavy weight - Need lots of scripting-fu (although Ruby makes that pretty easy) to make it work # Using svn:externals Here, you do your development on trunk/, and you have your custom CSS files sitting in a sub-folder of public/stylesheets. Something like: public/stylesheets/custom 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. ## Advantages - Easier to setup - Faster to work on - NO merging ## Disadvantage - More steps to release code (although this can be automated with scripts) - 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 # Using svk > **[Elixus.org : le média de vos informations.](https://www.elixus.org/)** > > Elixus.org : News, Informations et Actualités est un magazine participatif sur lequels les meilleurs auteurs viennent diffuser leurs informations. “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. ## Advantages - Merging is VERY much simplified - Can use svk to manage externals projects (Rails, plugins, etc) ## Disadvantages - New tool to learn (although the command line syntax is similar to svn’s) # Using Engines 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 and disadvantages. 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 ! ---
**Author:** ![Hammed\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7feea3/32.png) [@Hammed\_M](https://www.ruby-forum.com/u/Hammed_M)\ **Post date:** [May 4, 2006, 3:10am UTC](https://www.ruby-forum.com/t/subversion-setup-for-maintaining-customizations-to-base-code/59550/3 "2006-05-04T03:10:54Z")
Hi Francois, Thanks for the detailed and informative response. I’ve been following Engines for a while and I think I’ll be refactoring my app into Engines in the near future. That combined with externals seems to be the best option for me. I took a quick look at svk as well. Are svk repositories accessible with tools like Trac (since it’s based on subversion) ? BTW, I also read your excellent Subversion primer ([http://blog.teksol.info/articles/2006/03/09/subversion-primer-for-rails-projects](http://blog.teksol.info/articles/2006/03/09/subversion-primer-for-rails-projects)) Thanks! Hammed ---
**Author:** ![Hammed\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7feea3/32.png) [@Hammed\_M](https://www.ruby-forum.com/u/Hammed_M)\ **Post date:** [May 4, 2006, 4:36am UTC](https://www.ruby-forum.com/t/subversion-setup-for-maintaining-customizations-to-base-code/59550/4 "2006-05-04T04:36:23Z")
SVK depots ARE Subversion repositories in every respect. SVK depends on a public Subversion repository for the master repository. SVK users can freely collaborate with regular Subversion users on Subversion based projects. What SVK does is allow repository synchronization. So, you can have a synchronized LOCAL copy of the master repository on your personal machine. Additionally, you can make local branches of repositories, allowing a user to commit their changes locally without sending them to the master repository. This is extremely useful when you’re working on a project that will take some time. SVK’s merge tracking is useful because it allows you to keep your local branch in sync easily with changes in the main repository (merging) and similarly allows for a massive commit (one single commit or multiple, you choose!) back to the main repository once you’re done. I love the ability to work and commit even when I cannot pass tests. I also love committing in the park and on airplanes. 🙂 I don’t actually see how SVK is a solution to the customized application development problem discussed in the thread. I suppose you could create a master repository, create branches with SVK on a server, then allow people (with or without SVK) to use those Subversion repositories to develop against, and use SVK to merge the repositories more easily than without it. That said, I think the svnmerge script would be more effective and more direct in tackling that particular problem: [http://tinyurl.com/jr8f5](http://tinyurl.com/jr8f5) – – Tom M. ---
**Author:** ![Hammed\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/h/7feea3/32.png) [@Hammed\_M](https://www.ruby-forum.com/u/Hammed_M)\ **Post date:** [May 4, 2006, 4:17am UTC](https://www.ruby-forum.com/t/subversion-setup-for-maintaining-customizations-to-base-code/59550/5 "2006-05-04T04:17:53Z")
Hi ! 2006/5/3, Hammed M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > I took a quick look at svk as well. Are svk repositories accessible > with tools like Trac (since it’s based on subversion) ? I’m not sure about that one. Yes it uses a plain Subversion repository, but I think it manages the internals a bit differently. It probably uses branches and other things. You’d have to ask the SVK guys to know. Bye !