When working on a set of scripts without any smart development/version-control environment/cycle, you still want to keep some form of history of your code so you can always roll back to previous versions in case you mess up your current/development/unstable versions. Here I describe what I do. So far it has worked for me great. And if github is not an option for your project, give my approach a go.
Say I have been working on a script timestamper.py and I get to the stage when the script is working but I want to make some improvements, clean the code, and what not. Situations like this usually occur several times before a script can be considered finished.
Some people would make a new copy, called it something like timestamper_v2.py, and continued working on the copy. However, scripts are often used in groups so you would also need to find and replace “timestamper.py” with “timestamper_v2.py” in all files that reference the script. Further more, you can easily end up with tipestamper_v2.py that requires for for example “myfunctions_v45.py”. Soon you will go cross-eyed. Incrementing version number can be impractical.
I normally make a copy, but continue working on the original file. I got used to calling the copy according to the following pattern:
So in my example with timestamper.py, I may end up with a bunch of files like:
You can type the expired stamp by hand but that can get a bit tedious and error prone. Instead, if you have Python installed, you can use my Time Stamper utility that will give you access to the current time stamp in your clip board with a click of a button. If you don’t have Python installed, install Python! If you keep this utility open, making copies with the right name is a matter of seconds.
Note that this is not a backup mechanism, just version control. So read my note about backups too.
Obviously this approach can be extended for other types of files, not just code. Note that this works great if you are working on a more or less live system until you reach some “major release” you want to give to the customer/public. In that case, incrementing version numbers may be more suitable.