The right and the wrong way to keep track of file versions

Best Coding Practices Blog

The right way is simple, effective, transparent. The wrong way is messy, dangerous, and miserable to work around


Date : 2012-05-18
In the last few years I've worked with a lot of different developers from around the world. I've noticed some very clear regional differences in methods and priorities when it comes to developing code. I'm sure a lot of that has to do with the local training methods. I've also found a general willingness to learn that is comforting. One of the particularly bad habits that I have to talk about today is the Renamed Backup file. Let me just say from the start that code backups absolutely need to be done and there are easily hundreds of safe, effective means for doing these backups. My favorite being a well setup Version Control System. The renamed backup file, however, is a horrible mess to deal with and is a security risk. Let me show you what I mean. Below is a hypothetical root directory listing on website as it was when the site was first create, it's clean, it's safe:
Code:
.htaccess
favicon.ico
gdform.php
index.php
php.ini
webformmailer.php
welcome.html


Next I'll show you what it looks like after a few months of updates:
Code:
.htaccess
.htaccess – 2.13.12
.htaccess – 3.1.12
.htaccess – added new pw 3.4.12
favicon.ico
gdform.php
index – 4.23.12.php
index – added new footer 1.14.12.php
index – before update 2.8.12.php
index – removed side links 1.12.12.php
index.php
missing.html
php.ini
php.ini – original
php.ini – 2.1.12
webformmailer.php
welcome.html

Do you see the security risks in the above listing? Hopefully you're not looking at that thinking “That's a great way to make quick backups while editing files”. Do not do this.
Think of the debug output and other tricks that could be saved in some of those backup files that was for your eyes only. Do you really want to leave those test files where someone could accidentally find them at some point in the future? All you would need is one person testing using a browser bar that stores browsed pages and sends them off to google or alexa and eventually a spider is going to crawl through those pages. What if you have database cleanup operations stored in there and a spider triggers them? For security and site safety keep your directory listings clean.

The best method for developing new features for a live website is with a separate development site. That being said there are times when this just isn't possible. The next best method would be to set a directory aside for development, password protect it, and place all your test and development code in there. When some new feature is ready to be taken live you can make a backup copy of the original code in another directory and then write over the one and only version of that file in the live directory so there is still only one index.php. I keep original copies of files while taking a new feature live on my development box, they are not even on the server. Once the new feature is tested live I remove the local copy in case I ever see a copy of a file during a process and think I've already backed up my original.

What about backing up your full code base? Setup something automatic so you can forget about it. Many FTP programs will allow a scheduled download. I have them done weekly and the date of the download appended to the directory name. You wont know you need it until you need it and then you'll be able to go back through and find the exact code you need to reproduce. These directions are for sites that are not connected to any kind of version management or revision control system. If you have the ability to setup a CVS for the site you're working on that is definitely the way to go. I know from experience that there are a lot of websites being worked on every day that have no such service available.

Comments :

No comments yet
  • Search For Articles