Re: +AFs-OT+AF0- Working with version control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux