Re: SVN in Production
Took me to literal.. too literally ~| 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:311247 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew, A statement like this means you are not very good at your job. Brian's quite good at his job. I work with him. its a manual process to update and merge changes. Manual within the development branch - there shouldn't be any outstanding conflicts in anything tagged for QA, staging, or production. Brian, if you have been developing and using SVN heavily and making minor changes to websites as explained there is no way in hell I would employ you if you told me what you said below. I'm late showing up here - are you arguing that eyeballing a diff in a desktop tool (Beyond Compare?) is a superior deployment method to the near-industry-standard process of tagging, using Ant to build a production tag then deploy? You'd rather introduce a manual process that can't be auditing, doesn't produce verifiable results, and can be re-run? -Joe ~| 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:311250 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
You'd rather introduce a manual process that can't be auditing, doesn't produce verifiable results, and can be re-run? Perhaps he's a contractor. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| 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:311266 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Sat, Aug 16, 2008 at 8:18 AM, Dominic Watson [EMAIL PROTECTED] wrote: 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. You're right, if you have 20 changes to a file and you only want to push 2 up then you would not want to be using SVN. That does not make a point for never using SVN in production. That makes a point for never using SVN in production the kind of projects you work with which I assume are constantly evolving applications. Again, I am currently working with such an application and we deploy such changes manually using Beyond Compare and changing line by line where neccessary. Not all application development is like that. Some are far more straight forward and are updated less frequently and those situations simply don't arise. Choosing what parts of the code go into a deployment is always done manually to some degree. The difference is that people who actually know how to use Subversion will perform a merge between two tagged file sets and then tag the merged version, and deploy the merged tagset to production. And this is only a manual process in that you must specify the start and end tag sets to merge. It is a 30 second process. If you go buy any book on the topic this is what they will describe. Before you take the advice of anyone on this list, I would urge you to look at the documentation and books written by subject matter experts. This is a good start: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonpatterns.html#svn.branchmerge.commonpatterns.release 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 etc Again, I agree with you on redundant files being bad for both future developers and even the current ones. I am constantly removing redundant files and commented out code that is no longer needed and I commit those deletes to the repository. I *always* consider future developers. The extra files that SVN will be adding to the deployed application are all in hidden folders and all called .svn; a simple and prominent entry in the application documentation would be all that is needed to avoid any confusion about those files. Other than those files, I have found that SVN actually promotes the removing of redundant files. The common way to do this is to perform an Export from SVN. That results in deployed source that has no .svn files. This is the whole reason that command exists. The argument that one should not use SVN to deploy code because of the extra files is meaningless because one can deploy code without any SVN-related files with no effort at all. 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. This is the kind of comment that has kept this topic going far longer than it needs to have done. This list is about helping people with their questions and the OP put their question intelligently and deserves a respectful answer. This is not the kind of How do I set a variable question that deserves a RTFM response. I put my question to you personally because it was your personal statement that I wanted clearer information on. I am perfectly willing to accept that deploying with SVN might *always* be a bad idea and I, and I'm sure all the people who have read through the reams of this topic, would appreciate this information. Dominic, any argument having to do with .svn files being present on the production server is completely meaningless because using an SVN export is the estabilished way to do this. The books I mentioned earlier will show this in complete detail but it is extremely simple to do. The bottom line is that whatever anyone else says (or how loudly or with how many swears they say it with), deploying code with SVN is not only perfectly acceptable but it is the recommended way to deploy code. Once you have a look through the books and documentation on the subject you'll see that this is the case. Since I'm sure this will probably trigger a screeching, obscenity-laced reply from our resident know-it-all, I'll be pressing ignore on this conversation now. Hopefully the docs and books will help clear up some of the confusion. Regards, Brian ~| 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:
RE: SVN in Production
Coming in a little late here... Drive space is not expensive. You can get production quality drives for less than $500 (us) for a 1\2 a terabyte. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 3:21 AM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*SVN SHOULD NEVER BE USED IN PRODUCTION... /* /*SVN is used to have a revision control system, so that you could roll back /*to a previous version or whatever you need to do. /* /*When it comes to production, why the hell would you install 99% of extra /*space taking codes and indexes to a production server? Over a period of /*time, your code might be 1meg in size, but after a year the SVN indexes /*could result in 2gig and more of space that is no longer needed. But then /*if /*one read the docs to these tools, one would not use SVN in production. /* /*SVN can be expensive when it comes to hard drive space, and one should /*never /*and I will repeat this again. /* /*NEVER USE SVN in production. /* /*Use a program like beyond compare to syn file changes or something, but /*NEVER USE SVN in production. /* /*I am shocked to find people don't research their tools enough. /* /*So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn /*fool, and should be shot on sight. /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: Kym Kovan [mailto:[EMAIL PROTECTED] /*Sent: Monday, 11 August 2008 11:07 AM /*To: CF-Talk /*Subject: SVN in Production /* /*Hello, /* /*Looking at some of the responses in the recent thread on SVN v ftp I get /*an impression that some folk are using SVN clients on Production boxes. /*What are people's thoughts on this? Is it a security risk, is it /*dangerous in some other way, or is it a bad thing because of all of /*those extra files that cause havoc with backups? /* /*-- /* /*Yours, /* /*Kym Kovan /*mbcomms /* /* /* /* /* /* ~| 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:311198 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
I think I agree with your assessment Tom. On that, do you know of any good deployment systems that use SVN to go from dev to test to prod? Prefereably something web based? Eric /*-Original Message- /*From: Tom Chiverton [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 4:46 AM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*On Monday 11 Aug 2008, Andrew Scott wrote: /* SVN SHOULD NEVER BE USED IN PRODUCTION... /* /*I assume you mean 'to deploy code to a production box' ? /*Because as a production RCS it's well known for being utterly solid. /* /* When it comes to production, why the hell would you install 99% of extra /* space taking codes and indexes to a production server? Over a period of /* time, your code might be 1meg in size, but after a year the SVN indexes /* could result in 2gig and more of space that is no longer needed. /* /*SVN checkouts only contain one extra copy of each file (in side the .svn /*directory). This is unlikely to be an order of magnitude greater than /*the 'actual' file as you suggest. /* /* But then /* if one read the docs to these tools, one would not use SVN in /*production. /* /*I think 'svn help export' is fairly clear in not saying one way or the /*other. /* /* SVN can be expensive when it comes to hard drive space, /* /*Hard drive space is *very* cheap, really. /*A lot of people are using virtual servers anyway, so more hard drive space /*is /*free*. /* /* Use a program like beyond compare to syn file changes or something, but /* NEVER USE SVN in production. /* /*Why wouldn't I use 'svn diff' or a suitable GUI ? /* /* So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a /*damn /* fool, and should be shot on sight. /* /*I think you must have had a bad experience at some point... /* /*-- /*Tom Chiverton /* /* /* /*This email is sent for and on behalf of Halliwells LLP. /* /*Halliwells LLP is a limited liability partnership registered in England /*and Wales under registered number OC307980 whose registered office address /*is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 /*3EB. A list of members is available for inspection at the registered /*office. Any reference to a partner in relation to Halliwells LLP means a /*member of Halliwells LLP. Regulated by The Solicitors Regulation /*Authority. /* /*CONFIDENTIALITY /* /*This email is intended only for the use of the addressee named above and /*may be confidential or legally privileged. If you are not the addressee /*you must not read it and must not use any information contained in nor /*copy it nor inform any person other than Halliwells LLP or the addressee /*of its existence or contents. If you have received this email in error /*please delete it and notify Halliwells LLP IT Department on 0870 365 2500. /* /*For more information about Halliwells LLP visit www.halliwells.com. /* /* ~| 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:311199 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
That is why production should be a checked out version of either trunk or a release branch. It allows for a quick rollback from the repository. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 4:46 AM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*What /*Do you mean by repo - server and server - repo? /* /*The latter should never be an issue, or even considered. Anyone who makes /*changes to production and not in a development environment shouod be hung /*out to dry or better still beaten with a stick until you realise that /*development is what it means. /* /*You develop, you fix and you test. And when you and your client are happy /*then it is moved from dev / qa to production. /* /*If you make changes to production and the stick back into the SVN, you /*seriously need to rethink your procedures. /* /*NEVER USE production WITH YOUR SVN REPOSTIORY. /* /*Development at all costs, needs to do one of two things. Be the latest, be /*tested and if required then deployed to live. NEVER the other way around. /*If /*youu are intent on following the wrong rules of development then you are /*doomed to be the one that is developing with the wrong frame of mind. /* /*Once you have deployed to a production server, it should never have any /*ties /*with the repository in any way shape or form. If you are one of those that /*think this is ok, then you will need to adopt new procedures quickly. /*Before /*you adopt bad and I mean VERY BAD ideas. /* /*SVN was created for one purpose and one purpse only, that was to provide a /*revision control system for you to roll back, and manage different /*versions /*of your code. If you chose to ignore that then you are creating more work /*and more headaches to your development team or yourself if you are a lone /*developer. /* /*The thing to remember is what someone else might think about your /*procedures, and I do not care what anyone else has to say about using SVN /*when it comes to production code. If you can't be bothered to read the /*docs /*on what SVN actually is, or how to best utilise it then you should NOT be /*using it. /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: Jochem van Dieten [mailto:[EMAIL PROTECTED] /*Sent: Monday, 11 August 2008 7:29 PM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*Kym Kovan wrote: /* Looking at some of the responses in the recent thread on SVN v ftp I get /* an impression that some folk are using SVN clients on Production boxes. /* What are people's thoughts on this? Is it a security risk, is it /* dangerous in some other way, or is it a bad thing because of all of /* those extra files that cause havoc with backups? /* /*You only get the extra files if you do a checkout to create a working /*copy, not if you do an export. Since in our workflow web content has a /*strict one way (dev - QA - prod) publishing cycle that works fine with /*exports. /* /*For server configuration files (basically all of /etc/) I need working /*copies because they go both ways, from repo to server and from server to /*repo. But on the other hand, I don't want any extra files in my /etc/ /*because that would seriously mess up anything that works with config /*directories instead of config files. So there I typically have a working /*copy in /tmp/ that mirrors /etc/ and use that if I have to push files to /*the repository. That does require discipline though to keep /etc/ and /*/tmp/etc/ in sync. /* /*Jochem /* /* /* /* ~| 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:311200 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
I don't remember seeing that. Not every company has a proper SDLC. We don't, much to my chagrin. I would love to have consistent user testing, but as a smaller company, we don't have the resources to do so. Heck...I have a project awaiting testing that has been sitting there for the past 3 weeks. What we have set up is I develop locally...then commit to a development branch and update the dev server so I can test in a production environment. Once that is good, I merge the files to the test branch (from the development branch) and update the test server so (ideally), we get some UAT. Once that is ok'd, I then merge it to the trunk and update production. That sounds like a similar process to what other describe and it is similar to a process that was posted here in this thread (difference is they used release branches...which are unnecessary for my purposes as we are maintaining a single web site) Multiple benches could be used for your example and then you merge the changes (even going as far as using svn diff with the branch you are merging to, to cherry pick changes. Then you are only deploying the changes you need. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 6:52 AM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*Kym, /* /*I was not responding to you directly, if I did not answer your question /*then /*let me ask you this. /* /*If you are tight for HD space, and not everyone is. But what good would it /*be too actually have .svn files on your production server? If it doesn't /*need to be required to run, then it doesn't need to be there. /* /*From a security point of view, unless it is behind a VPN that is totally /*secure you have your code base open to the whole world when and if it is /*hacked. Small chance that someone would work out that your production /*server /*is connected to your SVN server. /* /*If you are like ME and most others, your company or business is behind a /*firewall. This means a number of things, and if hacked then the code could /*include your SVN details to connect to your SVN server. Unlikely, but why /*take the chance? /* /*Do you really want me to go further? /* /*SVN might be used by some people in production, and these people are in /*need /*of a good damn slapping and told to give it up... /* /*And over time, all changes made to production and stored back into .svn /*directories end up increasing your HD space so over a year it will grwo /*depending on how often youu make changes directly to production and DO NOT /*FOLLOW a full SDLC. /* /*But I guess that anyone who does use an approach of production-svn, do /*not /*know what an SDLC is all about or how to protect themselves. In one /*application, I had made changes to the application that DOES and WILL /*effect /*LIVE data. So until the client is happy it gores through the stages of dev /*- QA - production and then at least, once made live if the changes made /*to /*production effect live application data the ownus falls onto the developer /*and the client. /* /*If it is the developer, then they migrated changes that should never have /*been made live. If it is the client then they have no excuse, because it /*went through a QA phase for the client to approve from a UAT point of /*view... And I will make the assumption that if you follow an SDLC you /*would /*also be using the UAT, before a client signs of on the changes. /* /*Oh wait, some comments here have made a reference to the fact that changes /*are not signed off on. Which means you could have 20 changes waiting for /*approval, how do you migrate these changes? /* /*You certainly would not export the entire repository now would you? /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* ~| 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:311202 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
If there are conflicts in your code when you commit, svn lets you know and allows you to run a diff (which also tells you who made the change if you need to collaborate with them to make sure you are not deleting good code. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 6:59 AM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*Actually that's not entirely true /* /*And this is one reason I refuse to use subclipse /* /*What you don't see is the processes that can and do run in the background, /*if you run eclipse you can switch on to show hidden processes. Doing this /*will show you that svn can be contacted and updated without your /*knowledge, /*how else do you know if there are changes to the code... /* /*You think it guesses? /* /*Although having said that, you can even switch this caching off for svn as /*well. Well in subversive you can, the problem is that when you do sync / /*merge changes before doing an update can take sooo much longer :-( /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: Tom Chiverton [mailto:[EMAIL PROTECTED] /*Sent: Monday, 11 August 2008 9:38 PM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*On Monday 11 Aug 2008, Kym Kovan wrote: /* intermediate server to import it into SVN and then checked it out to the /* test server and then ran some file sync tools to the Production boxes /* which are FTP distance away. It took over an hour to say no /*difference! /* /*That's one of the great steps SVN decided to take over CVS - keeping a /*clean /* /*local copy so 'diff' is fast and doesn't need access to the network. /* /*-- /*Tom Chiverton /* /* /* /*This email is sent for and on behalf of Halliwells LLP. /* /*Halliwells LLP is a limited liability partnership registered in England /*and /*Wales under registered number OC307980 whose registered office address is /*at /*Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A /*list of members is available for inspection at the registered office. Any /*reference to a partner in relation to Halliwells LLP means a member of /*Halliwells LLP. Regulated by The Solicitors Regulation Authority. /* /*CONFIDENTIALITY /* /*This email is intended only for the use of the addressee named above and /*may /*be confidential or legally privileged. If you are not the addressee you /*must not read it and must not use any information contained in nor copy it /*nor inform any person other than Halliwells LLP or the addressee of its /*existence or contents. If you have received this email in error please /*delete it and notify Halliwells LLP IT Department on 0870 365 2500. /* /*For more information about Halliwells LLP visit www.halliwells.com. /* /* /* /* ~| 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:311203 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
By committing and updating the file you changed. You don't have to commit/update the entire site. /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 7:09 AM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*And how are you going to migrate small changes in a midst of other /*changes? /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: Kym Kovan [mailto:[EMAIL PROTECTED] /*Sent: Monday, 11 August 2008 10:04 PM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*Tom Chiverton wrote: /* On Monday 11 Aug 2008, Kym Kovan wrote: /* intermediate server to import it into SVN and then checked it out to /*the /* test server and then ran some file sync tools to the Production boxes /* which are FTP distance away. It took over an hour to say no /*difference! /* /* That's one of the great steps SVN decided to take over CVS - keeping a /*clean /* local copy so 'diff' is fast and doesn't need access to the network. /* /*Yes, and that lends me to the thought that the best scenario for our /*particular problem would be to have an exported copy on each production /*box (yes, they are clustered) and use a standard diff tool from there to /*flip the changes over to the actual production site. It would not be too /*hard to set off the flip to happen on all servers at the same time to /*avoid mayhem. I should have mentioned in my previous explanation that /*this site is on dedicated boxes so disk space is not an issue. /* /*Anyone see a difficulty in doing that? /* /* /* /*-- /* /*Yours, /* /*Kym Kovan /*mbcomms /* /* /* /* /* ~| 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:311204 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
If you have a private beta, then that should be a separate application...I would assume that this beta is a different code set (physically speaking). If you have to make a change to multiple code sets you can merge it. You can also automate that via scripting. If you have something that is regularly merged to multiple code sets, then write script you can run where you can specify multiple source and destination file. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 6:57 PM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*Kym, /* /*Think of an Application has being something that more than one client /*could /*have. Then think about their requirements, and how it might differ to /*another client. /* /*It is no secret that we have released our new flagship product into /*private /*beta, this product will have so many different carnations to the /*application. /* /*Anyway the point is that I might have one section, that is in 2 versions /*that need to be fixed. I switch to the first version and fix it, follow /*the /*SDLC and when it is approved it is then migrated to production. In the /*meantime we realise that another client uses this in their instance, so we /*now need to merge the changes to their version. /* /*This is an extreme case, but it highlights the switching to branches, tags /*or any version you need too. /* /*As for tickets, I just fixed 3 bugs. And another developer just also added /*a /*new module. But the module is not ready for production. So that means we /*need to sync the changes that I made and leave the other developers away /*from production. Which means we now have to eyeball these changes to /*production. /* /*Or in a more common example, as most Coldfusion developers are single team /*developers. The client has requested a complete change to their system, /*when /*finished he approved 60% of the changes and wants them to go live right /*now. /*I can't just export now can I? So again I have to either tell the client /*no, /*which will upset them.. Or make an eyeball sync to production to make the /*client happy, while they get me to finalise the remaining 40% of the /*changes. /* /*Under these circumstances, you can't just do an export from SVN. /* /* /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: Kym Kovan [mailto:[EMAIL PROTECTED] /*Sent: Monday, 11 August 2008 11:05 PM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*Andrew Scott wrote: /* And how are you going to migrate small changes in a midst of other /*changes? /* /* /*Good response Andrew to my question, just what I wanted. Unfortunately /*your response is top-replied with your signature as well, with its /*correct --, so in Thunderbird my question below that is lost. /* /*But this brings up a point I noticed in your earlier replies, you talked /*of 20 tickets open and sending one ticket to production. You also talked /*in another reply about the work in maintaining multiple branches for /*them all but surely this is what keeping tight control over your code is /*all about? A change is A branch, merge it when it is right and there /*is no problem surely? You talked about one application but many clients /*running off it, with variations for all of them. If changing one /*client's code affects others then surely the site architecture is wrong, /*it isn't one application is it many similar ones. I feel motivated to /*shout at you like you shout at everyone else about how bad that is, but /*I won't /* /* /*-- /* /*Yours, /* /*Kym Kovan /*mbcomms /* /* /* /* /* ~| 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:311206 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
In an instance like that you can create a separate branch that doesn't contain the changes the other developers made, sometimes called a feature branch. All that would remain is to merge those changes into the other branches to update them. Once that is deployed and all is well, you delete that branch. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 7:58 PM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*Sorry, /* /*Maybe I should have stated: /* /*Not even SVN can automatically decide what changes to make live and what /*not to make live, between developer changes /* /*As stated, if I have 2 changes one has to go live and the other is not /*ready. Another developer has made a change, but this change is also not /*ready to go into production. /* /*Can SVN decide to automatically decide what has to go live and what does /*not? /* /* /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: denstar [mailto:[EMAIL PROTECTED] /*Sent: Tuesday, 12 August 2008 10:23 AM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*On Mon, Aug 11, 2008 at 6:09 PM, Andrew Scott wrote: /* Brian... /* /* A statement like this means you are not very good at your job. /* /*Hey, we're all learning and whatnot, Andrew, cut the man some slack! :-) /* /* There is no way to automatically merge changes, I mean even SVN can't do /* that between developers and its a manual process to update and merge /* changes. /* /*SVN really DOES automatically merge changes. That's one of the cool /*things about it (The Book[http://svnbook.red-bean.com/], is awesome!) /* /* Brian, if you have been developing and using SVN heavily and making /*minor /* changes to websites as explained there is no way in hell I would employ /*you /* if you told me what you said below. /* /*I think you are thinking in the box, as in, your way is the right /*way, when really, there are many ways. /* /*You actually don't seem to be taking advantage of some of the more /*rock'n aspects of SVN. /* /* As much as I am one who looks to reduce work load, file sync is and will /* always be a manual process when it comes to migrating small changes. /* /*Oy! I think, as Dave sorta said, it's those little incremental /*changes that are exactly the type of thing you'd want captured in some /*type of history, if you will. /* /*I *really* *really* love having our config files in SVN-- we can stand /*up a new server much much faster-- I do have a comment on /etc files, /*and how we do it, but I'll address that some[time|where] else. /* /*Well... anyways, guess that's it. /* /*-- /*DeN 3 Subclipse /* /* /* /* ~| 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:311208 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Test to production or test to qa to production...same process. If you have multiple developers, you can have multiple branches...one for each developer or use a separate branch for each project. They then merge their changes and deal with conflict resolution as need be. SVN will automatically merge changes as long as they don't conflict. If there is a conflict, it will tell you and give you the opportunity to either resolve the conflict via svn diff or ignore it and just copy over your code. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 8:05 PM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*For FUCK sake. /* /*I never said anything about merging between SVN repositories. /* /*I fucking said merging code from dev - production, which has nothing to /*do /*with SVN what so ever that is my damn point. /* /*You bring automation into this, and I am fairly sure that I have been /*talking about using SVN in production. If I am as a developer, have made /*it /*very clear that not all my changes or even yours could end up in /*production. /*So how do you handle that? /* /*It has nothing to do with automation of any shape or form. /* /*I have been talking about deployment the entire time, WTF do you think I /*mean when I talk about merging fixes/changes from QA - PRODUCTION /* /*Did you think I had 2 repositories in SVN called QA and Production? /* /*Give me a break. /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: Brian Kotek [mailto:[EMAIL PROTECTED] /*Sent: Tuesday, 12 August 2008 10:34 AM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*I never said you would automatically handle merge changes. If you are /*merging, then you do that in the repository and tag the merged file set /*before you perform the deployment. That has nothing to do with deployment. /*You only deploy once the code has been properly merged, tagged, and /*tested. /* /*To anyone else interested in this topic, I would recommend that you look /*around for yourself by Googling ant deployment or svn deployment and /*look through the hundreds of thousands of results from a very wide range /*of /*authoritative sources. You'll quickly see that a great many people /*successfully leverage Subversion when deploying code. /* /* /*On Mon, Aug 11, 2008 at 8:09 PM, Andrew Scott /*[EMAIL PROTECTED]wrote: /* /* Brian... /* /* A statement like this means you are not very good at your job. /* /* There is no way to automatically merge changes, I mean even SVN can't do /* that between developers and its a manual process to update and merge /* changes. /* /* Brian, if you have been developing and using SVN heavily and making /*minor /* changes to websites as explained there is no way in hell I would employ /*you /* if you told me what you said below. /* /* As much as I am one who looks to reduce work load, file sync is and will /* always be a manual process when it comes to migrating small changes. /* /* Brian, you really should read your message again and seriously think /*about /* what you said. /* /* /* /* -- /* Senior Coldfusion Developer /* Aegeon Pty. Ltd. /* www.aegeon.com.au /* Phone: +613 9015 8628 /* Mobile: 0404 998 273 /* /* /* /* /* -Original Message- /* From: Brian Kotek [mailto:[EMAIL PROTECTED] /* Sent: Tuesday, 12 August 2008 12:01 AM /* To: CF-Talk /* Subject: Re: SVN in Production /* /* I disagree completely. There's absolutely nothing wrong with using SVN /*in /* production for deployment. /* /* Beyond Compare? It's a great program...but using it to deploy code? The /* idea /* makes me shudder. In fact, doing anything manual related to code /*deployment /* makes me shudder. /* /* There are easy ways around the issue you bring up about size: it's /*called /* an /* SVN Export. It's meant to do EXACTLY what you're talking about: create a /* copy of the source code with no SVN-related files. /* /* All of this can (and should) be automated with ANT. That means at the /*click /* of my mouse I can execute the entire deployment process in exactly the /*same /* way every single time. That might mean: /* /* - Zip the current code, timestamp it, and copy it to a back folder for /* easy retrieval. /* - Delete the current code /* - Copy a site maintenance file into the site folder /* - Pull latest from SVN /* - Perform export to site folder /* - Run a reinit HTTP request to reload the application /* - Send an email to notify stakeholders of success /* /* You can also have it run unit tests and only deploy if all tests pass. /* /* The bottom line is that using SVN and ANT to help you deploy code is /* EXACTLY /* what these tools were meant to do. If I have to do anything more than /*click /* my mouse once to execute an entire deployment process, I'm doing /*something /* wrong. /* /* /* On Mon, Aug 11, 2008 at 4:20 AM, Andrew
RE: SVN in Production
As far as merging, you are only merging your code...not the other developers. The automation handles getting the code from one repository to another. If your code has multiple folks running it, then you should have separate branches for each developer so you can test without effecting the work of others. Once that is ok'd for production, you merge it with production. When the other do the same, if there is any conflict between the production code and their code, then they will have to deal with the conflict before they push it live. That is no different that any other system of promoting code from server to server. SVN adds a level of safety in that it warns you if the code has conflicts and save the time of going through a diff tool when it isn't necessary. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Monday, August 11, 2008 8:28 PM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*You have my curiosity now... /* /*Explain to me how, SVN automation is going to know that I have 4 changes /*and /*only 3 of these are going to need to go to production. /* /*Not that it is going to change for me, I need to log into a VPN and then /*map /*to the harddrive anyway. So this approach WILL not work for me, in our /*current line of clients. /* /*Like I said I am curious, I have one file and that file has the entire 4 /*changes. But I need to sit down and manually make the 3 changes to live. /*How /*does SVN automation decided this? /* /*I am aware of all the hooks etc., because we use it with our ticketing /*system. So that the tickets are automatically update, when SVN is updated. /*But to manage change management, I am very curious how you have achieved /*what it takes a human brain to decide. /* /* /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: denstar [mailto:[EMAIL PROTECTED] /*Sent: Tuesday, 12 August 2008 11:03 AM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*On Mon, Aug 11, 2008 at 6:58 PM, Andrew Scott wrote: /*. /* /* As stated, if I have 2 changes one has to go live and the other is not /* ready. Another developer has made a change, but this change is also not /* ready to go into production. /* /* Can SVN decide to automatically decide what has to go live and what does /* not? /* /*It won't have to decide, if you've followed a pattern. /* /*Theoretically. /* /*=] /* /*-- /*Don't mean to come off as if I know something, as I know I don't know, ya /*know? /* /* /* /* ~| 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:311211 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
That tagged branch would contain the already merged files that are ready to be put up on production...so there is nothing that needs to be eyeballed at that point. Again, to avoid the complexity that you speak of, you would have separate branches for each developer so that the developer isn't committing changes to development that could affect the work of others until they have a final copy that is ready to go to qa. Once the final copy is ready, it can then be merged with the code that is on qa to be tested before going to productionsome even use a staging or second qa server as well to make sure that all the combined code is good and qa would then also have branches for each developer so their changes can be tested separately. Dev-developer--qa-developer--staging (or qa2) combined---production Obviously, if you are a single developer, the individual developer branches are unnecessary. If you add a developer to the mix, it is easy to break out new branches to accommodate. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Friday, August 15, 2008 10:56 PM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*Yes, but can it automatically eyeball the changes you need to move to /*production? /* /*No it can't, if you are in a position where you make a change and it has /*to /*go live then that would be fine. But that becomes a very small percentage /*of /*people who would use that method. /* /*But when you work with people who commit on a regular basis, and you have /*to /*merge and merge and merge and merge then commit yourself. You can see that /*it can become complex if you let it. /* /*As I stated we work in an environment, that is the norm for Enterprise /*solutions and I can tell you that moving out of SVN to production will not /*work for us with automation. /* /*And if you have ever designed and written a grails application, or even a /*coldbox application that could contain data for development and /*production, /*as well as code for the same. You can't rely on a change going to /*production, why because I might have only made a change that is needed for /*development or even testing. /* /*Everyone is different on the approach, however when it comes to automation /*as I stated it is only a small percentage that fall into that category. /* /*So we have to rely on the build script to build the version from the /*supplied information to build from the core source code, otherwise code /*and /*data that should not be there will be there or someone else's settings may /*end up into another clients production environment. Usually this gets /*branched / tagged, but not in this example as what we work on is core code /*to the framework of our Enterprise Application. /* /*That was my point in the conversation. /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: Tom Chiverton [mailto:[EMAIL PROTECTED] /*Sent: Thursday, 14 August 2008 7:13 PM /*To: CF-Talk /*Subject: Re: SVN in Production /* /*On Tuesday 12 Aug 2008, Andrew Scott wrote: /* Not even SVN can automatically decide what changes to make live and /*what /* not to make live, between developer changes /* /*I dunno, I've heard of systems which auto updated the live environment to /*the /*most recent tag which matches a patten (i.e. .../tags/live-release-N). /*The QA'ed tag is just copied to the next 'live' name, and the next /*maintenance /*job pushes the update to the live systems. /* /*-- /*Tom Chiverton /* /* /* /*This email is sent for and on behalf of Halliwells LLP. /* /*Halliwells LLP is a limited liability partnership registered in England /*and /*Wales under registered number OC307980 whose registered office address is /*at /*Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A /*list of members is available for inspection at the registered office. Any /*reference to a partner in relation to Halliwells LLP means a member of /*Halliwells LLP. Regulated by The Solicitors Regulation Authority. /* /*CONFIDENTIALITY /* /*This email is intended only for the use of the addressee named above and /*may /*be confidential or legally privileged. If you are not the addressee you /*must not read it and must not use any information contained in nor copy it /*nor inform any person other than Halliwells LLP or the addressee of its /*existence or contents. If you have received this email in error please /*delete it and notify Halliwells LLP IT Department on 0870 365 2500. /* /*For more information about Halliwells LLP visit www.halliwells.com. /* /* /* /* ~| 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
RE: SVN in Production
I don't think that is a logical argument. If I was hired into a new position and didn't know anything about svn or cvs or anything like that and I see all these .svn files...I would ask. Confusion solved. When we go into new positions, there is always going to be something new we have to learn whether that is a versioning system, coding styles, or whatever. Eric /*-Original Message- /*From: Andrew Scott [mailto:[EMAIL PROTECTED] /*Sent: Friday, August 15, 2008 11:07 PM /*To: CF-Talk /*Subject: RE: SVN in Production /* /*No I was not concerned about HD space, my view is simple. If it is not /*needed to have the Application run then it should not be there, whether /*there is plenty of space or not. /* /*Let me ask you something, if you didn't know about SVN and you picked up a /*maintenance job and came across all these extra directories that shouldn't /*be there. Are you goiong to know which file is to be used? OR if these /*extra /*dirs and files actually ever get used? /* /*The point is that you might now what they mean, and why they are there. /*Bout /*put yourself into someone else's shoes and think about the confusion it /*would cause. /* /*Granted having them there is not an issue as such, but why create further /*headaches down the track? /* /*Not everyone has the ability to use a VPN automatically, so automating a /*script to export from SVN to production is not always going to be viable /*either. For example we have a client where we have to be authorised to /*connect to the VPN connection, once we have finished with it is removed. /* /*The problem with that is that I have to find another solution to do the /*job, /*so the thing is I would prefer to use and build scripts to build the /*version /*into a war file to be deployed, or if in the case of Coldfusion standard, /*will build the application to QA as that is internal. Then when it is /*ticked /*off we can then deploy that, but it is still a small extra manual step but /*we have no choice when it comes to the VPN connection. /* /*Eitherway, svn integration will be different to everyone esle. /* /*But when it comes to deployment from SVN, never use SVN to migrate to /*production. When I first mentioned that, people quickly jumped onto the /*fact /*you can export from SVN. Sure, but you are not using SVN to migrate to /*production, as you have done an export. I thought that would have been /*obvious to most, but it appeared not. /* /* /*-- /*Senior Coldfusion Developer /*Aegeon Pty. Ltd. /*www.aegeon.com.au /*Phone: +613 9015 8628 /*Mobile: 0404 998 273 /* /* /* /* /*-Original Message- /*From: Dana Kowalski [mailto:[EMAIL PROTECTED] /*Sent: Friday, 15 August 2008 12:27 AM /*To: CF-Talk /*Subject: Re: SVN in Production /* /* This thread is kind of heavy handed. My personal opinion with anything /*like /*this is your mileage will vary. There are simply too many factors to heavy /*hand a this is the only way to do it. Everyones configurations, staff, /*resources, technical knowledge etc etc vary. You use what works, simple as /*that. /* /* Being over concerned about hard drive space is kind of crazy as well. I'm /*not really sure about the shared host portion of the posts as well. If you /*are that concerned with security, protocal, space and deployment why would /*you EVER be on a shared host thats pretty silly. /* /* /* /* ~| 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:311214 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
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
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 2008/8/16 Andrew Scott [EMAIL PROTECTED]: No I was not concerned about HD space, my view is simple. If it is not needed to have the Application run then it should not be there, whether there is plenty of space or not. Let me ask you something, if you didn't know about SVN and you picked up a maintenance job and came across all these extra directories that shouldn't be there. Are you goiong to know which file is to be used? OR if these extra dirs and files actually ever get used? The point is that you might now what they mean, and why they are there. Bout put yourself into someone else's shoes and think about the confusion it would cause. Granted having them there is not an issue as such, but why create further headaches down the track? Not everyone has the ability to use a VPN automatically, so automating a script to export from SVN to production is not always going to be viable either. For example we have a client where we have to be authorised to connect to the VPN connection, once we have finished with it is removed. The problem with that is that I have to find another solution to do the job, so the thing is I would prefer to use and build scripts to build the version into a war file to be deployed, or if in the case of Coldfusion standard, will build the application to QA as that is internal. Then when it is ticked off we can then deploy that, but it is still a small extra manual step but we have no choice when it comes to the VPN connection. Eitherway, svn integration will be different to everyone esle. But when it comes to deployment from SVN, never use SVN to migrate to production. When I first mentioned that, people quickly jumped onto the fact you can export from SVN. Sure, but you are not using SVN to migrate to production, as you have done an export. I thought that would have been obvious to most, but it appeared not. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Dana Kowalski [mailto:[EMAIL PROTECTED] Sent: Friday, 15 August 2008 12:27 AM To: CF-Talk Subject: Re: SVN in Production This thread is kind of heavy handed. My personal opinion with anything like this is your mileage will vary. There are simply too many factors to heavy hand a this is the only way to do it. Everyones configurations, staff, resources, technical knowledge etc etc vary. You use what works, simple as that. Being over concerned about hard drive space is kind of crazy as well. I'm not really sure about the shared host portion of the posts as well. If you are that concerned with security, protocal, space and deployment why would you EVER be on a shared host thats pretty silly. ~| 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
RE: SVN in Production
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
Re: SVN in Production
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. Neither me you. You have clearly stated that everyone is different but that no one should ever use SVN in production. I would like to know the concrete reasons for the latter because I am interested in the topic. 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. You're right, if you have 20 changes to a file and you only want to push 2 up then you would not want to be using SVN. That does not make a point for never using SVN in production. That makes a point for never using SVN in production the kind of projects you work with which I assume are constantly evolving applications. Again, I am currently working with such an application and we deploy such changes manually using Beyond Compare and changing line by line where neccessary. Not all application development is like that. Some are far more straight forward and are updated less frequently and those situations simply don't arise. 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 etc Again, I agree with you on redundant files being bad for both future developers and even the current ones. I am constantly removing redundant files and commented out code that is no longer needed and I commit those deletes to the repository. I *always* consider future developers. The extra files that SVN will be adding to the deployed application are all in hidden folders and all called .svn; a simple and prominent entry in the application documentation would be all that is needed to avoid any confusion about those files. Other than those files, I have found that SVN actually promotes the removing of redundant files. Now how about giving me one that I can pick holes in? The application is a small business' office management system built using Model-Glue and ColdSpring. It is a private site and downtime is possible for updates, though this has never needed to happen. Updates to the features of the application happen sometimes in small chunks and other times a whole heap of changes take place. There has never yet, and not likely ever, been a situation where development will be happening on two seperate updates that will deploy at different times and that conflict with each other. There is a single xml file that contains server specific configurations and those settings contain no sensitive data, I have no problem with having the settings of all servers in that file on each sever. SVN has been used to deploy the initial application, two rounds of updates and various bug fixes. It has made deployment of changes and fixes a breeze. Should there come a time where it is no longer practical, it will not be an issue to switch to some other deployment method. 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. This is the kind of comment that has kept this topic going far longer than it needs to have done. This list is about helping people with their questions and the OP put their question intelligently and deserves a respectful answer. This is not the kind of How do I set a variable question that deserves a RTFM response. I put my question to you personally because it was your personal statement that I wanted clearer information on. I am perfectly willing to accept that deploying with SVN might *always* be a bad idea and I, and I'm sure all the people who have read through the reams of this topic, would appreciate this information. 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:311099 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
Trust me it does I have had to close eclipse down many times, because subclipse is flakey at best. Like kill it because it would stop responding. Even those I work with in the Java world will not touch it due to its problems. And since switching I have more options, and it is faster to boot. Now that was 12 months+ so it may have changed since then or been fixed, but even killing the process running from within eclipse never worked. But then again, you maybe only have one or 2 projects at any one time. Just because you have not experienced it, I can name 20 people to you being one who has had problems with it. And it is always the same, it will stop responding when connecting to the svn server. And since Subversive had more features at the time and was faster in running, I have never looked back. Just because you didn't experience the problem doesn't mean it is not there, as a developer yourself you should damn well know that. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Thursday, 14 August 2008 7:08 PM To: CF-Talk Subject: Re: SVN in Production On Tuesday 12 Aug 2008, Andrew Scott wrote: There is a bug in Subclipse, that sees file saving take anything from an extra 2mins upto hours We use Subclipse here, and that simply does not happen. Our mileage clearly varies. -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:311076 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
Yes, but can it automatically eyeball the changes you need to move to production? No it can't, if you are in a position where you make a change and it has to go live then that would be fine. But that becomes a very small percentage of people who would use that method. But when you work with people who commit on a regular basis, and you have to merge and merge and merge and merge then commit yourself. You can see that it can become complex if you let it. As I stated we work in an environment, that is the norm for Enterprise solutions and I can tell you that moving out of SVN to production will not work for us with automation. And if you have ever designed and written a grails application, or even a coldbox application that could contain data for development and production, as well as code for the same. You can't rely on a change going to production, why because I might have only made a change that is needed for development or even testing. Everyone is different on the approach, however when it comes to automation as I stated it is only a small percentage that fall into that category. So we have to rely on the build script to build the version from the supplied information to build from the core source code, otherwise code and data that should not be there will be there or someone else's settings may end up into another clients production environment. Usually this gets branched / tagged, but not in this example as what we work on is core code to the framework of our Enterprise Application. That was my point in the conversation. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Thursday, 14 August 2008 7:13 PM To: CF-Talk Subject: Re: SVN in Production On Tuesday 12 Aug 2008, Andrew Scott wrote: Not even SVN can automatically decide what changes to make live and what not to make live, between developer changes I dunno, I've heard of systems which auto updated the live environment to the most recent tag which matches a patten (i.e. .../tags/live-release-N). The QA'ed tag is just copied to the next 'live' name, and the next maintenance job pushes the update to the live systems. -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:311077 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
No I was not concerned about HD space, my view is simple. If it is not needed to have the Application run then it should not be there, whether there is plenty of space or not. Let me ask you something, if you didn't know about SVN and you picked up a maintenance job and came across all these extra directories that shouldn't be there. Are you goiong to know which file is to be used? OR if these extra dirs and files actually ever get used? The point is that you might now what they mean, and why they are there. Bout put yourself into someone else's shoes and think about the confusion it would cause. Granted having them there is not an issue as such, but why create further headaches down the track? Not everyone has the ability to use a VPN automatically, so automating a script to export from SVN to production is not always going to be viable either. For example we have a client where we have to be authorised to connect to the VPN connection, once we have finished with it is removed. The problem with that is that I have to find another solution to do the job, so the thing is I would prefer to use and build scripts to build the version into a war file to be deployed, or if in the case of Coldfusion standard, will build the application to QA as that is internal. Then when it is ticked off we can then deploy that, but it is still a small extra manual step but we have no choice when it comes to the VPN connection. Eitherway, svn integration will be different to everyone esle. But when it comes to deployment from SVN, never use SVN to migrate to production. When I first mentioned that, people quickly jumped onto the fact you can export from SVN. Sure, but you are not using SVN to migrate to production, as you have done an export. I thought that would have been obvious to most, but it appeared not. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Dana Kowalski [mailto:[EMAIL PROTECTED] Sent: Friday, 15 August 2008 12:27 AM To: CF-Talk Subject: Re: SVN in Production This thread is kind of heavy handed. My personal opinion with anything like this is your mileage will vary. There are simply too many factors to heavy hand a this is the only way to do it. Everyones configurations, staff, resources, technical knowledge etc etc vary. You use what works, simple as that. Being over concerned about hard drive space is kind of crazy as well. I'm not really sure about the shared host portion of the posts as well. If you are that concerned with security, protocal, space and deployment why would you EVER be on a shared host thats pretty silly. ~| 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:311078 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Tuesday 12 Aug 2008, Andrew Scott wrote: There is a bug in Subclipse, that sees file saving take anything from an extra 2mins upto hours We use Subclipse here, and that simply does not happen. Our mileage clearly varies. -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310949 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Tuesday 12 Aug 2008, Andrew Scott wrote: Please don't confuse the topic Tom, and twist what I am saying. I seem to be having some difficultly with your points, so bear with me :-) My point is very simple, so let me spell it out for you again. When using export, that is not actually using SVN so it is not an issue in this conversation. I thought you of all people who has been around long enough, should have known that. I've only been using SVN for a few years, however. -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310950 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
On Tuesday 12 Aug 2008, Andrew Scott wrote: Not even SVN can automatically decide what changes to make live and what not to make live, between developer changes I dunno, I've heard of systems which auto updated the live environment to the most recent tag which matches a patten (i.e. .../tags/live-release-N). The QA'ed tag is just copied to the next 'live' name, and the next maintenance job pushes the update to the live systems. -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310951 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
This thread is kind of heavy handed. My personal opinion with anything like this is your mileage will vary. There are simply too many factors to heavy hand a this is the only way to do it. Everyones configurations, staff, resources, technical knowledge etc etc vary. You use what works, simple as that. Being over concerned about hard drive space is kind of crazy as well. I'm not really sure about the shared host portion of the posts as well. If you are that concerned with security, protocal, space and deployment why would you EVER be on a shared host thats pretty silly. ~| 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:310957 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production - back to the original question
Ant is very handy, the one thing I got to do with one of my applications was to template certain aspects of the site. Pain at times if you are not aware of it, but the point is that I used ant and the build file to package the war file up for me. The steps where get the template, grab the revision number and build number from SVN. This then replaces the file in the site, to reflect these small changes. Nothing special, but it does show how ant can be very handy, because once that happened. The ant script then encrypted the code, and produced a deployable package. The template system is nothing new, but it shows that even we in the ColdFusion arena can also make a script to modify code on the fly based on a condition. For example, we need to build for development the database location and details might be different to the production server, and those allow for us to build depending on whether we select development or production the template is then converted to the normal file and its location and has the changes requested. Certainly not the only way to do it, but it shows an example of another way most wouldn't know you could. However there are still times when automation doesn't work. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: denstar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 3:21 PM To: CF-Talk Subject: Re: SVN in Production - back to the original question With gigs of data, and it's possible, something incremental seems like a good idea. A nice bit about SVN (and some other version control systems) is the binary difference stuff, so only the changes are transmitted, not the entire file. Sweet for large data files, neh? I'm thinking a nice setup would be a ANT managed build process that triggers some unit tests, which trigger an svnant tag/branch, which triggers the deployment to the appropriate places. Yes, something like that sounds dandy, personally. One of many, many ways to do it, but it sounds like fun. Know, that a lot of this stuff I talk about, I probably practice about-- well, not as much. I'm a hypocrite, truth be known. Piecemeal is all I can manage. Add a build file for this project here, a customized repository hook there... *Totally* unrelated, but there is a plugin for Thunderbird that does a colored diff compare of a diff file (there's an example perl hook for subversion that will email you the diff when a commit is made), which is pretty super. On Mon, Aug 11, 2008 at 8:39 PM, Kym Kovan [EMAIL PROTECTED] wrote: . I find it interesting, we have been hosting CF for 11 years and still are finding new things to think over... I lovesiz it! :-) -- For a man to conquer himself is the first and noblest of all victories. Plato ~| 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:310838 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew Scott wrote: Don't put words into my mouth. I was not aware I did so. Perhaps you could quote me? As for xml changes that are not related to your source code is generally handled by daily backups anyway, and most people prefer that as it can put the machine into a state quicker than your method. But hey thats your choice, you want to create extra work for you then go for it. Daily backups don't provide the ability to do diffs. As for the actual content of the source files, DID I EVER MENTION ANYTHING about that? NO, I did not and I wouldn't like to have you tell me otherwise. Up until now I only stated my opinion on the content of the source files. Up until now I didn't tell what you wrote. Now you invite me however, I am going to. You did write: SVN was created for one purpose and one purpse only, that was to provide a revision control system for you to roll back, and manage different versions of your code. So yes, you did write that SVN is for code. Jochem ~| 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:310839 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
:-( Took me to literal.. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Jochem van Dieten [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 4:17 PM To: CF-Talk Subject: Re: SVN in Production Now you invite me however, I am going to. You did write: SVN was created for one purpose and one purpse only, that was to provide a revision control system for you to roll back, and manage different versions of your code. So yes, you did write that SVN is for code. Jochem ~| 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:310840 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Brian Kotek wrote: All of this can (and should) be automated with ANT. That means at the click of my mouse I can execute the entire deployment process in exactly the same way every single time. That might mean: - Zip the current code, timestamp it, and copy it to a back folder for easy retrieval. - Delete the current code - Copy a site maintenance file into the site folder - Pull latest from SVN - Perform export to site folder - Run a reinit HTTP request to reload the application - Send an email to notify stakeholders of success I agree with the need for scripting part. What you do in your scripting however can be very different if you have different requirements. In my case the scripting does: - export the sources - export externals - export the buildfiles - spawn an Ant task to package an EAR - remove all unit tests - compile the code - spawn an Ant task to package another EAR - calculate MD5 checksums of both EARs Then the non-compiled EAR with unit tests goes to the test environment and if approved there the compiled EAR without unit tests goes to QA so the customer can approve it. Test, QA and production do not have access to source control for CFML sources (only for configuration files), they get EAR files with MD5 checksums and test reports of the previous step in the cycle. This approach is very different from most approaches but the reason for that is that quite a bit of the software we develop is not deployed on infrastructure we control. We have had too much trouble with people messing around with things they didn't understand and with deployment instructions that were only partially followed. And we just don't want to deploy any sources at all, just compiled code. Jochem ~| 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:310843 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew Scott wrote: There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. That is correct. Which is why it is a best practice to always tag your code and deploy a tag. Deployment scripts should not do merging, they should only deploy what has already been merged, tagged and tested. Jochem PS I would appreciate it if you would limit your messages to the technical aspects of software development and were to leave out the personal slurs. ~| 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:310844 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew Scott wrote: Or in a more common example, as most Coldfusion developers are single team developers. The client has requested a complete change to their system, when finished he approved 60% of the changes and wants them to go live right now. I can't just export now can I? So again I have to either tell the client no, which will upset them.. Or make an eyeball sync to production to make the client happy, while they get me to finalise the remaining 40% of the changes. Under these circumstances, you can't just do an export from SVN. But you could do an eyeball merge to a new branch, tag it, deploy the tag to QA and when the client approves it deploy the tag to production. Jochem ~| 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:310847 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Mon, Aug 11, 2008 at 11:56 PM, Andrew Scott wrote: :-( Yes, I understand about commit early and commit often. But I don't see how that solves the problem? That really has nothing to do with branches, though does it? Well I guess a real-world example would be, what, 4 tickets, 3 of which are higher priority than the 4th? Any ticketing system worth it's salt integrates quite nice with version control, and yes, why not use branches? Copies are cheap! Keep 'em in sync with trunk, and you're good to go. Taking advantage of the ticketing system, you've got the specs for the changes, the code for the changes, and a spoken word history about the changes all in one place. You don't have to leave the branches around forever, although they've got their forever history. Branch, merge, merge, ... , delete. You can always go back, if you need to, but that way things are organized in a manner where deployment of approved tickets could probably be automated, depending on your routine. How you branch and tag depend a lot on your software and development cycle, so varies, but I think the important theme here is organized consistency. Like I said (sorta) earlier tho, nothing covers all the bases (it's related to Gödel, somehow ;]), and sometimes it's frustrating, but what do you do? Learn, adapt, continue on-- could be my motto. =] -- [Comment on List]: I still find it hard to believe that it is impossible to prove i am real. I can only believe I am Real. I didn't arrive at my understanding of the fundamental laws of the universe through my rational mind - A. Einstein ~| 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:310848 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Sure, that makes perfect sense Jochem. I was just outlining how I've done this and how I think most people would probably approach it. Obviously you need to do it in the way that makes sense for your application and your environment. Whatever the steps involved, the key is to make it as automatic and repeatable as possible. Thanks. On Tue, Aug 12, 2008 at 3:25 AM, Jochem van Dieten [EMAIL PROTECTED]wrote: Brian Kotek wrote: All of this can (and should) be automated with ANT. That means at the click of my mouse I can execute the entire deployment process in exactly the same way every single time. That might mean: - Zip the current code, timestamp it, and copy it to a back folder for easy retrieval. - Delete the current code - Copy a site maintenance file into the site folder - Pull latest from SVN - Perform export to site folder - Run a reinit HTTP request to reload the application - Send an email to notify stakeholders of success I agree with the need for scripting part. What you do in your scripting however can be very different if you have different requirements. In my case the scripting does: - export the sources - export externals - export the buildfiles - spawn an Ant task to package an EAR - remove all unit tests - compile the code - spawn an Ant task to package another EAR - calculate MD5 checksums of both EARs Then the non-compiled EAR with unit tests goes to the test environment and if approved there the compiled EAR without unit tests goes to QA so the customer can approve it. Test, QA and production do not have access to source control for CFML sources (only for configuration files), they get EAR files with MD5 checksums and test reports of the previous step in the cycle. This approach is very different from most approaches but the reason for that is that quite a bit of the software we develop is not deployed on infrastructure we control. We have had too much trouble with people messing around with things they didn't understand and with deployment instructions that were only partially followed. And we just don't want to deploy any sources at all, just compiled code. Jochem ~| 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:310860 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
On Tue, Aug 12, 2008 at 3:29 AM, Jochem van Dieten [EMAIL PROTECTED]wrote: That is correct. Which is why it is a best practice to always tag your code and deploy a tag. Deployment scripts should not do merging, they should only deploy what has already been merged, tagged and tested. Thanks, Jochem, that's exactly what I was saying as well but in response I got a face full of curse words and insults about my professional abilities. Jochem PS I would appreciate it if you would limit your messages to the technical aspects of software development and were to leave out the personal slurs. I couldn't agree more. I had a rather scathing reply to Andrew typed out but I deleted it because it just isn't worth it to fuel that fire. :-) ~| 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:310861 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
You need to delete those SVN dir's with a script. Hello, Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? -- Yours, Kym Kovan mbcomms ~| 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:310663 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
You need to delete those SVN dir's with a script. mbcomms BTW: I still prefer using DIFF in combination with FTP... But I am a lonely guy, if you search with deploy web app on google it's all SVN nowadays. ~| 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:310664 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
SVN SHOULD NEVER BE USED IN PRODUCTION... SVN is used to have a revision control system, so that you could roll back to a previous version or whatever you need to do. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. But then if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never and I will repeat this again. NEVER USE SVN in production. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. I am shocked to find people don't research their tools enough. So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn fool, and should be shot on sight. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 11:07 AM To: CF-Talk Subject: SVN in Production Hello, Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? -- Yours, Kym Kovan mbcomms ~| 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:310665 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
clear statement, I'll use that in my meeting with the boss :) SVN SHOULD NEVER BE USED IN PRODUCTION... SVN is used to have a revision control system, so that you could roll back to a previous version or whatever you need to do. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. But then if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never and I will repeat this again. NEVER USE SVN in production. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. I am shocked to find people don't research their tools enough. So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn fool, and should be shot on sight. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 Hello, Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? -- Yours, Kym Kovan mbcomms ~| 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:310673 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
Yeah There are so many different ways to deploy, the problem boils down to the tools that we use. Me, I can't vouch for the likes of svnAnt and I DO not see a need for svnAnt to migrate changes to production, a first of deployment sure I could see its merits. But not as I make changes or fixes. I might make 10 FIXES, but only 2 should or need to go live. Me, I use the fact that the application I use / write has 2 states of development. One, is the latest build and changes or additions to the application itself. The second is what is currently in production. I use and endorse Beyond Compare by Scooter Software, when deploying changes to production. However when it comes to total control. I will have a branch in SVN for stable and build/release version number and use the switch to switch between the versions. But when it comes to DIFF, BC (Beyond Compare) is as simple as it needs to be. Does the change I made need to be deployed, visually the change says no so then I can deploy that file or line by line. Just in case I was working on other things when I fixed a major bug or something. But eventually one should deploy the best that suits their needs, and SVN is not the way to go. Use what best suits you, but DO NOT USE SVN as a means to keep production upto date. NEVER... -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Joeri B [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 7:04 PM To: CF-Talk Subject: Re: SVN in Production clear statement, I'll use that in my meeting with the boss :) SVN SHOULD NEVER BE USED IN PRODUCTION... SVN is used to have a revision control system, so that you could roll back to a previous version or whatever you need to do. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. But then if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never and I will repeat this again. NEVER USE SVN in production. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. I am shocked to find people don't research their tools enough. So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn fool, and should be shot on sight. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 Hello, Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? -- Yours, Kym Kovan mbcomms ~| 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:310676 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Kym Kovan wrote: Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? You only get the extra files if you do a checkout to create a working copy, not if you do an export. Since in our workflow web content has a strict one way (dev - QA - prod) publishing cycle that works fine with exports. For server configuration files (basically all of /etc/) I need working copies because they go both ways, from repo to server and from server to repo. But on the other hand, I don't want any extra files in my /etc/ because that would seriously mess up anything that works with config directories instead of config files. So there I typically have a working copy in /tmp/ that mirrors /etc/ and use that if I have to push files to the repository. That does require discipline though to keep /etc/ and /tmp/etc/ in sync. Jochem ~| 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:310678 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
What Do you mean by repo - server and server - repo? The latter should never be an issue, or even considered. Anyone who makes changes to production and not in a development environment shouod be hung out to dry or better still beaten with a stick until you realise that development is what it means. You develop, you fix and you test. And when you and your client are happy then it is moved from dev / qa to production. If you make changes to production and the stick back into the SVN, you seriously need to rethink your procedures. NEVER USE production WITH YOUR SVN REPOSTIORY. Development at all costs, needs to do one of two things. Be the latest, be tested and if required then deployed to live. NEVER the other way around. If youu are intent on following the wrong rules of development then you are doomed to be the one that is developing with the wrong frame of mind. Once you have deployed to a production server, it should never have any ties with the repository in any way shape or form. If you are one of those that think this is ok, then you will need to adopt new procedures quickly. Before you adopt bad and I mean VERY BAD ideas. SVN was created for one purpose and one purpse only, that was to provide a revision control system for you to roll back, and manage different versions of your code. If you chose to ignore that then you are creating more work and more headaches to your development team or yourself if you are a lone developer. The thing to remember is what someone else might think about your procedures, and I do not care what anyone else has to say about using SVN when it comes to production code. If you can't be bothered to read the docs on what SVN actually is, or how to best utilise it then you should NOT be using it. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Jochem van Dieten [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 7:29 PM To: CF-Talk Subject: Re: SVN in Production Kym Kovan wrote: Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? You only get the extra files if you do a checkout to create a working copy, not if you do an export. Since in our workflow web content has a strict one way (dev - QA - prod) publishing cycle that works fine with exports. For server configuration files (basically all of /etc/) I need working copies because they go both ways, from repo to server and from server to repo. But on the other hand, I don't want any extra files in my /etc/ because that would seriously mess up anything that works with config directories instead of config files. So there I typically have a working copy in /tmp/ that mirrors /etc/ and use that if I have to push files to the repository. That does require discipline though to keep /etc/ and /tmp/etc/ in sync. Jochem ~| 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:310682 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Monday 11 Aug 2008, Andrew Scott wrote: SVN SHOULD NEVER BE USED IN PRODUCTION... I assume you mean 'to deploy code to a production box' ? Because as a production RCS it's well known for being utterly solid. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. SVN checkouts only contain one extra copy of each file (in side the .svn directory). This is unlikely to be an order of magnitude greater than the 'actual' file as you suggest. But then if one read the docs to these tools, one would not use SVN in production. I think 'svn help export' is fairly clear in not saying one way or the other. SVN can be expensive when it comes to hard drive space, Hard drive space is *very* cheap, really. A lot of people are using virtual servers anyway, so more hard drive space is free*. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. Why wouldn't I use 'svn diff' or a suitable GUI ? So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn fool, and should be shot on sight. I think you must have had a bad experience at some point... -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310681 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Yes, indeed. With a diff ( I want to use free commander with Winmerge) tool, you SEE the changes going live. I point that one out in a previous post. I work on a large project in a existing application which I check-in constantly (Backup purpose and team work) , but doesn't need to go live. Because it's not finished yet. With a diff tool it's easy to put other fixes live, and others not. With SVN (export) it's difficult. You can work with branches... but that is tricky. Yeah There are so many different ways to deploy, the problem boils down to the tools that we use. Me, I can't vouch for the likes of svnAnt and I DO not see a need for svnAnt to migrate changes to production, a first of deployment sure I could see its merits. But not as I make changes or fixes. I might make 10 FIXES, but only 2 should or need to go live. Me, I use the fact that the application I use / write has 2 states of development. One, is the latest build and changes or additions to the application itself. The second is what is currently in production. I use and endorse Beyond Compare by Scooter Software, when deploying changes to production. However when it comes to total control. I will have a branch in SVN for stable and build/release version number and use the switch to switch between the versions. But when it comes to DIFF, BC (Beyond Compare) is as simple as it needs to be. Does the change I made need to be deployed, visually the change says no so then I can deploy that file or line by line. Just in case I was working on other things when I fixed a major bug or something. But eventually one should deploy the best that suits their needs, and SVN is not the way to go. Use what best suits you, but DO NOT USE SVN as a means to keep production upto date. NEVER... -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 clear statement, I'll use that in my meeting with the boss :) if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never ~| 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:310683 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
This is an interesting conversation, I've been using SVN Export for some time now when looking to deploy changes to production and not really had any beef from it. I understand what you guys are saying here about only wishing to deploy certain changes, that's a very valid use case, but to be honest, I would perhaps suggest that you guys are not strict enough on your version control in the first place and perhaps you processes rant quite right, as it sounds like you're deploying code straight from trunk / branches? Using your DIFF based stuff to pick and choose which modifications get deployed? Surely, once you know what code version is 'production ready' then you build it into a release candidate in a new tag? You then can use SVN to deploy from the latest tag to production? No? I wouldn't ever deploy from anything that wasn't in /tags, and the only way anything makes it into a tag is when its test and ready as a release candidate. -Original Message- From: Joeri B [mailto:[EMAIL PROTECTED] Sent: 11 August 2008 10:58 To: CF-Talk Subject: Re: SVN in Production Yes, indeed. With a diff ( I want to use free commander with Winmerge) tool, you SEE the changes going live. I point that one out in a previous post. I work on a large project in a existing application which I check-in constantly (Backup purpose and team work) , but doesn't need to go live. Because it's not finished yet. With a diff tool it's easy to put other fixes live, and others not. With SVN (export) it's difficult. You can work with branches... but that is tricky. Yeah There are so many different ways to deploy, the problem boils down to the tools that we use. Me, I can't vouch for the likes of svnAnt and I DO not see a need for svnAnt to migrate changes to production, a first of deployment sure I could see its merits. But not as I make changes or fixes. I might make 10 FIXES, but only 2 should or need to go live. Me, I use the fact that the application I use / write has 2 states of development. One, is the latest build and changes or additions to the application itself. The second is what is currently in production. I use and endorse Beyond Compare by Scooter Software, when deploying changes to production. However when it comes to total control. I will have a branch in SVN for stable and build/release version number and use the switch to switch between the versions. But when it comes to DIFF, BC (Beyond Compare) is as simple as it needs to be. Does the change I made need to be deployed, visually the change says no so then I can deploy that file or line by line. Just in case I was working on other things when I fixed a major bug or something. But eventually one should deploy the best that suits their needs, and SVN is not the way to go. Use what best suits you, but DO NOT USE SVN as a means to keep production upto date. NEVER... -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 clear statement, I'll use that in my meeting with the boss :) if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never ~| 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:310684 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Monday 11 Aug 2008, Andrew Scott wrote: The latter should never be an issue, or even considered. Anyone who makes changes to production and not in a development environment shouod be hung out to dry or better still beaten with a stick until you realise that development is what it means. You have clearly never worked with a slightly broken production system, and a PHB/client/boss breathing on your neck. You develop, you fix and you test. And when you and your client are happy then it is moved from dev / qa to production. Man, if only the world was that simple all the time ! SVN was created for one purpose and one purpse only, that was to provide a revision control system for you to roll back, a Actually, no, SVN was created To take over the CVS user base. Specifically, we're writing a new version control system that is very similar to CVS, but fixes many things that are broken (http://subversion.tigris.org/faq.html#why) -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310685 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
No one and I will repeat myself... No one is saying hard drive is not cheap. But let me ask you this, if you had a shared hosting plan with 100mb of storagespace, and part of this is your SQL space is also included. If you checkout it might be a copy of the current index from svn, but that is still and let me repeat myself this is still double your storage space if in a shared environment where space is an issue. No even so, whether it is an issue or not. You should never have .svn directories in a production environment, if you do then I can no longer help your ignorance. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 7:46 PM To: CF-Talk Subject: Re: SVN in Production On Monday 11 Aug 2008, Andrew Scott wrote: SVN SHOULD NEVER BE USED IN PRODUCTION... I assume you mean 'to deploy code to a production box' ? Because as a production RCS it's well known for being utterly solid. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. SVN checkouts only contain one extra copy of each file (in side the .svn directory). This is unlikely to be an order of magnitude greater than the 'actual' file as you suggest. But then if one read the docs to these tools, one would not use SVN in production. I think 'svn help export' is fairly clear in not saying one way or the other. SVN can be expensive when it comes to hard drive space, Hard drive space is *very* cheap, really. A lot of people are using virtual servers anyway, so more hard drive space is free*. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. Why wouldn't I use 'svn diff' or a suitable GUI ? So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn fool, and should be shot on sight. I think you must have had a bad experience at some point... -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310687 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
I am the same, I could have 20 tickets at any one time that I am also working on. The moment the client says I want ticket number such and such to go live, but the ticket that is completed I haven't completed. So what do you do. 1) Export from SVN to live, this will not work because the tickets that do go live are not requested to go live. Do you branch and for what reason, I would only branch or tag under specific conditions and these conditions are determined by the team involved. 2) Make the eyeball changes that are needed to go live? Me, I would branch as much as possible. If you have only one client for your application then you might not need too. The point is this, if I was to make a production for the first time then an export would be fine. However that is never the case when it has been live for many days or more and I need to make changes to the system over a period of time. If I was to do a full export with all changes that I was working on there are two things that can happen. The first is that my changes that were never asked to go live will go live, if I choose to branch every change I make will be branched then it comes down to a nightmare as to which version I should switch too. I am not going to tell you how to use SVN, but I can guide you to the proper uses and if anyone chooses to ignore that, then they are on their own when it comes to support and what constitutes migration or a normal release. So this is what I have to say on the subject... If you want to migrate from SVN (via export) that is your choice, and you obviously have a different approach to your life cycle of the application you developed. But when it comes to experience, someone is always going to come along and tell you that you need to do it this way. But if you feel that your way is better (not you as the person who began this thread, but you as a developer who might be reading this thread.) thern by all means do what you need. But if I have to come along, and migrate from production to SVN because you made the changes live before being in a tested state and approved before making it live Then you seriously need to look at your FULL SDLC And make changes quickly before someone who knows what they are doing takes over from your work Clients are not stupid, they act that way to play you against other developers. If you think you know better then good luck to you. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Joeri B [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 7:58 PM To: CF-Talk Subject: Re: SVN in Production Yes, indeed. With a diff ( I want to use free commander with Winmerge) tool, you SEE the changes going live. I point that one out in a previous post. I work on a large project in a existing application which I check-in constantly (Backup purpose and team work) , but doesn't need to go live. Because it's not finished yet. With a diff tool it's easy to put other fixes live, and others not. With SVN (export) it's difficult. You can work with branches... but that is tricky. Yeah There are so many different ways to deploy, the problem boils down to the tools that we use. Me, I can't vouch for the likes of svnAnt and I DO not see a need for svnAnt to migrate changes to production, a first of deployment sure I could see its merits. But not as I make changes or fixes. I might make 10 FIXES, but only 2 should or need to go live. Me, I use the fact that the application I use / write has 2 states of development. One, is the latest build and changes or additions to the application itself. The second is what is currently in production. I use and endorse Beyond Compare by Scooter Software, when deploying changes to production. However when it comes to total control. I will have a branch in SVN for stable and build/release version number and use the switch to switch between the versions. But when it comes to DIFF, BC (Beyond Compare) is as simple as it needs to be. Does the change I made need to be deployed, visually the change says no so then I can deploy that file or line by line. Just in case I was working on other things when I fixed a major bug or something. But eventually one should deploy the best that suits their needs, and SVN is not the way to go. Use what best suits you, but DO NOT USE SVN as a means to keep production upto date. NEVER... -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 clear statement, I'll use that in my meeting with the boss :) if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never ~| Adobe® ColdFusion® 8 software 8 is the most important and dramatic release to date Get the Free Trial http
RE: SVN in Production
Really Let me tell you something then... I have 10 copies of this application in production, I could be fixing a bug that is related to only one of these branches. So if I switch ( come on I can't be the only one who uses the switch, to switch between different branches/tags?) then I can work on that one version, but then I decide that this fix needs to go to all the versions... I then merge/migrate this change, then I know need to migrate this change so how do I do it? Easy, I DO NOT EXPORT THE ENTIRE APPLICATION. Why is that, because the fix is related to the one client and I need to sync just that change. And how do you do that? That is not for me to tell you that, it is documented in the SVN and can be googled as well.. But the point is simple... 1) if I want to take 100% out of SVN then an export is good enough 2) if I need to migrate a change then I would compare the changes that I need, and this needs to be at an eyeball level. If you are dealing with an ORM, like I am with GORM then you need to be extremely careful what change you make live, it might only reflect a fix for one of your clients. And in this case you WILL not do an export, you would sync your changes only. Again I will say this to you all, think about your problem first. Then think about how it would work under certain circumstances, if it will not work for you then your approach is wrong as simple as that. NEVER USE SVN FOR PRODUCTION. NEVER, NEVER, NEVER. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Robert Rawlins [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 8:09 PM To: CF-Talk Subject: RE: SVN in Production This is an interesting conversation, I've been using SVN Export for some time now when looking to deploy changes to production and not really had any beef from it. I understand what you guys are saying here about only wishing to deploy certain changes, that's a very valid use case, but to be honest, I would perhaps suggest that you guys are not strict enough on your version control in the first place and perhaps you processes rant quite right, as it sounds like you're deploying code straight from trunk / branches? Using your DIFF based stuff to pick and choose which modifications get deployed? Surely, once you know what code version is 'production ready' then you build it into a release candidate in a new tag? You then can use SVN to deploy from the latest tag to production? No? I wouldn't ever deploy from anything that wasn't in /tags, and the only way anything makes it into a tag is when its test and ready as a release candidate. -Original Message- From: Joeri B [mailto:[EMAIL PROTECTED] Sent: 11 August 2008 10:58 To: CF-Talk Subject: Re: SVN in Production Yes, indeed. With a diff ( I want to use free commander with Winmerge) tool, you SEE the changes going live. I point that one out in a previous post. I work on a large project in a existing application which I check-in constantly (Backup purpose and team work) , but doesn't need to go live. Because it's not finished yet. With a diff tool it's easy to put other fixes live, and others not. With SVN (export) it's difficult. You can work with branches... but that is tricky. Yeah There are so many different ways to deploy, the problem boils down to the tools that we use. Me, I can't vouch for the likes of svnAnt and I DO not see a need for svnAnt to migrate changes to production, a first of deployment sure I could see its merits. But not as I make changes or fixes. I might make 10 FIXES, but only 2 should or need to go live. Me, I use the fact that the application I use / write has 2 states of development. One, is the latest build and changes or additions to the application itself. The second is what is currently in production. I use and endorse Beyond Compare by Scooter Software, when deploying changes to production. However when it comes to total control. I will have a branch in SVN for stable and build/release version number and use the switch to switch between the versions. But when it comes to DIFF, BC (Beyond Compare) is as simple as it needs to be. Does the change I made need to be deployed, visually the change says no so then I can deploy that file or line by line. Just in case I was working on other things when I fixed a major bug or something. But eventually one should deploy the best that suits their needs, and SVN is not the way to go. Use what best suits you, but DO NOT USE SVN as a means to keep production upto date. NEVER... -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 clear statement, I'll use that in my meeting with the boss :) if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never
RE: SVN in Production
DO NOT ASSUME WHAT I HAVE DONE OR NOT DONE I have not only been there, but that was 10 years ago and I have not only learnt from that, I have moved onto better and bigger things. If you feel it works for you then continue, but let me tell you this. Move outside of coldfusion and use those same approaches you will be not only scoldered. But I would say you might become an outcast to boot If you feel SVN - production works for you... Then go for it... But let me tell you this, change jobs into java/groovy/grails and you will and I will say this WILL be a minority who knows nothing. I could create an image, this image could be used for 10 different sites and slight changes to each version, but it is only relevant to one of my clients. I would not be making that an export from SVN because you will end up with images that do not belong to the project wasting HD space... Think about it for a minute -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 8:09 PM To: CF-Talk Subject: Re: SVN in Production On Monday 11 Aug 2008, Andrew Scott wrote: The latter should never be an issue, or even considered. Anyone who makes changes to production and not in a development environment shouod be hung out to dry or better still beaten with a stick until you realise that development is what it means. You have clearly never worked with a slightly broken production system, and a PHB/client/boss breathing on your neck. You develop, you fix and you test. And when you and your client are happy then it is moved from dev / qa to production. Man, if only the world was that simple all the time ! SVN was created for one purpose and one purpse only, that was to provide a revision control system for you to roll back, a Actually, no, SVN was created To take over the CVS user base. Specifically, we're writing a new version control system that is very similar to CVS, but fixes many things that are broken (http://subversion.tigris.org/faq.html#why) -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310692 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
Andrew Scott wrote: ... snip If you checkout it might be a copy of the current index from svn, but that is still and let me repeat myself this is still double your storage space if in a shared environment where space is an issue. Andrew, that is a major step back from your earlier statements. I have been sitting back watching the responses, from Andrew's original Extreme statement to more measured responses from others and what I gather in one aspect at least is that the extra disk space could be an issue in that a simple checkout will take double the space of the code base itself. Beyond that I have seen no hard comments about security risks, etc., only fluffy ones. Andrew said again: No even so, whether it is an issue or not. You should never have .svn directories in a production environment, if you do then I can no longer help your ignorance. Why not Andrew? I asked what I thought was a reasonable question and I did it because of a request of a client of ours. I have always thought SVN is not for prod servers but when I saw that thread I thought it might be sensible to ask why? You suggested doing some Googling, I found a whole bunch of folk who do use SVN clients on their Production servers as well as folk who say never just like you but also not with explanations as to why, just like you. So why? To put the whole thing in perspective a little context may come in handy. We started as a CF development shop back in the 1.5 days and took up hosting CF sites as no-one else did back then. The wheels have turned and now we do development work again as well as serious hosting and have a nice environment with workstations that run several versions of CF flowing through to test and stage servers where clients can make sure all is right before their sites get flipped over into production. SVN in the background, etc, all nicely civilized. On the hosting side we have many sites that we have had nothing to do with from a development perspective but suddenly one of those clients has hit a wall in terms of the size of their site and maintaining it and they want to drop into version control with us and do it properly. Umm, 400MB+ of cfm files, the site with base gifs, js, css, etc to make it work was over 1.5GB. The whole site with client upload areas, etc is about 7GB. We did an initial copy of code, js, etc., onto an intermediate server to import it into SVN and then checked it out to the test server and then ran some file sync tools to the Production boxes which are FTP distance away. It took over an hour to say no difference! So our problem is how to push out changes to the Production boxes in a sensible fashion and hence our question that has raised such ire amongst one person at least :-) -- Yours, Kym Kovan mbcomms ~| 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:310693 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
You're an extremely aggressive individual aren't you Andrew? -Original Message- From: Andrew Scott [mailto:[EMAIL PROTECTED] Sent: 11 August 2008 12:15 To: CF-Talk Subject: RE: SVN in Production DO NOT ASSUME WHAT I HAVE DONE OR NOT DONE I have not only been there, but that was 10 years ago and I have not only learnt from that, I have moved onto better and bigger things. If you feel it works for you then continue, but let me tell you this. Move outside of coldfusion and use those same approaches you will be not only scoldered. But I would say you might become an outcast to boot If you feel SVN - production works for you... Then go for it... But let me tell you this, change jobs into java/groovy/grails and you will and I will say this WILL be a minority who knows nothing. I could create an image, this image could be used for 10 different sites and slight changes to each version, but it is only relevant to one of my clients. I would not be making that an export from SVN because you will end up with images that do not belong to the project wasting HD space... Think about it for a minute -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 8:09 PM To: CF-Talk Subject: Re: SVN in Production On Monday 11 Aug 2008, Andrew Scott wrote: The latter should never be an issue, or even considered. Anyone who makes changes to production and not in a development environment shouod be hung out to dry or better still beaten with a stick until you realise that development is what it means. You have clearly never worked with a slightly broken production system, and a PHB/client/boss breathing on your neck. You develop, you fix and you test. And when you and your client are happy then it is moved from dev / qa to production. Man, if only the world was that simple all the time ! SVN was created for one purpose and one purpse only, that was to provide a revision control system for you to roll back, a Actually, no, SVN was created To take over the CVS user base. Specifically, we're writing a new version control system that is very similar to CVS, but fixes many things that are broken (http://subversion.tigris.org/faq.html#why) -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310694 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew Scott wrote: I could create an image, this image could be used for 10 different sites and slight changes to each version, but it is only relevant to one of my clients. I would not be making that an export from SVN because you will end up with images that do not belong to the project wasting HD space... I think the above paragraph describes where we are at. In your context Andrew what you are saying is correct. I someone has one client with one codebase and one website then your concerns are not theirs. Think about it for a minute Yeah, do that, not all the world is the same colour. -- Yours, Kym Kovan mbcomms ~| 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:310695 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Monday 11 Aug 2008, Andrew Scott wrote: If you feel it works for you then continue, but let me tell you this. Move outside of coldfusion and use those same approaches you will be not only scoldered. But I would say you might become an outcast to boot I dunno, I bet the PHP folks are fond of it too. Obviously fully compiled languages like Java don't let you, but that's another matter... tell you this, change jobs into java/groovy/grails and you will and I will say this WILL be a minority who knows nothing. ah ha, you see ? -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310696 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
On Monday 11 Aug 2008, Kym Kovan wrote: intermediate server to import it into SVN and then checked it out to the test server and then ran some file sync tools to the Production boxes which are FTP distance away. It took over an hour to say no difference! That's one of the great steps SVN decided to take over CVS - keeping a clean local copy so 'diff' is fast and doesn't need access to the network. -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310697 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Kym, I was not responding to you directly, if I did not answer your question then let me ask you this. If you are tight for HD space, and not everyone is. But what good would it be too actually have .svn files on your production server? If it doesn't need to be required to run, then it doesn't need to be there. From a security point of view, unless it is behind a VPN that is totally secure you have your code base open to the whole world when and if it is hacked. Small chance that someone would work out that your production server is connected to your SVN server. If you are like ME and most others, your company or business is behind a firewall. This means a number of things, and if hacked then the code could include your SVN details to connect to your SVN server. Unlikely, but why take the chance? Do you really want me to go further? SVN might be used by some people in production, and these people are in need of a good damn slapping and told to give it up... And over time, all changes made to production and stored back into .svn directories end up increasing your HD space so over a year it will grwo depending on how often youu make changes directly to production and DO NOT FOLLOW a full SDLC. But I guess that anyone who does use an approach of production-svn, do not know what an SDLC is all about or how to protect themselves. In one application, I had made changes to the application that DOES and WILL effect LIVE data. So until the client is happy it gores through the stages of dev - QA - production and then at least, once made live if the changes made to production effect live application data the ownus falls onto the developer and the client. If it is the developer, then they migrated changes that should never have been made live. If it is the client then they have no excuse, because it went through a QA phase for the client to approve from a UAT point of view... And I will make the assumption that if you follow an SDLC you would also be using the UAT, before a client signs of on the changes. Oh wait, some comments here have made a reference to the fact that changes are not signed off on. Which means you could have 20 changes waiting for approval, how do you migrate these changes? You certainly would not export the entire repository now would you? -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 ~| 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:310698 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
No, but bad habits an ill advice can hurt you down the track, could it not? -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 9:33 PM To: CF-Talk Subject: Re: SVN in Production Andrew Scott wrote: I could create an image, this image could be used for 10 different sites and slight changes to each version, but it is only relevant to one of my clients. I would not be making that an export from SVN because you will end up with images that do not belong to the project wasting HD space... I think the above paragraph describes where we are at. In your context Andrew what you are saying is correct. I someone has one client with one codebase and one website then your concerns are not theirs. Think about it for a minute Yeah, do that, not all the world is the same colour. -- Yours, Kym Kovan mbcomms ~| 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:310699 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Actually that's not entirely true And this is one reason I refuse to use subclipse What you don't see is the processes that can and do run in the background, if you run eclipse you can switch on to show hidden processes. Doing this will show you that svn can be contacted and updated without your knowledge, how else do you know if there are changes to the code... You think it guesses? Although having said that, you can even switch this caching off for svn as well. Well in subversive you can, the problem is that when you do sync / merge changes before doing an update can take sooo much longer :-( -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 9:38 PM To: CF-Talk Subject: Re: SVN in Production On Monday 11 Aug 2008, Kym Kovan wrote: intermediate server to import it into SVN and then checked it out to the test server and then ran some file sync tools to the Production boxes which are FTP distance away. It took over an hour to say no difference! That's one of the great steps SVN decided to take over CVS - keeping a clean local copy so 'diff' is fast and doesn't need access to the network. -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310700 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Tom Chiverton wrote: On Monday 11 Aug 2008, Kym Kovan wrote: intermediate server to import it into SVN and then checked it out to the test server and then ran some file sync tools to the Production boxes which are FTP distance away. It took over an hour to say no difference! That's one of the great steps SVN decided to take over CVS - keeping a clean local copy so 'diff' is fast and doesn't need access to the network. Yes, and that lends me to the thought that the best scenario for our particular problem would be to have an exported copy on each production box (yes, they are clustered) and use a standard diff tool from there to flip the changes over to the actual production site. It would not be too hard to set off the flip to happen on all servers at the same time to avoid mayhem. I should have mentioned in my previous explanation that this site is on dedicated boxes so disk space is not an issue. Anyone see a difficulty in doing that? -- Yours, Kym Kovan mbcomms ~| 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:310701 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
And how are you going to migrate small changes in a midst of other changes? -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 10:04 PM To: CF-Talk Subject: Re: SVN in Production Tom Chiverton wrote: On Monday 11 Aug 2008, Kym Kovan wrote: intermediate server to import it into SVN and then checked it out to the test server and then ran some file sync tools to the Production boxes which are FTP distance away. It took over an hour to say no difference! That's one of the great steps SVN decided to take over CVS - keeping a clean local copy so 'diff' is fast and doesn't need access to the network. Yes, and that lends me to the thought that the best scenario for our particular problem would be to have an exported copy on each production box (yes, they are clustered) and use a standard diff tool from there to flip the changes over to the actual production site. It would not be too hard to set off the flip to happen on all servers at the same time to avoid mayhem. I should have mentioned in my previous explanation that this site is on dedicated boxes so disk space is not an issue. Anyone see a difficulty in doing that? -- Yours, Kym Kovan mbcomms ~| 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:310702 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew Scott wrote: What Do you mean by repo - server and server - repo? The latter should never be an issue, or even considered. Anyone who makes changes to production and not in a development environment shouod be hung out to dry or better still beaten with a stick until you realise that development is what it means. So you think the entire /etc/ folder on a production box is the same as an /etc/ folder on a development box? You think they have the same hostnames? The same IP addresses? The same firewall rules? That the test environment has a two year backup retention like production has? Not everybody uses SVN just for sourcecode. Some use it for their university thesis. Some for their grocery list. Some use SVN for complete server configurations. And what you use it for does influence the usage pattern. It is perfectly acceptable to change the -Dmail.host oarameter in your jvm.config file directly on production and then back it up to SVN. Once you have deployed to a production server, it should never have any ties with the repository in any way shape or form. If you are one of those that think this is ok, then you will need to adopt new procedures quickly. Before you adopt bad and I mean VERY BAD ideas. Generally speaking you don't want to have production running directly from a working copy. But there is nothing wrong with putting $Id$, $HeadURL$ etc. in your sources so that code and configuration files on the production box points back to a specific version of a file in a repository. Jochem ~| 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:310704 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew Scott wrote: And how are you going to migrate small changes in a midst of other changes? Good response Andrew to my question, just what I wanted. Unfortunately your response is top-replied with your signature as well, with its correct --, so in Thunderbird my question below that is lost. But this brings up a point I noticed in your earlier replies, you talked of 20 tickets open and sending one ticket to production. You also talked in another reply about the work in maintaining multiple branches for them all but surely this is what keeping tight control over your code is all about? A change is A branch, merge it when it is right and there is no problem surely? You talked about one application but many clients running off it, with variations for all of them. If changing one client's code affects others then surely the site architecture is wrong, it isn't one application is it many similar ones. I feel motivated to shout at you like you shout at everyone else about how bad that is, but I won't -- Yours, Kym Kovan mbcomms ~| 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:310706 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Monday 11 Aug 2008, Andrew Scott wrote: And this is one reason I refuse to use subclipse will show you that svn can be contacted and updated without your knowledge, how else do you know if there are changes to the code... That's a good thing. I want my RCS updated when I delete or rename a file, and I really don't want it bothering my all the time either. I can always look in Eclipse's console to see what it's done, or the web view of the repository, or the RSS feed of recent changes or ... well. Well in subversive you can, the problem is that when you do sync / merge changes before doing an update can take sooo much longer :-( Err, yes ? That's one of the trade-offs the SVN folks made when they were designing things... -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310707 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Monday 11 Aug 2008, Andrew Scott wrote: secure you have your code base open to the whole world when and if it is hacked. With the vast majority of ColdFusion deployments, that's the case anyway. The default JRun connector for Adobe's engine still runs the .cfm files from inside the .svn sub dirs, so even if you did have an actual checkout in your web root (rather than an export) there's still no way for source code to leak out, without logging interactively on to the box. firewall. This means a number of things, and if hacked then the code could include your SVN details to connect to your SVN server. Unlikely, but why take the chance? shrug Then can also read neo-query.xml and get to my DB directly. Or sniff my home SSH pass phrase. I don't see how this is SVNs 'fault'. SVN might be used by some people in production, and these people are in need of a good damn slapping and told to give it up... Geez. You are not the world. And over time, all changes made to production and stored back into .svn directories end up increasing your HD space so over a year it will grwo depending on how often youu make changes directly to production and DO NOT FOLLOW a full SDLC. I've no idea what a SDLC is in this context, but our SVN repo is only 403 meg, and we've been using it heavily for years, with rev. numbers now in the mid four figures. This is not excessive use of space by any stretch. But I guess that anyone who does use an approach of production-svn, do not know what an SDLC is all about or how to protect themselves. Assuming you mean Systems Development Life Cycle, we've got a perfectly good one, tyvm. of dev - QA - production and then at least, once made live if the changes Uh huh. We then use SVN make sure what was QA'ed and tested is exactly the same as what was deployed. Why is this bad ? approval, how do you migrate these changes? You certainly would not export the entire repository now would you? Err, no. What has one to do with the other ? -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310708 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
I disagree completely. There's absolutely nothing wrong with using SVN in production for deployment. Beyond Compare? It's a great program...but using it to deploy code? The idea makes me shudder. In fact, doing anything manual related to code deployment makes me shudder. There are easy ways around the issue you bring up about size: it's called an SVN Export. It's meant to do EXACTLY what you're talking about: create a copy of the source code with no SVN-related files. All of this can (and should) be automated with ANT. That means at the click of my mouse I can execute the entire deployment process in exactly the same way every single time. That might mean: - Zip the current code, timestamp it, and copy it to a back folder for easy retrieval. - Delete the current code - Copy a site maintenance file into the site folder - Pull latest from SVN - Perform export to site folder - Run a reinit HTTP request to reload the application - Send an email to notify stakeholders of success You can also have it run unit tests and only deploy if all tests pass. The bottom line is that using SVN and ANT to help you deploy code is EXACTLY what these tools were meant to do. If I have to do anything more than click my mouse once to execute an entire deployment process, I'm doing something wrong. On Mon, Aug 11, 2008 at 4:20 AM, Andrew Scott [EMAIL PROTECTED]wrote: SVN SHOULD NEVER BE USED IN PRODUCTION... SVN is used to have a revision control system, so that you could roll back to a previous version or whatever you need to do. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. But then if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never and I will repeat this again. NEVER USE SVN in production. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. I am shocked to find people don't research their tools enough. So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn fool, and should be shot on sight. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 11:07 AM To: CF-Talk Subject: SVN in Production Hello, Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? -- Yours, Kym Kovan mbcomms ~| 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:310710 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Kym Kovan wrote: Yes, and that lends me to the thought that the best scenario for our particular problem would be to have an exported copy on each production box (yes, they are clustered) and use a standard diff tool from there to flip the changes over to the actual production site. I can not imagine any scenario where diff / patch / merge ever is the best way to deploy production code. Because what you would do with diff / patch / merge is either an svn export of tag X to some temporary location and then make your production location equal to the temporary location, or you do something more complex where you do an actual merge and choose to apply some changesets and not others. In the first case, you should just do an svn export followed by a filesystem move. Not only is that much easier, in most modern filesystems a move is an atomic operation so it is much safer. (Or just point your mapping/webroot to the new version you exported. Talk about an easy rollback scenario :) The second case is something you just shouldn't do. Because what you are really saying is compare version A and B and apply the changes to version C. That means that the final outcome of the process depends on what is in position on the final location already and if some file got corrupted in that power failure three months ago, it will still be corrupted after the new release. In that scenario it is an absolute nightmare to guarantee that what you tested in QA is the same as what you deployed in production. If you deploy code in production you always want it to be an unchanged export of some unique svn URL (preferably a tag). Even a checkout with all the extra files is better then a local merge. Jochem ~| 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:310742 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
On Mon, Aug 11, 2008 at 5:25 AM, Kym Kovan wrote: So our problem is how to push out changes to the Production boxes in a sensible fashion and hence our question that has raised such ire amongst one person at least :-) I haven't been watching this thread too close, but... SVN has something called repository hooks, which fire when certain actions occur. So when I get a commit action, my repo does some stuff... looks at what the thing was, where it was, etc., and the repo server does stuff based on that information. I use rsync, a tool designed specifically for keeping filesystems in sync, to push the changes to the places they need to go. It's fast, and only copes what's changed. This is not an uncommon setup, as you'll see if you research SVN deployment, but I offer it, in case it hasn't been mentioned in the thread already. And you can use those repository hooks to fire off unit-tests, or whatever else you need to do as part of your regiment. Great stuff! HIH -- For a man to conquer himself is the first and noblest of all victories. Plato ~| 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:310776 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Don't put words into my mouth. As for xml changes that are not related to your source code is generally handled by daily backups anyway, and most people prefer that as it can put the machine into a state quicker than your method. But hey thats your choice, you want to create extra work for you then go for it. As for the actual content of the source files, DID I EVER MENTION ANYTHING about that? NO, I did not and I wouldn't like to have you tell me otherwise. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Jochem van Dieten [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 10:23 PM To: CF-Talk Subject: Re: SVN in Production Andrew Scott wrote: What Do you mean by repo - server and server - repo? The latter should never be an issue, or even considered. Anyone who makes changes to production and not in a development environment shouod be hung out to dry or better still beaten with a stick until you realise that development is what it means. So you think the entire /etc/ folder on a production box is the same as an /etc/ folder on a development box? You think they have the same hostnames? The same IP addresses? The same firewall rules? That the test environment has a two year backup retention like production has? Not everybody uses SVN just for sourcecode. Some use it for their university thesis. Some for their grocery list. Some use SVN for complete server configurations. And what you use it for does influence the usage pattern. It is perfectly acceptable to change the -Dmail.host oarameter in your jvm.config file directly on production and then back it up to SVN. Once you have deployed to a production server, it should never have any ties with the repository in any way shape or form. If you are one of those that think this is ok, then you will need to adopt new procedures quickly. Before you adopt bad and I mean VERY BAD ideas. Generally speaking you don't want to have production running directly from a working copy. But there is nothing wrong with putting $Id$, $HeadURL$ etc. in your sources so that code and configuration files on the production box points back to a specific version of a file in a repository. Jochem ~| 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:310787 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
Kym, Think of an Application has being something that more than one client could have. Then think about their requirements, and how it might differ to another client. It is no secret that we have released our new flagship product into private beta, this product will have so many different carnations to the application. Anyway the point is that I might have one section, that is in 2 versions that need to be fixed. I switch to the first version and fix it, follow the SDLC and when it is approved it is then migrated to production. In the meantime we realise that another client uses this in their instance, so we now need to merge the changes to their version. This is an extreme case, but it highlights the switching to branches, tags or any version you need too. As for tickets, I just fixed 3 bugs. And another developer just also added a new module. But the module is not ready for production. So that means we need to sync the changes that I made and leave the other developers away from production. Which means we now have to eyeball these changes to production. Or in a more common example, as most Coldfusion developers are single team developers. The client has requested a complete change to their system, when finished he approved 60% of the changes and wants them to go live right now. I can't just export now can I? So again I have to either tell the client no, which will upset them.. Or make an eyeball sync to production to make the client happy, while they get me to finalise the remaining 40% of the changes. Under these circumstances, you can't just do an export from SVN. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 11:05 PM To: CF-Talk Subject: Re: SVN in Production Andrew Scott wrote: And how are you going to migrate small changes in a midst of other changes? Good response Andrew to my question, just what I wanted. Unfortunately your response is top-replied with your signature as well, with its correct --, so in Thunderbird my question below that is lost. But this brings up a point I noticed in your earlier replies, you talked of 20 tickets open and sending one ticket to production. You also talked in another reply about the work in maintaining multiple branches for them all but surely this is what keeping tight control over your code is all about? A change is A branch, merge it when it is right and there is no problem surely? You talked about one application but many clients running off it, with variations for all of them. If changing one client's code affects others then surely the site architecture is wrong, it isn't one application is it many similar ones. I feel motivated to shout at you like you shout at everyone else about how bad that is, but I won't -- Yours, Kym Kovan mbcomms ~| 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:310788 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
No Tom... There is a bug in Subclipse, that sees file saving take anything from an extra 2mins upto hours If you read what I replied too, then read my response and you know about that bug then you will know what I said to be correct in a response. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 11:46 PM To: CF-Talk Subject: Re: SVN in Production On Monday 11 Aug 2008, Andrew Scott wrote: And this is one reason I refuse to use subclipse will show you that svn can be contacted and updated without your knowledge, how else do you know if there are changes to the code... That's a good thing. I want my RCS updated when I delete or rename a file, and I really don't want it bothering my all the time either. I can always look in Eclipse's console to see what it's done, or the web view of the repository, or the RSS feed of recent changes or ... well. Well in subversive you can, the problem is that when you do sync / merge changes before doing an update can take sooo much longer :-( Err, yes ? That's one of the trade-offs the SVN folks made when they were designing things... -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310789 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Please don't confuse the topic Tom, and twist what I am saying. Nobody is going to have a go at you for your SDLC, or how you deploy for the first time. My point is very simple, so let me spell it out for you again. When using export, that is not actually using SVN so it is not an issue in this conversation. I thought you of all people who has been around long enough, should have known that. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Tom Chiverton [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 11:54 PM To: CF-Talk Subject: Re: SVN in Production On Monday 11 Aug 2008, Andrew Scott wrote: of dev - QA - production and then at least, once made live if the changes Uh huh. We then use SVN make sure what was QA'ed and tested is exactly the same as what was deployed. Why is this bad ? approval, how do you migrate these changes? You certainly would not export the entire repository now would you? Err, no. What has one to do with the other ? -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. ~| 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:310791 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Don't put words into my mouth. I don't see anyone putting words into your mouth. Jochem simply mentioned that some people use revision control systems for things other than application source code. That is certainly true, even if you don't do that yourself. As for xml changes that are not related to your source code is generally handled by daily backups anyway, and most people prefer that as it can put the machine into a state quicker than your method. But hey thats your choice, you want to create extra work for you then go for it. The advantage of using revision control for server configuration files, etc, is that you can do diffs, etc, that you can't do as easily with a typical machine backup. But that's fairly obvious, isn't it? Personally, I would be very happy if server configuration files were generally treated this way, because I can't count the number of times I've found a file that's been changed from default settings, with no indication of when or why. As for the actual content of the source files, DID I EVER MENTION ANYTHING about that? NO, I did not and I wouldn't like to have you tell me otherwise. When reading email, it's very difficult to discern intent, attitude, or emotional state. So, I interpret your responses with the assumption that they're written for the best possible reasons, with positive intent. That said, I think that many readers here might find your responses unpleasant and off-putting. I mention this solely to let you know this, if you don't already know. Feel free to disregard it. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| 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:310792 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Brian... A statement like this means you are not very good at your job. There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. Brian, if you have been developing and using SVN heavily and making minor changes to websites as explained there is no way in hell I would employ you if you told me what you said below. As much as I am one who looks to reduce work load, file sync is and will always be a manual process when it comes to migrating small changes. Brian, you really should read your message again and seriously think about what you said. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 12:01 AM To: CF-Talk Subject: Re: SVN in Production I disagree completely. There's absolutely nothing wrong with using SVN in production for deployment. Beyond Compare? It's a great program...but using it to deploy code? The idea makes me shudder. In fact, doing anything manual related to code deployment makes me shudder. There are easy ways around the issue you bring up about size: it's called an SVN Export. It's meant to do EXACTLY what you're talking about: create a copy of the source code with no SVN-related files. All of this can (and should) be automated with ANT. That means at the click of my mouse I can execute the entire deployment process in exactly the same way every single time. That might mean: - Zip the current code, timestamp it, and copy it to a back folder for easy retrieval. - Delete the current code - Copy a site maintenance file into the site folder - Pull latest from SVN - Perform export to site folder - Run a reinit HTTP request to reload the application - Send an email to notify stakeholders of success You can also have it run unit tests and only deploy if all tests pass. The bottom line is that using SVN and ANT to help you deploy code is EXACTLY what these tools were meant to do. If I have to do anything more than click my mouse once to execute an entire deployment process, I'm doing something wrong. On Mon, Aug 11, 2008 at 4:20 AM, Andrew Scott [EMAIL PROTECTED]wrote: SVN SHOULD NEVER BE USED IN PRODUCTION... SVN is used to have a revision control system, so that you could roll back to a previous version or whatever you need to do. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. But then if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never and I will repeat this again. NEVER USE SVN in production. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. I am shocked to find people don't research their tools enough. So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn fool, and should be shot on sight. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 11:07 AM To: CF-Talk Subject: SVN in Production Hello, Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? -- Yours, Kym Kovan mbcomms ~| 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:310793 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
No it hasn't been mentioned But the reason I haven't mentioned it, is because the thread never started that way... As well as the fact that if you are not going through an approval stage of your changes, then they will automatically go live. That is not always ideal, sure is an option but is not ideal to about 98% of people. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: denstar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 7:36 AM To: CF-Talk Subject: Re: SVN in Production On Mon, Aug 11, 2008 at 5:25 AM, Kym Kovan wrote: . So our problem is how to push out changes to the Production boxes in a sensible fashion and hence our question that has raised such ire amongst one person at least :-) I haven't been watching this thread too close, but... SVN has something called repository hooks, which fire when certain actions occur. So when I get a commit action, my repo does some stuff... looks at what the thing was, where it was, etc., and the repo server does stuff based on that information. I use rsync, a tool designed specifically for keeping filesystems in sync, to push the changes to the places they need to go. It's fast, and only copes what's changed. This is not an uncommon setup, as you'll see if you research SVN deployment, but I offer it, in case it hasn't been mentioned in the thread already. And you can use those repository hooks to fire off unit-tests, or whatever else you need to do as part of your regiment. Great stuff! HIH -- For a man to conquer himself is the first and noblest of all victories. Plato ~| 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:310794 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Dave, Don't quote something out of context. I deliberately removed that before replying, so you assumed that I was talking about that now? I am well aware what SVN is, and anyone who has read the documentation would know that without a doubt now wouldn't they? Why is that Dave? Because the examples in the documentation relate to what you made an assumption on. If you want to be corrected, I actually referred to the files and their contents from SVN. I never brought that up. And yet it was referred to as if I had. As for your words of wisdom, taken on board. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 10:12 AM To: CF-Talk Subject: RE: SVN in Production Don't put words into my mouth. I don't see anyone putting words into your mouth. Jochem simply mentioned that some people use revision control systems for things other than application source code. That is certainly true, even if you don't do that yourself. As for xml changes that are not related to your source code is generally handled by daily backups anyway, and most people prefer that as it can put the machine into a state quicker than your method. But hey thats your choice, you want to create extra work for you then go for it. The advantage of using revision control for server configuration files, etc, is that you can do diffs, etc, that you can't do as easily with a typical machine backup. But that's fairly obvious, isn't it? Personally, I would be very happy if server configuration files were generally treated this way, because I can't count the number of times I've found a file that's been changed from default settings, with no indication of when or why. As for the actual content of the source files, DID I EVER MENTION ANYTHING about that? NO, I did not and I wouldn't like to have you tell me otherwise. When reading email, it's very difficult to discern intent, attitude, or emotional state. So, I interpret your responses with the assumption that they're written for the best possible reasons, with positive intent. That said, I think that many readers here might find your responses unpleasant and off-putting. I mention this solely to let you know this, if you don't already know. Feel free to disregard it. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| 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:310795 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
On Mon, Aug 11, 2008 at 6:09 PM, Andrew Scott wrote: Brian... A statement like this means you are not very good at your job. Hey, we're all learning and whatnot, Andrew, cut the man some slack! :-) There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. SVN really DOES automatically merge changes. That's one of the cool things about it (The Book[http://svnbook.red-bean.com/], is awesome!) Brian, if you have been developing and using SVN heavily and making minor changes to websites as explained there is no way in hell I would employ you if you told me what you said below. I think you are thinking in the box, as in, your way is the right way, when really, there are many ways. You actually don't seem to be taking advantage of some of the more rock'n aspects of SVN. As much as I am one who looks to reduce work load, file sync is and will always be a manual process when it comes to migrating small changes. Oy! I think, as Dave sorta said, it's those little incremental changes that are exactly the type of thing you'd want captured in some type of history, if you will. I *really* *really* love having our config files in SVN-- we can stand up a new server much much faster-- I do have a comment on /etc files, and how we do it, but I'll address that some[time|where] else. Well... anyways, guess that's it. -- DeN 3 Subclipse ~| 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:310796 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
I never said you would automatically handle merge changes. If you are merging, then you do that in the repository and tag the merged file set before you perform the deployment. That has nothing to do with deployment. You only deploy once the code has been properly merged, tagged, and tested. To anyone else interested in this topic, I would recommend that you look around for yourself by Googling ant deployment or svn deployment and look through the hundreds of thousands of results from a very wide range of authoritative sources. You'll quickly see that a great many people successfully leverage Subversion when deploying code. On Mon, Aug 11, 2008 at 8:09 PM, Andrew Scott [EMAIL PROTECTED]wrote: Brian... A statement like this means you are not very good at your job. There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. Brian, if you have been developing and using SVN heavily and making minor changes to websites as explained there is no way in hell I would employ you if you told me what you said below. As much as I am one who looks to reduce work load, file sync is and will always be a manual process when it comes to migrating small changes. Brian, you really should read your message again and seriously think about what you said. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 12:01 AM To: CF-Talk Subject: Re: SVN in Production I disagree completely. There's absolutely nothing wrong with using SVN in production for deployment. Beyond Compare? It's a great program...but using it to deploy code? The idea makes me shudder. In fact, doing anything manual related to code deployment makes me shudder. There are easy ways around the issue you bring up about size: it's called an SVN Export. It's meant to do EXACTLY what you're talking about: create a copy of the source code with no SVN-related files. All of this can (and should) be automated with ANT. That means at the click of my mouse I can execute the entire deployment process in exactly the same way every single time. That might mean: - Zip the current code, timestamp it, and copy it to a back folder for easy retrieval. - Delete the current code - Copy a site maintenance file into the site folder - Pull latest from SVN - Perform export to site folder - Run a reinit HTTP request to reload the application - Send an email to notify stakeholders of success You can also have it run unit tests and only deploy if all tests pass. The bottom line is that using SVN and ANT to help you deploy code is EXACTLY what these tools were meant to do. If I have to do anything more than click my mouse once to execute an entire deployment process, I'm doing something wrong. On Mon, Aug 11, 2008 at 4:20 AM, Andrew Scott [EMAIL PROTECTED]wrote: SVN SHOULD NEVER BE USED IN PRODUCTION... SVN is used to have a revision control system, so that you could roll back to a previous version or whatever you need to do. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. But then if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never and I will repeat this again. NEVER USE SVN in production. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. I am shocked to find people don't research their tools enough. So let me recap, DO NOT USE SVN IN PRODUCTION. If you do then your a damn fool, and should be shot on sight. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Monday, 11 August 2008 11:07 AM To: CF-Talk Subject: SVN in Production Hello, Looking at some of the responses in the recent thread on SVN v ftp I get an impression that some folk are using SVN clients on Production boxes. What are people's thoughts on this? Is it a security risk, is it dangerous in some other way, or is it a bad thing because of all of those extra files that cause havoc with backups? -- Yours, Kym Kovan mbcomms ~| 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
Re: SVN in Production
On Mon, Aug 11, 2008 at 5:56 PM, Andrew Scott wrote: Kym, Think of an Application has being something that more than one client could have. Then think about their requirements, and how it might differ to another client. I'm not sure if I should go into it, but-- You're doing it wrong. :) The scenarios you outline are common problems, and are actually some of the reasons source control is, where it is today. Check out svn:externals (you can pin these external revisions, which can be a key factor!), and *really* do yourself a favor, and learn about branches, and merging, and how SVN revisions and whatnot. Then sit down, and figure out a tagging strategy, as well as the lifecycle that fits your application, etc.(maybe not in that order;]), and get that stuff documented (and under version control! =]). Make sure you come up with a plan that addresses the issues you haven't addressed yet-- the issues which you blame on version control, but that are actually related to how you are doing things. You'll be in high spirits after that, man! You'll know, that even if a truck just plain takes you out at some random moment, your team will still be O.K. without you. Force be with you mate! den -- For a man to conquer himself is the first and noblest of all victories. Plato ~| 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:310798 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Don't quote something out of context. I deliberately removed that before replying, so you assumed that I was talking about that now? I am well aware what SVN is, and anyone who has read the documentation would know that without a doubt now wouldn't they? I don't see any reason to doubt you know what SVN is. You may well know it better than I do. But I didn't quote anything out of context. I simply replied to your response to Jochem, without referring to any other email in the thread. I apologize in advance for what will certainly be difficult to read, but here's Jochem's post to you: Andrew Scott wrote: What Do you mean by repo - server and server - repo? The latter should never be an issue, or even considered. Anyone who makes changes to production and not in a development environment shouod be hung out to dry or better still beaten with a stick until you realise that development is what it means. So you think the entire /etc/ folder on a production box is the same as an /etc/ folder on a development box? You think they have the same hostnames? The same IP addresses? The same firewall rules? That the test environment has a two year backup retention like production has? Not everybody uses SVN just for sourcecode. Some use it for their university thesis. Some for their grocery list. Some use SVN for complete server configurations. And what you use it for does influence the usage pattern. It is perfectly acceptable to change the -Dmail.host oarameter in your jvm.config file directly on production and then back it up to SVN. Once you have deployed to a production server, it should never have any ties with the repository in any way shape or form. If you are one of those that think this is ok, then you will need to adopt new procedures quickly. Before you adopt bad and I mean VERY BAD ideas. Generally speaking you don't want to have production running directly from a working copy. But there is nothing wrong with putting $Id$, $HeadURL$ etc. in your sources so that code and configuration files on the production box points back to a specific version of a file in a repository. Reading that, my interpretation is that you stated that copying from your production server to a repository was never acceptable. Jochem then presented a scenario where he believed it was acceptable. I tend to agree with him in this case, for what that's worth. You posted this in response: Don't put words into my mouth. As for xml changes that are not related to your source code is generally handled by daily backups anyway, and most people prefer that as it can put the machine into a state quicker than your method. But hey thats your choice, you want to create extra work for you then go for it. As for the actual content of the source files, DID I EVER MENTION ANYTHING about that? NO, I did not and I wouldn't like to have you tell me otherwise. Now, as I stated before, I don't see where he put any words in your mouth. You clearly state that it's unequivocally a VERY BAD idea to copy from a production server to a repository, and he says otherwise. Why is that Dave? Because the examples in the documentation relate to what you made an assumption on. If you want to be corrected, I actually referred to the files and their contents from SVN. I never brought that up. And yet it was referred to as if I had. Again, I don't see where he implies that you said anything about the contents of files. He says something about the contents of files, though, as a justification for having files on the production box point to specific copies in a repository. Clearly, that would be a tie with the repository, which you clearly stated would be a VERY BAD idea. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| 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:310799 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
On Mon, Aug 11, 2008 at 8:23 PM, denstar [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 6:09 PM, Andrew Scott wrote: Brian... A statement like this means you are not very good at your job. Hey, we're all learning and whatnot, Andrew, cut the man some slack! :-) Thanks Den. :-) But believe me, you don't have to defend me to Andrew. At all. There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. SVN really DOES automatically merge changes. That's one of the cool things about it (The Book[http://svnbook.red-bean.com/], is awesome!) I think we might be looking at different kinds of merging. What we're talking about here are cases where you have different branches of the code (say a development branch and a production branch), and you fix a set of bugs in development and you want to merge those changes back into the production branch without bringing over any of the other partially finished work from the development branch. This process is known as merging, and it does require care though it is not particularly difficult to do. The trick is that after you merge the changes into the production branch, that you then apply a tag to it, test it thoroughly, and then deploy the updated file set to production. Am I misunderstanding? Or were you referring to SVN's ability to merge changes from different developers who are working on a file at the same time? That process is actually called conflict resolution. I just wanted to make sure whether we're talking about the same thing. Thanks. ~| 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:310801 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
Sorry, Maybe I should have stated: Not even SVN can automatically decide what changes to make live and what not to make live, between developer changes As stated, if I have 2 changes one has to go live and the other is not ready. Another developer has made a change, but this change is also not ready to go into production. Can SVN decide to automatically decide what has to go live and what does not? -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: denstar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 10:23 AM To: CF-Talk Subject: Re: SVN in Production On Mon, Aug 11, 2008 at 6:09 PM, Andrew Scott wrote: Brian... A statement like this means you are not very good at your job. Hey, we're all learning and whatnot, Andrew, cut the man some slack! :-) There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. SVN really DOES automatically merge changes. That's one of the cool things about it (The Book[http://svnbook.red-bean.com/], is awesome!) Brian, if you have been developing and using SVN heavily and making minor changes to websites as explained there is no way in hell I would employ you if you told me what you said below. I think you are thinking in the box, as in, your way is the right way, when really, there are many ways. You actually don't seem to be taking advantage of some of the more rock'n aspects of SVN. As much as I am one who looks to reduce work load, file sync is and will always be a manual process when it comes to migrating small changes. Oy! I think, as Dave sorta said, it's those little incremental changes that are exactly the type of thing you'd want captured in some type of history, if you will. I *really* *really* love having our config files in SVN-- we can stand up a new server much much faster-- I do have a comment on /etc files, and how we do it, but I'll address that some[time|where] else. Well... anyways, guess that's it. -- DeN 3 Subclipse ~| 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:310803 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
On Mon, Aug 11, 2008 at 6:44 PM, Brian Kotek wrote: On Mon, Aug 11, 2008 at 8:23 PM, denstar wrote: Hey, we're all learning and whatnot, Andrew, cut the man some slack! :-) Thanks Den. :-) But believe me, you don't have to defend me to Andrew. At all. Oh, snap! =] Didn't mean to imply that, actually. Thinking it might be some type of pain referral for Andrew, if that makes sense. I meant we are all imperfect, and that's perfect, I guess. There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. SVN really DOES automatically merge changes. That's one of the cool things about it (The Book[http://svnbook.red-bean.com/], is awesome!) Am I misunderstanding? Or were you referring to SVN's ability to merge changes from different developers who are working on a file at the same time? That process is actually called conflict resolution. I just wanted to make sure whether we're talking about the same thing. Thanks. You nailed it with conflict resolution-- so long as there is no conflict, the merge (of updated code) is automatic, which is the automatic part I was referring to :-) (it's pretty smart, too!). So not merging branches, but merging updates, is what I think I was talking about. -- I think =] ~| 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:310804 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
On Mon, Aug 11, 2008 at 6:58 PM, Andrew Scott wrote: Not even SVN can automatically decide what changes to make live and what not to make live, between developer changes If you've got things organized the right way, it's pretty easy. You do need to make use of tags and revision numbers and whatnot tho. It's nice that 1.5 has some built-in merge tracking stuff now-- no more commenting it so you remember! As stated, if I have 2 changes one has to go live and the other is not ready. Another developer has made a change, but this change is also not ready to go into production. Can SVN decide to automatically decide what has to go live and what does not? It won't have to decide, if you've followed a pattern. Theoretically. =] -- Don't mean to come off as if I know something, as I know I don't know, ya know? ~| 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:310806 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
For FUCK sake. I never said anything about merging between SVN repositories. I fucking said merging code from dev - production, which has nothing to do with SVN what so ever that is my damn point. You bring automation into this, and I am fairly sure that I have been talking about using SVN in production. If I am as a developer, have made it very clear that not all my changes or even yours could end up in production. So how do you handle that? It has nothing to do with automation of any shape or form. I have been talking about deployment the entire time, WTF do you think I mean when I talk about merging fixes/changes from QA - PRODUCTION Did you think I had 2 repositories in SVN called QA and Production? Give me a break. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 10:34 AM To: CF-Talk Subject: Re: SVN in Production I never said you would automatically handle merge changes. If you are merging, then you do that in the repository and tag the merged file set before you perform the deployment. That has nothing to do with deployment. You only deploy once the code has been properly merged, tagged, and tested. To anyone else interested in this topic, I would recommend that you look around for yourself by Googling ant deployment or svn deployment and look through the hundreds of thousands of results from a very wide range of authoritative sources. You'll quickly see that a great many people successfully leverage Subversion when deploying code. On Mon, Aug 11, 2008 at 8:09 PM, Andrew Scott [EMAIL PROTECTED]wrote: Brian... A statement like this means you are not very good at your job. There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. Brian, if you have been developing and using SVN heavily and making minor changes to websites as explained there is no way in hell I would employ you if you told me what you said below. As much as I am one who looks to reduce work load, file sync is and will always be a manual process when it comes to migrating small changes. Brian, you really should read your message again and seriously think about what you said. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 12:01 AM To: CF-Talk Subject: Re: SVN in Production I disagree completely. There's absolutely nothing wrong with using SVN in production for deployment. Beyond Compare? It's a great program...but using it to deploy code? The idea makes me shudder. In fact, doing anything manual related to code deployment makes me shudder. There are easy ways around the issue you bring up about size: it's called an SVN Export. It's meant to do EXACTLY what you're talking about: create a copy of the source code with no SVN-related files. All of this can (and should) be automated with ANT. That means at the click of my mouse I can execute the entire deployment process in exactly the same way every single time. That might mean: - Zip the current code, timestamp it, and copy it to a back folder for easy retrieval. - Delete the current code - Copy a site maintenance file into the site folder - Pull latest from SVN - Perform export to site folder - Run a reinit HTTP request to reload the application - Send an email to notify stakeholders of success You can also have it run unit tests and only deploy if all tests pass. The bottom line is that using SVN and ANT to help you deploy code is EXACTLY what these tools were meant to do. If I have to do anything more than click my mouse once to execute an entire deployment process, I'm doing something wrong. On Mon, Aug 11, 2008 at 4:20 AM, Andrew Scott [EMAIL PROTECTED]wrote: SVN SHOULD NEVER BE USED IN PRODUCTION... SVN is used to have a revision control system, so that you could roll back to a previous version or whatever you need to do. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could result in 2gig and more of space that is no longer needed. But then if one read the docs to these tools, one would not use SVN in production. SVN can be expensive when it comes to hard drive space, and one should never and I will repeat this again. NEVER USE SVN in production. Use a program like beyond compare to syn file changes or something, but NEVER USE SVN in production. I am shocked to find people don't research their tools enough. So let me recap, DO NOT USE SVN
RE: SVN in Production
Is there any wonder, when you see an email like this one. If you are going to make a statement, make sure you have done your research into what has and is being said. DID you READ my EMAIL? Where I said to you exactly what you just said? Did you not hear me when I said, when I switch between SVN revisions I can make the change to one, and then merge that into another? Does that not indicate to you, that what you described was a waste of your time? -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: denstar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 10:35 AM To: CF-Talk Subject: Re: SVN in Production On Mon, Aug 11, 2008 at 5:56 PM, Andrew Scott wrote: Kym, Think of an Application has being something that more than one client could have. Then think about their requirements, and how it might differ to another client. . I'm not sure if I should go into it, but-- You're doing it wrong. :) The scenarios you outline are common problems, and are actually some of the reasons source control is, where it is today. Check out svn:externals (you can pin these external revisions, which can be a key factor!), and *really* do yourself a favor, and learn about branches, and merging, and how SVN revisions and whatnot. Then sit down, and figure out a tagging strategy, as well as the lifecycle that fits your application, etc.(maybe not in that order;]), and get that stuff documented (and under version control! =]). Make sure you come up with a plan that addresses the issues you haven't addressed yet-- the issues which you blame on version control, but that are actually related to how you are doing things. You'll be in high spirits after that, man! You'll know, that even if a truck just plain takes you out at some random moment, your team will still be O.K. without you. Force be with you mate! den -- For a man to conquer himself is the first and noblest of all victories. Plato ~| 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:310809 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Dave, Are you referring to his reference with the $ID as a reason why? I can export to any QA server, and then migrate that via any option available to me. But the contents of the file is not an issue, if you pull source out of SVN it is going to have that in the source code anyway. Or did I miss the reason you say you can see it? I don't see it, all I see is that of other things like docs. Never brought that up, so it's not an issue. The $ID and $url header info, has nothing to do with SVN as such. As once it is insereted into the file it is part of the file anyway, so whether it comes from svn or another directory it is going to have that information. Maybe I am not understanding you now. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Dave Watts [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 10:44 AM To: CF-Talk Subject: RE: SVN in Production Don't quote something out of context. I deliberately removed that before replying, so you assumed that I was talking about that now? I am well aware what SVN is, and anyone who has read the documentation would know that without a doubt now wouldn't they? I don't see any reason to doubt you know what SVN is. You may well know it better than I do. But I didn't quote anything out of context. I simply replied to your response to Jochem, without referring to any other email in the thread. I apologize in advance for what will certainly be difficult to read, but here's Jochem's post to you: Andrew Scott wrote: What Do you mean by repo - server and server - repo? The latter should never be an issue, or even considered. Anyone who makes changes to production and not in a development environment shouod be hung out to dry or better still beaten with a stick until you realise that development is what it means. So you think the entire /etc/ folder on a production box is the same as an /etc/ folder on a development box? You think they have the same hostnames? The same IP addresses? The same firewall rules? That the test environment has a two year backup retention like production has? Not everybody uses SVN just for sourcecode. Some use it for their university thesis. Some for their grocery list. Some use SVN for complete server configurations. And what you use it for does influence the usage pattern. It is perfectly acceptable to change the -Dmail.host oarameter in your jvm.config file directly on production and then back it up to SVN. Once you have deployed to a production server, it should never have any ties with the repository in any way shape or form. If you are one of those that think this is ok, then you will need to adopt new procedures quickly. Before you adopt bad and I mean VERY BAD ideas. Generally speaking you don't want to have production running directly from a working copy. But there is nothing wrong with putting $Id$, $HeadURL$ etc. in your sources so that code and configuration files on the production box points back to a specific version of a file in a repository. Reading that, my interpretation is that you stated that copying from your production server to a repository was never acceptable. Jochem then presented a scenario where he believed it was acceptable. I tend to agree with him in this case, for what that's worth. You posted this in response: Don't put words into my mouth. As for xml changes that are not related to your source code is generally handled by daily backups anyway, and most people prefer that as it can put the machine into a state quicker than your method. But hey thats your choice, you want to create extra work for you then go for it. As for the actual content of the source files, DID I EVER MENTION ANYTHING about that? NO, I did not and I wouldn't like to have you tell me otherwise. Now, as I stated before, I don't see where he put any words in your mouth. You clearly state that it's unequivocally a VERY BAD idea to copy from a production server to a repository, and he says otherwise. Why is that Dave? Because the examples in the documentation relate to what you made an assumption on. If you want to be corrected, I actually referred to the files and their contents from SVN. I never brought that up. And yet it was referred to as if I had. Again, I don't see where he implies that you said anything about the contents of files. He says something about the contents of files, though, as a justification for having files on the production box point to specific copies in a repository. Clearly, that would be a tie with the repository, which you clearly stated
Re: SVN in Production
Lighten up Andrew. You have been in attack mode from your first response. It is obvious you have strong opinions on the topic, but responding like you have been does nothing to educate the people here who may not have an opinion yet and are trying to learn something from these threads. Andrew Scott wrote: For FUCK sake. I never said anything about merging between SVN repositories. I fucking said merging code from dev - production, which has nothing to do with SVN what so ever that is my damn point. You bring automation into this, and I am fairly sure that I have been talking about using SVN in production. If I am as a developer, have made it very clear that not all my changes or even yours could end up in production. So how do you handle that? It has nothing to do with automation of any shape or form. I have been talking about deployment the entire time, WTF do you think I mean when I talk about merging fixes/changes from QA - PRODUCTION Did you think I had 2 repositories in SVN called QA and Production? Give me a break. ~| 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:310812 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
You have my curiosity now... Explain to me how, SVN automation is going to know that I have 4 changes and only 3 of these are going to need to go to production. Not that it is going to change for me, I need to log into a VPN and then map to the harddrive anyway. So this approach WILL not work for me, in our current line of clients. Like I said I am curious, I have one file and that file has the entire 4 changes. But I need to sit down and manually make the 3 changes to live. How does SVN automation decided this? I am aware of all the hooks etc., because we use it with our ticketing system. So that the tickets are automatically update, when SVN is updated. But to manage change management, I am very curious how you have achieved what it takes a human brain to decide. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: denstar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 11:03 AM To: CF-Talk Subject: Re: SVN in Production On Mon, Aug 11, 2008 at 6:58 PM, Andrew Scott wrote: . As stated, if I have 2 changes one has to go live and the other is not ready. Another developer has made a change, but this change is also not ready to go into production. Can SVN decide to automatically decide what has to go live and what does not? It won't have to decide, if you've followed a pattern. Theoretically. =] -- Don't mean to come off as if I know something, as I know I don't know, ya know? ~| 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:310813 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: SVN in Production
Maybe I am not understanding you now. At this point, perhaps neither of us is making much sense to the other right now. This is my signal to take the rest of the night off! Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ~| 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:310816 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew Scott wrote: You have my curiosity now... Explain to me how, SVN automation is going to know that I have 4 changes and only 3 of these are going to need to go to production. Andrew, I think the point being made is that if you have 4 changes they should be in 4 branches or something similar so you can merge into your production tag the ones you want and leave the rest. No mention of automation, just the way things are arranged. The way I understand what you describe of your workflow is that you do not do that, all the changes are in one branch and if so the problem is in your methodology/workflow arrangements in your place of work. Maybe I understand you wrongly. -- Yours, Kym Kovan mbcomms ~| 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:310817 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
Kym, Which is why I painted the scenario of this, and I will repeat it again because it seems to be getting lost in translation. The client has come to us and have asked for a number of changes to the system, over a period of time these changes are completed and placed into QA - UAT. Now the client is happy with 3 out of the 4 changes that you have made, and has requested that these changes go live straight away. But the 4th needs some more tweaking. Now I ask you again, how can automation decide which of those changes are required to be made live? Let's forget about branches and tags for now and concentrate on the above scenario, and the original question. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 12:10 PM To: CF-Talk Subject: Re: SVN in Production Andrew Scott wrote: You have my curiosity now... Explain to me how, SVN automation is going to know that I have 4 changes and only 3 of these are going to need to go to production. Andrew, I think the point being made is that if you have 4 changes they should be in 4 branches or something similar so you can merge into your production tag the ones you want and leave the rest. No mention of automation, just the way things are arranged. The way I understand what you describe of your workflow is that you do not do that, all the changes are in one branch and if so the problem is in your methodology/workflow arrangements in your place of work. Maybe I understand you wrongly. -- Yours, Kym Kovan mbcomms ~| 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:310818 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production - back to the original question
It seems I started something by asking if I was understanding some folk's practices correctly. Actually I just asked a question, someone else started something :^) Meanwhile I filled in a few details of an issue we have with this new client need with their monster site and in amongst all of the flames there was an answer or two that was useful so thank you for that. I was toying with the idea of doing an export from SVN to each production server but the code set is too big so I thought about doing a diff from the staging server to production but Jochem mentioned the risk of a corrupt file at the destination not getting picked up which is a legitimate concern. I was never considering in a month of Sundays doing file merges on the Production boxes or even using such a tool for deployment as was suggested by someone as that is what they do, the thought is too scary, when I mention diff I mean the directory/file difference tools not the file merge tools. One of those tools runs every day to keep a running backup of content on a backup file server and taking a peek at the logs it takes about 7 minutes to scan all 6.8GB of website across the network, much better than the 50-odd minutes done via FTP from here, and we are only 20mSec away! :-), hence my thoughts about doing the diff locally. One thing we currently do for the client is a twice a week backup of that mass of website down to a local server here in our second datacentre so we do have a copy of the production site right here next to the staging servers so now I am mulling over the possibility of doing the diffs locally and then only a few files need to be sent out for each update. I gather the client currently updates their site several times a week so we need to make the whole exercise as painless as possible. So the scenario would still be the A B send to C scenario that Jochem described but in this case B and C are synonymous. I find it interesting, we have been hosting CF for 11 years and still are finding new things to think over... -- Yours, Kym Kovan mbcomms ~| 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:310821 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Andrew Scott wrote: Kym, Which is why I painted the scenario of this, and I will repeat it again because it seems to be getting lost in translation. yes, yours Andrew. The original question came up because you stated that you could not send out 3 of 4 changes. In one of the many replies automation got mentioned but I avoided that in my response just now and took it back to the original point. The client has come to us and have asked for a number of changes to the system, over a period of time these changes are completed and placed into QA - UAT. Now the client is happy with 3 out of the 4 changes that you have made, and has requested that these changes go live straight away. But the 4th needs some more tweaking. I will repeat: Why are the 4 changes not in their own branches? Or if I get to the rub: why is your system so broken that you cannot manage something like that? No mention of automation just getting organised and doing it right in the first place. I am starting to get peeved Andrew and like others am signing off on this conversation with you unless you start responding to what was asked and not drop into defensive mode or push your own line to the detriment of other legitimate ones. I asked a question as I was surprised that I was reading that folk use SVN into production, ie have SVN clients on Production boxes. You responded rather strongly and war broke out. In amongst the dross thrown up by you, directly or indirectly, there were some good answers. I will mind them and ignore the rest. -- Yours, Kym Kovan mbcomms ~| 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:310822 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: SVN in Production
Anyone who is interested in learning how to better use Subversion, including its excellent capabilities for helping you deploy code, should check out Pragmatic Version Control Using Subversion by Mike Mason. It is a great overview and covers a lot of ground in a very easy to understand way. Regards, Brian On Mon, Aug 11, 2008 at 9:04 PM, Andrew Scott [EMAIL PROTECTED]wrote: For FUCK sake. I never said anything about merging between SVN repositories. I fucking said merging code from dev - production, which has nothing to do with SVN what so ever that is my damn point. You bring automation into this, and I am fairly sure that I have been talking about using SVN in production. If I am as a developer, have made it very clear that not all my changes or even yours could end up in production. So how do you handle that? It has nothing to do with automation of any shape or form. I have been talking about deployment the entire time, WTF do you think I mean when I talk about merging fixes/changes from QA - PRODUCTION Did you think I had 2 repositories in SVN called QA and Production? Give me a break. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 10:34 AM To: CF-Talk Subject: Re: SVN in Production I never said you would automatically handle merge changes. If you are merging, then you do that in the repository and tag the merged file set before you perform the deployment. That has nothing to do with deployment. You only deploy once the code has been properly merged, tagged, and tested. To anyone else interested in this topic, I would recommend that you look around for yourself by Googling ant deployment or svn deployment and look through the hundreds of thousands of results from a very wide range of authoritative sources. You'll quickly see that a great many people successfully leverage Subversion when deploying code. On Mon, Aug 11, 2008 at 8:09 PM, Andrew Scott [EMAIL PROTECTED]wrote: Brian... A statement like this means you are not very good at your job. There is no way to automatically merge changes, I mean even SVN can't do that between developers and its a manual process to update and merge changes. Brian, if you have been developing and using SVN heavily and making minor changes to websites as explained there is no way in hell I would employ you if you told me what you said below. As much as I am one who looks to reduce work load, file sync is and will always be a manual process when it comes to migrating small changes. Brian, you really should read your message again and seriously think about what you said. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Brian Kotek [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 12:01 AM To: CF-Talk Subject: Re: SVN in Production I disagree completely. There's absolutely nothing wrong with using SVN in production for deployment. Beyond Compare? It's a great program...but using it to deploy code? The idea makes me shudder. In fact, doing anything manual related to code deployment makes me shudder. There are easy ways around the issue you bring up about size: it's called an SVN Export. It's meant to do EXACTLY what you're talking about: create a copy of the source code with no SVN-related files. All of this can (and should) be automated with ANT. That means at the click of my mouse I can execute the entire deployment process in exactly the same way every single time. That might mean: - Zip the current code, timestamp it, and copy it to a back folder for easy retrieval. - Delete the current code - Copy a site maintenance file into the site folder - Pull latest from SVN - Perform export to site folder - Run a reinit HTTP request to reload the application - Send an email to notify stakeholders of success You can also have it run unit tests and only deploy if all tests pass. The bottom line is that using SVN and ANT to help you deploy code is EXACTLY what these tools were meant to do. If I have to do anything more than click my mouse once to execute an entire deployment process, I'm doing something wrong. On Mon, Aug 11, 2008 at 4:20 AM, Andrew Scott [EMAIL PROTECTED]wrote: SVN SHOULD NEVER BE USED IN PRODUCTION... SVN is used to have a revision control system, so that you could roll back to a previous version or whatever you need to do. When it comes to production, why the hell would you install 99% of extra space taking codes and indexes to a production server? Over a period of time, your code might be 1meg in size, but after a year the SVN indexes could
RE: SVN in Production
Kym, I answered your question. So what you are saying is that if I make 5 small text changes, and it was all requested in one ticket. You would make me branch ever one of those small changes? For what reason? Revision control system as what SVN is, is designed to be run in a specific way. The implementation of that way is then left up to the procedures in place, in our case we base our changes based on the task and quote. So what that means is that even though I made 5 small text changes as described above. It is actually one support request, so if we need to roll back because a mistake was made on either end we are not merging from 5 different branches. However, although it wasn't mentioned but I think you are implying that I should maybe branch the new live version. I didn't mention it, because it would go without saying that there would always be a new branch for that release version. Now if I have 5 different branches in the above example, and I need to then merge this as the final revision and build for that client. This way we can also track and locate when bugs may have been introduced and from where and what stage of the development, others may have different views. But I do not see the need of creating a branch, like this to introduce a more headache of branching. In small applications I could understand the thinking that people have, but the reality is that small is not always best to learn from either. The point I am making is that when you get to a stage or having just 3 clients running your base product, with each client also having different modules. These are certainly branched and tagged where necessary, then if we need to make those changes because they are core spelling mistakes. But it also only needs to affect 1 of the clients then we will again have to merge the code to each of these branches. That is not an issue, it works. But to then create these changes as seperate branches for each change is stupid, and ends up creating more work for you over the long run. Because instead of one branch, you need to merge n branches back to one, to then merge into some of the others. I thought that if you read between the lines, when I mentioned I switch branches would be clue enough that I follow the reccomendations that the SVN book / manual describes. It doesn't go into detail as to how deep you need to go into branching and I believe that the minimal the better. -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: Kym Kovan [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 12:52 PM To: CF-Talk Subject: Re: SVN in Production Andrew Scott wrote: Kym, Which is why I painted the scenario of this, and I will repeat it again because it seems to be getting lost in translation. yes, yours Andrew. The original question came up because you stated that you could not send out 3 of 4 changes. In one of the many replies automation got mentioned but I avoided that in my response just now and took it back to the original point. The client has come to us and have asked for a number of changes to the system, over a period of time these changes are completed and placed into QA - UAT. Now the client is happy with 3 out of the 4 changes that you have made, and has requested that these changes go live straight away. But the 4th needs some more tweaking. I will repeat: Why are the 4 changes not in their own branches? Or if I get to the rub: why is your system so broken that you cannot manage something like that? No mention of automation just getting organised and doing it right in the first place. I am starting to get peeved Andrew and like others am signing off on this conversation with you unless you start responding to what was asked and not drop into defensive mode or push your own line to the detriment of other legitimate ones. I asked a question as I was surprised that I was reading that folk use SVN into production, ie have SVN clients on Production boxes. You responded rather strongly and war broke out. In amongst the dross thrown up by you, directly or indirectly, there were some good answers. I will mind them and ignore the rest. -- Yours, Kym Kovan mbcomms ~| 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:310830 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production
On Mon, Aug 11, 2008 at 7:27 PM, Andrew Scott wrote: You have my curiosity now... Explain to me how, SVN automation is going to know that I have 4 changes and only 3 of these are going to need to go to production. Kym pretty much explained what I was getting at, changing your style. There's a saying, commit early, commit often'. Some systems make certain aspects easier-- Git is great for open open source, for instance, while SVN is better for a more centralized approach. At least that's my current take on it. :-) My point being, there are various ways to tackle problems, depending on the goals and parameters and whatnot. And that tools are WICKED COOL, plain and simple. All tools, really. I'm a sucker for stuff that builds stuff. :-) Not that it is going to change for me, I need to log into a VPN and then map to the harddrive anyway. So this approach WILL not work for me, in our current line of clients. Ah. I've been really happy with rsync. You can do it over SSH (there's a java server, if you're on windows), and if you're really worried about leaving ports open or something, you could rock some port knocking, which keeps 'em closed unless you use the secret knock. That, layered with some locked-down permissions and whatnot, is pretty pimp. Mmmm mmm good! Or at least it sounds like fun to set up. ;] Anyways, I shouldn't have implied (heh) that you're doing it wrong, as perhaps you're doing the best for your environment, you know? It's pretty easy to make assumptions about things based on what information we have-- hell, it's what we do. -- For a man to conquer himself is the first and noblest of all victories. Plato ~| 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:310834 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Re: SVN in Production - back to the original question
With gigs of data, and it's possible, something incremental seems like a good idea. A nice bit about SVN (and some other version control systems) is the binary difference stuff, so only the changes are transmitted, not the entire file. Sweet for large data files, neh? I'm thinking a nice setup would be a ANT managed build process that triggers some unit tests, which trigger an svnant tag/branch, which triggers the deployment to the appropriate places. Yes, something like that sounds dandy, personally. One of many, many ways to do it, but it sounds like fun. Know, that a lot of this stuff I talk about, I probably practice about-- well, not as much. I'm a hypocrite, truth be known. Piecemeal is all I can manage. Add a build file for this project here, a customized repository hook there... *Totally* unrelated, but there is a plugin for Thunderbird that does a colored diff compare of a diff file (there's an example perl hook for subversion that will email you the diff when a commit is made), which is pretty super. On Mon, Aug 11, 2008 at 8:39 PM, Kym Kovan [EMAIL PROTECTED] wrote: I find it interesting, we have been hosting CF for 11 years and still are finding new things to think over... I lovesiz it! :-) -- For a man to conquer himself is the first and noblest of all victories. Plato ~| 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:310835 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
RE: SVN in Production
:-( Yes, I understand about commit early and commit often. But I don't see how that solves the problem? That really has nothing to do with branches, though does it? -- Senior Coldfusion Developer Aegeon Pty. Ltd. www.aegeon.com.au Phone: +613 9015 8628 Mobile: 0404 998 273 -Original Message- From: denstar [mailto:[EMAIL PROTECTED] Sent: Tuesday, 12 August 2008 2:29 PM To: CF-Talk Subject: Re: SVN in Production On Mon, Aug 11, 2008 at 7:27 PM, Andrew Scott wrote: You have my curiosity now... Explain to me how, SVN automation is going to know that I have 4 changes and only 3 of these are going to need to go to production. Kym pretty much explained what I was getting at, changing your style. There's a saying, commit early, commit often'. Some systems make certain aspects easier-- Git is great for open open source, for instance, while SVN is better for a more centralized approach. At least that's my current take on it. :-) My point being, there are various ways to tackle problems, depending on the goals and parameters and whatnot. And that tools are WICKED COOL, plain and simple. All tools, really. I'm a sucker for stuff that builds stuff. :-) Not that it is going to change for me, I need to log into a VPN and then map to the harddrive anyway. So this approach WILL not work for me, in our current line of clients. Ah. I've been really happy with rsync. You can do it over SSH (there's a java server, if you're on windows), and if you're really worried about leaving ports open or something, you could rock some port knocking, which keeps 'em closed unless you use the secret knock. That, layered with some locked-down permissions and whatnot, is pretty pimp. Mmmm mmm good! Or at least it sounds like fun to set up. ;] Anyways, I shouldn't have implied (heh) that you're doing it wrong, as perhaps you're doing the best for your environment, you know? It's pretty easy to make assumptions about things based on what information we have-- hell, it's what we do. -- For a man to conquer himself is the first and noblest of all victories. Plato ~| 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:310837 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
