Rails - May 2006 - subversion setup for maintaining customizations to base code

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.

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 !
--
Fran?ois Beausoleil
http://blog.teksol.info/

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)
Thanks!

Hammed

On 5/3/06, Francois Beausoleil <francois.beausoleil@gmail.com>
wrote:
> 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 !
> --
> Fran?ois Beausoleil
> http://blog.teksol.info/
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
>
>

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 !
--
Fran?ois Beausoleil
http://blog.teksol.info/

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

On May 3, 2006, at 7:15 PM, Francois Beausoleil wrote:
> 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 !
> --
> Fran?ois Beausoleil
> http://blog.teksol.info/
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails