Robert Cummings wrote: > On Thu, 2006-09-21 at 18:11 -0400, tedd wrote: >> At 2:21 PM -0700 9/21/06, Chris W. Parker wrote: >>> Hello, >>> >>> This is off topic but I wanted to get the list member's opinions on the >>> subject as it will probably benefit someone else. >>> >>> -snip- >>> >>> Is this a sound strategy or should I just realize that I can't publish >>> until all current features enhancements are completed? >>> >>> >>> Thanks, >>> Chris. >> Chris: >> >> I've been thinking about this as well. Please forgive my naiveness if >> the gang already has a better way, but the method I used to do >> application development was that I started with a folder that >> contained all my code, which I named v1.0. >> >> Whenever I reached a milestone of some type I thought significant, I >> duplicated the entire working folder; renamed the duplicate the next >> version (i.e., v1.01); and started working with the new folder. If I >> screwed up, then I could always trash the new folder, duplicate the >> previous version and start again. It was a system that worked for me. >> >> At the end of the development cycle, I would have a long thread of >> development versions. Often, I found that intermediate folders >> provided branches for other development -- so, keeping intermediate >> development versions was a plus. >> >> Now, it's a bit different working with folders on the web because you >> have one "root" (live) folder and making changes can be problematic. >> However, there's enough similarity that I often follow the same >> method as I used in application development. >> >> For example, my current site http://sperling.com is alive and running >> well. However, I am doing a complete rewrite of the site. As such I >> duplicated the entire site and placed it in another directory, >> namely: http://sperling.com/a -- and I work on that. >> >> When I feel that revision is ready, I will save the current "root" >> directory to my desktop, delete it on my server and then pull >> everything out of my "a" directory and make it the new root. For me, >> that would take just a few minutes. For more complex sites, where the >> change must be instant, I would look into using the .htaccess file to >> change the root index. >> >> If there are better development schemes, I would like to hear about >> them as well. > > Use CVS or SubVersion already. I'm not familiar with SubVersion, though > from what I hear it's has all the features of CVS.
I would strongly recommend subversion over CVS. I've used CVS for many years and can't believe how much better things are now I've switched to SVN. I second Brad's recommendation of reading http://subversion.red-bean.com/ - The Subversion Book. It makes for excellent reading. You can quite easily work on a "trunk" project, make multiple changes and use it for general development work. (e.g. /trunk/myproject/) When you are ready for your first deployment, you create a "staging" branch (/branches/myproject/staging) using the "svn cp" command. You then test this version in a simulated live environment. Other developers can carry on working on /trunk/myproject while you work. If you need to make any changes (e.g. bugs found during staging process), just commit to the /branches/myproject/staging branch (don't worry we'll merge this back to trunk in a bit). Once you are happy, you are ready for the first deployment. Use "svn cp" to create your deployment branch (e.g. /branches/myproject/deployed). Also to keep a permanent record, you should tag this deployment (again using "svn cp" to e.g. /tags/myproject/deployed-20060922010000). On your production environment, just check out /branch/myproject/deployed (you could use the tag, but it will be more complex when updating on next deployment (it would require using "svn switch" rather than just "svn up"). Now just merge any commits made to the staging brach back to trunk (use "svn merge"). Now carry on development. Now you're ready for deployment 2! This time the staging branch has already been made so no need to use "svn cp" to create it. Just svn merge all the changesets made to trunk since your last deployment. Again test it and commit any required bugfixes. Then use svn merge to apply all the changesets in the staging branch to the deployment branch since you lasted deployed (it may just be one, but could be more if there are bugfixes). Once you have commited these changes, make a new tag with "svn cp" for your records (tags do not take up any real disk space to don't worry about them even if your project is huge!) On your production environment just run "svn up". Oh, don't forget to merge any bugfixes made to your staging branch back to trunk! If in an emergency you need to roll back, just issue an "svn switch REPO/tags/myproject/deployed-<date of previous deployment>" and you're back to how you were. Hope this simple process helps - read the SVN book to get a better understanding of the terms I've used. Col. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
