At time of release to test do you not tag that build, let's say 1.0.0? Your current dev trunk is then 1.0.1 (or whatever release - key is, it is not 1.0.0). If it passes all tests then that build is your prod release code. If it fails, you build again etc. Your trunk really shouldn't be the same as test except at the point of release.
"This e-mail is from Reed Exhibitions (Gateway House, 28 The Quadrant, Richmond, Surrey, TW9 1DN, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions." Visit our website at http://www.reedexpo.com -----Original Message----- From: AJ Mercer To: CF-Talk Sent: Tue May 15 07:46:31 2007 Subject: Re: deploying changes from subversion I mean deploy. So, some how, I go from my dev box, to the test server then finally to the production server. Other developers will also deploy to the test server. As I understand it, we wont want to commit anything to the trunk until it has been signed off in test. So in that case, if trunk is always stable, we can just update the production server from the trunk. This makes that side very simple. And that being the most important part - that is a good thing :-) And I guess at that same time the trunk can be tagged - eg /tags/prod-20070515 Now I am just left with the bit in between all the dev servers and the test server. Branching seems to me the way to go for major bug fixes and new features. Ensuring an mods to the truck get merged into the branches then updated into the dev machine(s) Then, to my thinking, once the bug has been signed off in test, I should be able to merge it into the trunk. Hmmm, time to do some testing and see what happens... On 5/15/07, Andrew Scott <[EMAIL PROTECTED]> wrote: > > Deploy? If you mean deploy to production, thats always trunk. > > Or do you mean deploy from your code to the repository, that's commit. > > > > On 5/15/07, AJ Mercer < [EMAIL PROTECTED]> wrote: > > > > OK, irrespective of whether the trunk or branches are used > > how do you selectively chose what you want to deploy? > > > > If I have 5 bug fixes on the go bug001 - bug005, > > and bug004 is signed off > > how would I use subversion to know which files need to be updated on > > production (without any of the work on bugs 1,2,3,5 going over)? > > > > On 5/15/07, Andrew Scott < [EMAIL PROTECTED]> wrote: > > > > > > AJ, > > > > > > Welcome to the world of many ways to skin a cat. > > > > > > We do it the same way I outlined a few times now, but others have > > diffeent > > > ways to do it. > > > > > > When working on something that is either new or a bug, the code is > > looked > > > at > > > and fixed now until it is fixed, tested with unit tests and the > > > development > > > tested we do not commit it back to SVN. > > > > > > Thats our procedure, but as I said earlier, we also sync the changes > to > > > make > > > sure we don't need to merge any new code, and then when its tested, > > merged > > > on our code with the repository we then commit it. > > > > > > Thats our method, and others have many other ways of doing it. > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Deploy Web Applications Quickly across the enterprise with ColdFusion MX7 & Flex 2 Free Trial http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJU Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:278129 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
