I believe it was Tom or Dave(could have been someone else) that stated that the files in the .svn directories were a clean copy of the files that you can use to diff(or more precisely so that svn can diff) against the actual files so you don't have to download the files from the repository immediately. I think you are guilty of making an incorrect assumption.
This has nothing to do with what process is used to get the code from development to production. I would say you are completely wrong in your assessment that it is indicative of being guilty of going directly from dev to production. It just shows that you are using svn to promote your files. It could be right from dev, but there can also be several servers that are used for testing in-between. Also, you should be worried about what others here think. If you stay steadfast in your way of doing things and ignore and don't evaluate what others are saying, you are not growing professionally. I don't think anyone here, even Ben and Ray and others, would say that they have nothing to learn from others...even from newbies. One of the things that I love about this field is that it is very dynamic and does change frequently and that we do have to learn new ideas and new ways of doing things on a regular basis. It keeps it fresh. A mind is like a parachute...it only functions when it is open ;-) Eric /*-----Original Message----- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Saturday, August 16, 2008 5:35 AM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*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:311216 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
