Subversion and var/storage

Author Message

Greg McAvoy-Jensen

Friday 06 June 2008 11:33:22 pm

I've read posts about handling var/cache and var/log with svn:ignore. That makes sense. But should var/storage be handled the same way? What makes the most sense?

Granite Horizon, Certified Developer of eZ Publish Web Solutions
Provider of the SaaS Solution Granite Horizon In The Cloud | http://granitehorizon.com/cloud
http://granitehorizon.com | +1 916 647 6350 | California USA | @granitegreg
Blog: http://granitehorizon.com/blog

Gaetano Giunta

Saturday 07 June 2008 2:41:09 am

It makes sense to svn:ignore var/storage too for the two simple reasons:

- it will grow very big very fast, and putting it in svn will make your svn crawl to a grinding halt - especially if you keep your workspace on windows (not even taking into account a possible antivirus), but on unix too (just svn delete of the var/storage dir when linked to repo over https over internet took me an hour or so)

- as soon as you have made a first copy of your dev server install to a test, integration or production setup, the different installs will diverge as for content present. Devs will create test content in the dev eZ to check out new templates, editors will usually start to fill in real content in the integration or prod installs, etc. Some identical content will be created by hand in both eZP installs, resulting in different files in var/storage

In short: have svn ignore it. When you need to resync your data from eg. prod to dev, copy over at the same time both the db and the storage, and you're done

Principal Consultant International Business
Member of the Community Project Board

Greg McAvoy-Jensen

Saturday 07 June 2008 6:39:53 am

Thanks, Gaetano.

That's what I thought, but wanted to be sure I wasn't missing something since the article (http://ez.no/developer/articles/using_subversion_with_ez_publish) listed var/cache and var/log but not var/storage or simply "var".

Granite Horizon, Certified Developer of eZ Publish Web Solutions
Provider of the SaaS Solution Granite Horizon In The Cloud | http://granitehorizon.com/cloud
http://granitehorizon.com | +1 916 647 6350 | California USA | @granitegreg
Blog: http://granitehorizon.com/blog

Greg McAvoy-Jensen

Monday 23 June 2008 11:30:45 am

One follow-up question: does this mean that if we're using the ignore property on the var directory, we should never use svn commit from the root ezpublish directory?

I'm new to SVN, and assumed after doing whatever changes I wanted (template override settings, extension design, etc.) I would then just do a svn commit from the root ezpublish directory--but this updates the var directory even with propset ignore. Am I missing something?

And is the same true on the testing and production servers--we should only use svn update on the specific directories we've made changes to? It seems to make us more prone to errors.

Thanks for any thoughts.

Granite Horizon, Certified Developer of eZ Publish Web Solutions
Provider of the SaaS Solution Granite Horizon In The Cloud | http://granitehorizon.com/cloud
http://granitehorizon.com | +1 916 647 6350 | California USA | @granitegreg
Blog: http://granitehorizon.com/blog

Maxime Thomas

Wednesday 26 January 2011 6:02:36 pm

Hi Greg,

Another point you can focus on : some extension are generating data inside the extension and not inside the var directory.

Typically ezfind has its own index under /extensions/ezfind/java/solr/data.

Max

Maxime Thomas
[email protected] | www.wascou.org | http://twitter.com/wascou

Company Blog : http://www.wascou.org/eng/Company/Blog
Technical Blog : http://share.ez.no/blogs/maxime-thomas

Gaetano Giunta

Saturday 29 January 2011 2:33:17 am

@maxime a good point. And I think we should in fact fix those extensions,as the 'ez' way is to only have variable data in /var.

Apart form ezfind, any other known offender?

Principal Consultant International Business
Member of the Community Project Board

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.