I am familiar with Subversion's recommended layouts of
branches/tags/trunk and on how vendor branches are usually used, but I
am stumped designing a proper layout for my new project.
I am going to deploy a SugarCRM and it needs modifications, which I want
under version control of course. For normal software I'd simply use
vendor branches like explained in the svn book, but for Sugar this
doesn't work. It's a web app and it has a database. If I were to upgrade
from version X to version Y using standard vendor branches, I would only
get source code changes but the code that modifies the database is never
When there is an update for SugarCRM you get a zip package that you can
upload inside the web application. It contains two things: An updated
set of source code files, which are simply copied over the old ones (it
contains only the files that have changed) and a set of post-install
scripts, which are executed after the new source files have been copied.
These post-install scripts modify the database structure *and data* to
match the new version.
How would I design my repository so I can work with such a set-up?
Should I set it up such that I take the 5.0-to-5.1 upgrade, see which
new source files are in there, re-apply my modifications and use the
modified zip on my test install?
Or, perhaps remove all the source code from those zip upgrades, keep the
source in vendor branches, `svn merge` the changes between 5.0 and 5.1
to my modified 5.0, `svn update` my test installation and use the
upgrade zip only to update the database?
How do other people manage local modifications to web applications that
use a database? Surely I'm not the first to tackle this problem :-) I
know that for example phpBB, mediawiki and many other web apps use the
same method as SugarCRM: Ship an upgrade that contains the changed files
plus a script to update the database.
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-30 23:33:48 CEST