|
Monday 23 October 2006 5:38:40 am
I heard of people using symbolic links to versioned files instead of placing the entire eZ publish installation into svn. The idea being if you don't modify the 'stock' eZ publish core (non-meta). By doing this can make upgrading eZ publish installation simpler. As you do not have to deal with svn committing core files after an eZ publish upgrade (or conflicts). Leaving eZ publish core files are loosely coupled to the versioned meta files via symbolic links in a non-versioned eZ publish installation directory. Running a kind of eZ publish 'build script' which performs the following commands
1) extract 'stock' eZ publish (core)
2) move 'stock' meta folders (avoid conflict with core directories)
3) create symbolic links from 'stock' meta folders to subversion directory structures (override core)
# base_path="/web/pro/"
# cd $base_path
# tar -zxf /web/arc/src/ez/ezpublish-3.7.6-gpl.tar.gz
# cd ezpublish-3.7.6
# mv extension .extension
# mv design .design
# mv var .var
# ln -s ../example.com/favicon.ico favicon.ico
# ln -s ../example.com/extension extension
# ln -s ../example.com/design design
# ln -s ../example.com/var var
# ln -s ./bin/shell/clearcache.sh clr
cd settings
# mv override .override
# mv siteaccess .siteaccess
# ln -s ../../example.com/settings/override override
# ln -s ../../example.com/settings/siteaccess siteaccess
This also allows me to svn status /web/pro/example.com (svn versioned eZ publish directories) in one command, including commits, etc! I also hear you can simply <i>not</i> commit cache files (yet I hear of many do add non-recursively the key top level directories in the various used in the cache directory structure). I've even heard of people who will hand-commit files added, modified and removed from 'var/plain/storage' and 'var/log/*' as these are fairly simple commands to script if performing these commits by hand are too time consuming. Excluding the directories '/var/cache/*', '/var/plain/cache/*' is simple enough to do. It sounds a little time consuming to have a versioned (where applicable or useful) 'var/' directory structure / eZ publish installation meta files required by db. Without saying I hear of many performing backups of the eZ publish database on a regular plan and schedule (which should increase to match the frequency of changes to it, for example active sites might backup more frequently to protect their live eZ publish db data). While for others looser scheduled backups of both the eZ publish db and files (semi-quarterly) is sufficient. mysqldump --skip-opt --single-transaction example_com_pro_376 -p > /web/arc/caption/db/sql_example_com_pro_376__20061123_072842_001.sql
Upon considering the amount of svn commits required to keep file 'var/plain/storage' modifications of a very high traffic eZ publish installation's 'var/' directory stored in subversion. I wonder if an eZ publish extension (name guess: ezversionedvarsvn) which when activated and configured would override a base class in eZ publish, say in relationship to 'var/<siteaccess>/storage' to include transparent automation of subversion commits to the added, modified, removed files would not simplify my say quarterly svn maintenance. In a way perhaps providing duplicate functionality as the hand commits (logged of course) yet remove the requirement of human management (which may or may not be necessary).
//kracker
<i>film: the trail of the pink panther ...</i>
Member since: 2001.07.13 || http://ezpedia.se7enx.com/
|