Archiving Old Code after Major Updates
After making major changes to a web page what do you do with the previous version? The old code could be tossed in the trash since it's unlikely to be needed again. However, there may be a time where someone discovers a critical bug that slipped through the cracks. Until fixed, it may be better to revert back to a fully-functional version. With that in mind, let's take a look at archiving.
Background
If we don't use a fancy CMS (Content Management Systems) that maintains a revision history, managing the archive is our responsibility. This may sound like a daunting task, but once a process is established, it's not so bad. Of course, the magnitude of the archive is dependent on factors like the size of the website, the frequency of updates, and what's considered "worthy" for the archive. If files are archived every time a typo is corrected, for example, things might get a little unwieldy. But if we only archive code when structural changes are made, such as using a database instead of hard-coding the information…that's more manageable.
Archive Structure
We could just throw files to be archive into a folder and be done with it. But as more files are added, it gets difficult figuring out what's what. Instead, if we edited the index.php file in our website's "about" folder, the old file could be saved to an "about" folder in the archive. Utilizing the same structure for the archive and website will make locating files easier.
File Names
Another thing to consider is that the index.php file under the "about" folder may be edited again. So we'll end up with multiple index.php files in the archive. The additional files could be renamed to index2.php, index3.php, etc. But if we're ever looking for something specific in the archives, it's going to be difficult knowing what's inside the files without opening them. So let's provide some hints.
When archiving files, notes can be made within the file name. For example, a date the file was archived could be added along with a quick description of what changed. Instead of "index.php", the file might be renamed to "index (2011-11-07 before using a database to display staff info).php". The date, formatted as YYYY-MM-DD, is mostly used so that the file name sorts chronologically. The description would be whatever's necessary to indicate which version the file is.
4 Comments
Very nice! And thanks for the image; it helps eliminate any doubt I may have had otherwise. There have been too many times that I've heard of a promising feature only to discover we (not you and me) weren’t talking about the same thing.
In Git and I believe SVN, when you "commit" your changes i.e. update your codebase with a new version, you are able to leave a message explaining what changes you have made to the code, plus it automatically lets you see the differences between the current and previous version of code.
Here is an example one: http://imageshack.us/photo/my-images/254/gitf.png/
Those are some great ideas! I've been toying around with adding a readme file which describes the various changes the pages go through. I really like your idea of zipping the files along with the readme.
Do you know if Git (or any other DVCS that you've used) lets you annotate the archived files?
Well if you did decide to keep older versions of code, which is the better option I think there are other routes you could go down which might be a bit cleaner.
1) DVCS, use something like Git, SVN etc which always lets you roll back your code to previous versions as well as letting you see what the changes that you actually made where.
2)Zipping previous versions are always a good alternative. You can date the zip file and place a readme inside the archive for future reference and mention all of the changes in there. Bonus to this is that you do not need to learn anything new!
Leave a Comment