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

Reply via email to