Forum: Ruby on Rails subversion setup for maintaining customizations to base code

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
0bcc972918891ef358b0b3dfb4e7f18b?d=identicon&s=25 Hammed Malik (Guest)
on 2006-05-04 01:54
(Received via mailing list)
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.
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 François Beausoleil (fbeausoleil)
on 2006-05-04 02:46
(Received via mailing list)
Hi !

2006/5/3, Hammed Malik <hammed@gmail.com>:
> 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
=======
http://svk.elixus.org/
"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 !
0bcc972918891ef358b0b3dfb4e7f18b?d=identicon&s=25 Hammed Malik (Guest)
on 2006-05-04 03:10
(Received via mailing list)
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/subver...)
Thanks!

Hammed
3dd4b52a0946bd698b1d1635a46ea3a3?d=identicon&s=25 François Beausoleil (fbeausoleil)
on 2006-05-04 04:17
(Received via mailing list)
Hi !

2006/5/3, Hammed Malik <hammed@gmail.com>:
> 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 !
59de94a56fd2c198f33d9515d1c05961?d=identicon&s=25 Tom Mornini (Guest)
on 2006-05-04 04:36
(Received via mailing list)
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

-- -- Tom Mornini
This topic is locked and can not be replied to.