Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!weretis.net!feeder4.news.weretis.net!news.teledata-fn.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Content-Type: text/plain; charset="UTF-8" Message-ID: <1972622.Wd2QAAWABF@PointedEars.de> From: Thomas 'PointedEars' Lahn Reply-To: Thomas 'PointedEars' Lahn Organization: PointedEars Software (PES) Date: Wed, 27 Mar 2013 09:08:29 +0100 User-Agent: KNode/4.8.5 Content-Transfer-Encoding: 8Bit X-Face: %i>XG-yXR'\"2P/C_aO%~;2o~?g0pPKmbOw^=NT`tprDEf++D.m7"}HW6.#=U:?2GGctkL,f89@H46O$ASoW&?s}.k+&. <3bednVqnL5qAhc_MnZ2dnUVZ_q6dnZ2d@supernews.com> MIME-Version: 1.0 Lines: 39 NNTP-Posting-Date: 27 Mar 2013 09:09:05 CET NNTP-Posting-Host: 050ae3e7.newsspool4.arcor-online.net X-Trace: DXC=@GgQ`\MA6 Cal Dershowitz wrote: >> I have simple questions at this point: how do you try something new on >> your server without stomping all over the last thing that worked? > > Let's say the page you want to work on is named ORIGINAL.PHP. You > make a copy of that file and you call it something like > ORIGINAL.PHP.BAK. Then you work on ORIGINAL.PHP. If you need more > copies og that original, you can append a date or a letter or whatever > after BAK to differentiate them. Or you are a *responsible* *professional* Web developer. Then you would use a local (private) Web server with a sufficiently similar setup on which you test changes before you upload to the remote (public) one. You would not upload files directly, but commit to a project repository of a version control system (like SVN or git) allowing you to roll back the remote version to a working state at any time should it turn out that – then unlikely – something did not work remotely that did work locally. You would keep your commits atomic (changes that belong together go into the same commit) and write commit comments so you would know what you changed and where you changed it (and, if you are in a team, who made the change), removing the need for a host of almost-duplicate files on the server that only you know about (and have to reverse-engineer with manual diff what you changed and why you changed it back then; and, if you are in a team, who changed it). HTH PointedEars -- Sometimes, what you learn is wrong. If those wrong ideas are close to the root of the knowledge tree you build on a particular subject, pruning the bad branches can sometimes cause the whole tree to collapse. -- Mike Duffy in cljs,