Forums / Developer / cvs and Ez 3.2 developing

cvs and Ez 3.2 developing

Next topic

Author	Message
Tore Skobba	Monday 29 September 2003 8:58:33 am Hi all I working on developing an fairly complex website for an Norwegian school, or program (www.grunderskolen.no). During this I find it nice to have all code etc. checked into an cvs tree. I have done this and I have some questions I hope someone can answer, or give me some genreal tips on. I checked out and installed an plain Ez 3.2 verion, set up my site and edited the site.ini.append files in order to be as general as possbile(i.e siteurl is localhost/...). This in order to get an cvs checkout version up and running as fast as possible. However, all checkout versions are connecting to the same database, could this present some problems with for instance images in articles? In my current setup the folder "var" is included in the tree, however all "cache" subfolders are ignored. This as I think that all article, or content objects images are stored under /var/sitedesign/storage/, is this correct? Could someone please comment on my setup, does it seems correct or will this not work? Anyone else has any experince on using CVS while developing an EZ site which has some experince to share? Cheers Tore
Paul Forsyth	Monday 29 September 2003 2:34:09 pm Do you mean you use the same database for each checked out project? If your project is separate this would obviously cause problems. We use cvs all of the time when building projects with ez. We have chosen to minimise the number of checkins to cvs to only those areas we change. For example, we version control: - design/user (own design) - settings (only some, such as siteaccess and override) - storage (from var/storage) - extension (for anything we add to the kernel) - database (our sql dump) - patches (changes to the kernel we need). When we put a new ez kernel in we run scripts/ant to configure it and to put symlinks into our checked out code. In this way we never need to check in an ez kernel. In my opinion it isn't practical to do this since the kernel changes frequently (svn etc). The var/storage directory is kept in cvs as a .tgz file, since we don't really care about versioning every image inside the storage dir. Other than this the other files are usually text files and version quite nicely :) Hope this helps you. Let me know. Paul
Tore Skobba	Tuesday 30 September 2003 1:56:28 am Hi Paul No, I am not using the same database for different project:), this is only a single project. As such I am using one database which all the equal checkout CVS projects are connecting to. I have checked in all except cache, but I notice that update takes a long time. However, since it seems that I am the only one supposed to develop I think I can live with this (i.e rarly updating)... Secondly it will be very nice at release just to do a checkout in the live site:). Thirdly, kernel changes are possible to track and undo. But I do see your point in keeping the checked in elements at a minimum. And I do think I would opt for such an solution if I was having several projects. However, as I have only one project I can live with the overhead, copying your solution is gonna cost me losts of time. Thanks for the info:). Small tip: Try out Eclipse (http://www.eclipse.org/) for EZ developing, Eclipse nicely integrates with CVS and has an fairly ok text editor.
Paul Forsyth	Tuesday 30 September 2003 3:41:12 am Eclipse is what we use too :) Fantastic piece of software. We use a few plugins too for it to give us php functions plus css syntax colouring. A subversion plugin is just round the corner too: subeclipse.tigris.org (works for windows but not quite for linux yet). When we first looked at a development environment to work with ez we did consider checking it in. But as you rightly say that approach doesn't quite work for multiple projects. Instead we keep a local version of the ez svn repository. Once svn opens up again for outside users (soon i hope) i would suggest doing this. Then you can export a version for your own use whenever you want while keeping the local svn repository separate. Search for the svn docs here to see what i mean. I think there a few examples of usage there. For a single project what you are doing is fine. But if you try more then its worth considering taking the time 'hit' and moving to a more extendible environment. To give you an example, to set up a new site on our system takes very little time. We just unpack our ez kernel, drop it in, run our scripts to set the system up and thats it (not including apache/mysql setup). But with this we can easily drop in an updated kernel and change a symlink and test away. Paul
Jonny Bergkvist	Wednesday 01 October 2003 12:48:35 am Hi! We use CVS for the new template-files and settings we do in eZ. We use all the override, and append-support in eZ, and then we never need to change anything in the standard distribution, we just add own files - and these files we do CVS-versioning on. At first we did CVS-versioning of the whole eZ-site including our own overrides, and the standard distribution, but we soon found out that this was not a good way to do it. It make it more work when you are upgrading to a newer version, and slower to do CVS-commands. I use Windows as my client, and I use TortoiseCVS which integrates nice into Windows shell (I use Samba to access the files on our eZ-server). We have one or more site's for each person that do development, and we have one official prototype-site. We only work on templates on our own sites (usually we use the same database as the prototype-site), then we do cvs commit on our changes, and the script under creates the prototype site (with cvs checkout etc.) On our server we use this script to make our prototype-site (not in production yet) get updated with the latest from CVS (comments are in Norwegian): #!/bin/sh # Dette kjøres i crontab, og kan i tillegg kjøres manuelt. # Scriptet oppdaterer site'n SITE.hit.no med siste # oppdatering fra HiT-CVS. cd /www # Flytter var-katalogen midlertidig... mv /www/SITE/var /tmp/SITE_var # Pakker ut ezpublish tar -xvf /root/SITE_autoupdate/ezpublish-3.2-1.tar # Fjerner ezpublish rm -rf /www/SITE mv ezpublish-3.2-1 SITE tar -xvf /root/SITE_autoupdate/editor-1.2.tar # Henter ut CVSen mkdir /tmp/SITE-cvs cvs -d /var/lib/cvs checkout -d /tmp/SITE-cvs ezpublish cp -r /tmp/SITE-cvs/* /www/SITE/ rm -rf /tmp/SITE-cvs # Tar over spesialsettinger cp /root/SITE_autoupdate/site.ini.append.php /www/SITE/settings/override/ cd /www/SITE # Legger tilbake var-katalogen mv ./var ./var.org mv /tmp/SITE_var var # Fikser rettigheter chmod 755 ./bin/modfix.sh chmod 755 ./bin/shell/clearcache.sh ./bin/modfix.sh # Sletter evt. cache ./bin/shell/clearcache.sh --clear-all