Ok, As you directed the response to me....
1) I am not worried about what you think, the reason being is that I have clearly stated that on a few occasions everyone is different. 2) Even when I did Coldfusion development full time, I had one client that asked us to quote a job. This job resulted in a SDLC that was around 2-3 weeks. Within that time frame I completed around 20 tasks the client wanted enhanced. In this example, I mentioned it earlier, I can't do an automation in that case either. Why because the entire job consisted of only 12 things that the client wanted to go live with. It is a huge Reservation System, and there is no way I can automate these changes to production. Some of the files contained multiple tasks. So the only way to do this was to eyeball the changes with a file sync program. That would allow me to copy one line changes in the file. Granted that this case is an extreme case, but after 20 years I am yet to come across a job where I could do a complete automated change to production. The reality is it never happens in my world anymore. The point I am making is that sure, you can start out with this method, but in the long run you will be forced or have to change eventually to accommodate this. Now how the hell can extra SVN information sitting on a server help the running of an application on a server? The only reason this would work as you described if you are guilty of synching from development to production using SVN to do this. I am fully against that procedure, as stated if the file is not needed it clutters the project up. And at some point your going to come along and ask yourself why!! As for merging, committing... Anyone who has worked within a team will know that there is simple guidelines to work with. I mean in the Java world, we had a guy who worked for us and he was 100% convinced that the trunk had to be 100% stable. With all these build scripts, and tests to make a build a small change could actually take 10 hours to build with. By the time I had eyeballed the change and made it live I had completed the task within 5 mins, the point is that you may believe you are doing the right thing and you might well be. But going back to what I stated. There is no way to automatically migrate a file, with 20 changes and only 2 of them are to go to production. This has to be done manually. A computer can't decided what it takes a human to decide. Well at least not yet anyway. The automation process is not going to know what parts of the file should or should not be uploaded. And in the example I gave, the process is to branch the changes when going to QA / UAT but if the client rejects some of those changes your in limbo for a bit. If you think you can achieve what I have been trying to do for the last 10+ years, then I would love to hear how you overcome that part of the automation process. In my research manual eyeball works best, in more cases than automation. Argue about it till you are blue in the face, but after your 10th project you may see things differently. I certianly did 10 years ago when things where pointed out to me. We do try to automate as much as possible, the reason is simple the less work you have to do then it has to be good. But when it comes to building a stable application, doing an automated build can cause more problems in the long run. Here is the challenge, I have given my example. But so far not one person has come along and stated how they actually combat th problem I have described. If you can do that, then I will point out things you may not have even considered. The development process is not about cutting code, and getting somthing to automatically publish it. Imagine a newspaper, who uses SVN to produce their paper. And as a reporter I wrote an article, and it wasn't finished. The SVN automation would not know this, and if that article was published that could break laws then what do you do? Automation does work in small cases, but like I clearly stated those small cases is around 1% of actual usage. And I laugh when I here ColdFusion developers talk about SVN and how they do this and do that, well some of us have been there before and learnt. Others just don't want to learn. 1) lets look at an Application. Along the way it is very easy for images to get left behind. And instead of removing these images they end up remaining there, the image does no harm. But someone is going to wonder why it was ever left there in the first place. So rule of thumb, if it is not needed remove it. After all you have it in SVN right? 2) I guess you wouldn't hear about them then.... it is human nature to curse the previous developer of such jobs, you might not mean anything by it. But you do it because it creates extra work for you, my point there was that if you take the attitude that she'll be right, it is 99% of the time not. A lot of people don't take into consideration support and maintenace in their work, and when it comes to removing code or even files that do not belong to the application tells me that you are lazy. Harsh yes, and I have been guilty of that in the past, but it highlighted the fact that in 10 months or maybe more I am going to have to come back to this application and support it. Then I have to rack my brain because I need to know why I left a said file there, then spend 2 hours looking for where it gets referenced to find I just wasted my time. Looking for something that I shouldn't have had too. 3) you will be shot if you do... See previous comment, I may like I said curse you because of your bad practices. But thats human nature. Like I said, I do see a reason for using automated SVN scripts. Just not when deploying changes, there is a 1% chance that you don't need to eyeball the changes. Now lets talk about some of the more popular frameworks like coldbox, I have a config file that if I do make a change to it. I do not want the entire change to go live, because there is certain information in that config file that SHOULD never be seen by anyone outside the company, as it is development information and sensative. Like I said, I can give you many examples where it will not work. Now how about giving me one that I can pick holes in? And let me show you the error in your thinking. Now there is also one other reason for no .svn files in production, and I will see if anyone lese can guess the reason. And I can tell you now it is a very serious reason why I would not use it, and it also hilights what I have been trying to say. But I have refused to mention it because I want to see if anyone is actuall smart enough to know what I refer too first. If you know how SVN works then the answer to that will be very easy for you. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -----Original Message----- From: Dominic Watson [mailto:[EMAIL PROTECTED] Sent: Saturday, 16 August 2008 7:32 PM To: CF-Talk Subject: Re: SVN in Production Andrew, your initial point (that you made redundantly clear by way of caps and repetition) was to never use subversion to move code to production. You then make your detailed case that demonstrates your reasons not to. I agree, in your situation you would not do so. But I fail to see how you can be blind to the fact that not everyone will be in the same, quite horrid by the sound of it (different code per server...), situation. Your arguments for never using SVN in production appear to boil down to: 1. If it is not needed to have the Application run then it should not be there 2. Think of the poor blighters who may inherit your app and are confused by extra data In a situation where using SVN to deploy to production made deployment a great deal easier, faster and more reliable, you could argue that it is helping the application to run (perhaps several hours or days before it would else have been). Future developers will only be confused if the processes aren't documented or they don't read the documentation thats there. I am currently working in an environment where we do merge and merge and merge, etc and we do NOT use SVN to deploy to production; probably rightly so. But I have also been in much simpler environments where using SVN for deployment has made life so much easier and given confidence in the version of the live application. I am 100% confident that using it to go to production in those scenarios is NOT going to turn around and bite me some day. Neither of the above arguments suggest otherwise. I'm sure people interested in this topic would appreciate it if you could add to those points concisely, points that are not case specific. ie. Reasons never to use SVN in production: 1. If it is not needed to have the Application run then it should not be there 2. Think of the poor blighters who may inherit your app and are confused by extra data 3. You will be shot if you do... etc Regards, Dominic ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http://ad.doubleclick.net/clk;203748912;27390454;j Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:311096 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
