Blake, here's how we do it: svn: each project has a separate set of code trees: eg. svn://host/project/trunk , svn://host/project/tags , svn://host/project/branches each developer has read/write access to the projects they're working on
Development: (developers only) dev server has its own database server each developer has an account on the dev server and checks out the code repository into their own file space which is accessed via sftp and ssh I use MacFuse to mount the directory on my Mac so I can use TextMate etc, others login and use vi to edit their files (they could just as easily use vi on their Mac or whatever suits) eg. svn co svn://host/project/trunk /home/developer/www/project apache has virtual host entries for each developer & project like this: http://project.developer.dev/ maps to /home/developer/www/project this way every developer can work independently of every other developer and everyone else Test: (developers & testers & other interested people) test server has its own database server projects are checked out into separate directories in the web tree eg. svn co svn://host/project/trunk /home/apache/www/project apache has a virtual host entry for each project like this: http://project.test/ maps to /home/apache/www/project this gives testers and others a stable environment for their use it can be updated as needed or on a predictable schedule appropriate for each project Production: (public facing) production servers share a single database server set up like test with host names changed as appropriate Development work is never done on live. All changes start on dev, are commited to svn and migrated through to live. Some advantages: all code stays on managed servers, database accesss can be secured to the appropriate servers, developers can work completely independently (possible exception of some database changes), developers don't have to worry about apache configuration/administration, consistent development environment for everyone, developers don't have to worry if they have the right modules and versions required Some disadvantages: dev server has multiple copies of the code base, some additional apache administration to set up the virtual hosts on dev, assumes a formal arrangement with each developer Alternatively, each developer could set up their own database and apache server, check out the code base onto their own machines and test locally. For FOSS appilcations, this is probably the better choice. It sounds to me like you're missing the 'test locally' part. If you're on a Mac you might be able to use the apache environment that ships with it. If not, you can probably update apache etc to the required version levels. If you're doing some low-level system stuff that might not be good enough. If you're on an Intel system you could use VMWare and install an appropriately configured LAMP stack. If you're on Windows, you will almost certainly have to do that. Hope that helps, Carl On Tue, Jan 20, 2009 at 1:14 PM, electBlake <[email protected]> wrote: > Calling All Code Junkies! > Blake here, from the VULab project and I'm having problems figuring out a > good way to setup my development workflow. > My Preference. > I enjoy working on a live development server so I can fully see how my php > code is going to behave on a standard LAMP situation, as such I also enjoy > using an integrated ftp code writing client. > The Problem. > York University, where VULab is hosted is like many other private and secure > server clusters that don't allow the ftp protocol to be used to access their > servers. The sftp option falls short as with my current permissions I need > to sudo <cmd> to have write access. > The Current Situation. > Currently I am biting the bullet and I am developing the site locally, and > then submitting my patches to svn and after the patches have been committed > I ssh into the server (vulab.yorku.ca) and checkout the latest from the svn. > This works but like I stated in My Preference, I enjoy seeing my code on the > final server setup asap. > > The Solution(s)? > I am curious as to how you other fluid'ers are developing and what your > workflow is. Be as details or straight forward as possible. I am new to > working within a svn workflow so I feel like I am missing something. > > Thanks! > - Blake > > > > > > _______________________________________________________ > fluid-work mailing list - [email protected] > To unsubscribe, change settings or access archives, > see http://fluidproject.org/mailman/listinfo/fluid-work > > -- Start by doing what's necessary; then do what's possible; and suddenly you are doing the impossible. -- Saint Francis of Assisi _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
