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

You need to delete those SVN dir's with a script. ----- Excess quoted text cut - see Original Post for more -----

>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.

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

clear statement, I'll use that in my meeting with the boss :) ----- Excess quoted text cut - see Original Post for more -----

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 :) ----- Excess quoted text cut - see Original Post for more ----- 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 ----- Excess quoted text cut - see Original Post for more -----

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. ----- Excess quoted text cut - see Original Post for more -----

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. 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. ----- Excess quoted text cut - see Original Post for more ----- 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 ----- Excess quoted text cut - see Original Post for more ----- is ----- Excess quoted text cut - see Original Post for more -----

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 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. ----- Excess quoted text cut - see Original Post for more ----- 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 ----- Excess quoted text cut - see Original Post for more ----- is ----- Excess quoted text cut - see Original Post for more -----

> 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.

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 > 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.

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

> 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.

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 > 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.

> 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.

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 > 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.

> 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.

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 > 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