Hi AJ, You don't need to wait for signoff of all 5 bugs if you need. It comes to how severe they are based on your bug tracking. Obviously your goal is to ship as big free software as possible but there is obviously going to be known issues and undocumented features. :-). It also depends on what software development cycle you want to run with.
With your SVN, imagine you have 1 project - Project1 which has the usual branches, tags and trunk (I have never ever had to use branches - had no need). Assume that test, dev and production are all the same code base as if they are not, it maked version control a little trickier. So, your trunk / dev code is now version 1.0.0 (major, minor, maintenance) but it's never labelled as such in SVN - you just know that is the build you are working *to*. You finish a set of features etc and want to release to test. Now, at this point you tag the trunk as 1.0.0. It is this tag which is released to test and your trunk now becomes 1.0.1 (or whatever release point you deem). Again, this is not labelled as such it's what you are working to. If you get 5 bugs in build 1.0.0 in test then you fix them in 1.0.1. If you only want to fix 3 then release again then you follow the same above - tag trunk as 1.0.1 and release to test. Your trunk then becomes 1.0.2 and so on and so forth. At any one point you will know what release is on what system and you know your trunk will always be in line + current development. "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 08:01:35 2007 Subject: Re: deploying changes from subversion Hi Neil, I don't have any process at the moment :-( Trying to get my head around it all. The bit that is getting me is that the test server will never be 100% good to go. If there are 5 bug fixes going on at one time, only 2 of them may get signed off. I don't really wont to have to get to a point of waiting for all 5 bugs fixes to be signed off before any get put into production. On 5/15/07, Robertson-Ravo, Neil (RX) <[EMAIL PROTECTED]> wrote: > > 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. > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion?sdid=RVJW Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:278134 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
