Version Control
So I've inherited the task at work to implement some type of version control for our PLC code. I won't go into too much geeky detail, but damn, this shit is really fucking cool how it works. I know, I know, I'm way behind the times in this respect, but that doesn't stop me from being completely mindblown at the possibilities.
I picked up TortoiseSVN, and I haven't looked back. Basically this allows you to keep a central database of files (local or remote), and allows you to make changes to the files. The server keeps track of all the different users editing the files so if someone decides to fuck something up, they're not going to get away with it. It also keeps backups of EVERY SINGLE change that has ever happened and you are able to revert back at any point that you want to. At first I thought, "Damn, that must REALLY eat up the hard drive space, making copies of everything". Then I did some investigation and realized that it only keeps the information needed to revert back. Seems pretty intuitive right?
So lets say you have this huge 500MB zip file containing a bunch of random files. You can take a file out of the archive, edit whatever you want, etc., and commit the changes to the repository. Generally you'd have to make a backup of the original AND create a whole new zip file even for the smallest of changes, thus doubling the amount of space needed with each change. Apparently Subversion can detect what's the same and whats different, even in a zip file, and only add the necessary bytes to implement the changes. So to hold the new version AND the old version (and probably many other older versions as well), you're looking at slightly over 500MB depending on the amount of changes made. Mind blown. (sad right?)
Yet another feature of this type of version control is the aspect of merging. Usually, if you want to edit a file, you have to 'lock' it, download the file, edit the file, then upload and unlock the file. This way, no one else can edit the file while you're messing around with it. Usually what happens is someone will lock the file, and then go on vacation or something stupid like that. Everyone is fucked at this point. With merging, you don't need to lock the file. User A can edit the file edit the file while user B edits the file at the same time. User A will commit the changes and when user B commits the changes, as long as they changes weren't in the same part of the file, then everything is fine. Unfortunately this only works with ASCII files. If the file happens to be a binary file, Subversion will alert you that someone has made changes to the file since you downloaded it and won't let you overwrite their changes. Keeps people from stepping one eachother's toes. Might be a pain in the ass to see what changes were made and reupload, but it sure beats overwriting inadventantly.
The interesting thing about the program as a whole is that it's a windows shell extension so everything is very well integrated and intuitive. The client is also extremely lightweight as well (<20MB). It's free too? WTF?
It's too bad I don't do anything important enough at home to really put this to any use...
(After linking up my post with the appropriate informational links, I've come to the conclusion that I have a lot to learn yet, haha)
I picked up TortoiseSVN, and I haven't looked back. Basically this allows you to keep a central database of files (local or remote), and allows you to make changes to the files. The server keeps track of all the different users editing the files so if someone decides to fuck something up, they're not going to get away with it. It also keeps backups of EVERY SINGLE change that has ever happened and you are able to revert back at any point that you want to. At first I thought, "Damn, that must REALLY eat up the hard drive space, making copies of everything". Then I did some investigation and realized that it only keeps the information needed to revert back. Seems pretty intuitive right?
So lets say you have this huge 500MB zip file containing a bunch of random files. You can take a file out of the archive, edit whatever you want, etc., and commit the changes to the repository. Generally you'd have to make a backup of the original AND create a whole new zip file even for the smallest of changes, thus doubling the amount of space needed with each change. Apparently Subversion can detect what's the same and whats different, even in a zip file, and only add the necessary bytes to implement the changes. So to hold the new version AND the old version (and probably many other older versions as well), you're looking at slightly over 500MB depending on the amount of changes made. Mind blown. (sad right?)
Yet another feature of this type of version control is the aspect of merging. Usually, if you want to edit a file, you have to 'lock' it, download the file, edit the file, then upload and unlock the file. This way, no one else can edit the file while you're messing around with it. Usually what happens is someone will lock the file, and then go on vacation or something stupid like that. Everyone is fucked at this point. With merging, you don't need to lock the file. User A can edit the file edit the file while user B edits the file at the same time. User A will commit the changes and when user B commits the changes, as long as they changes weren't in the same part of the file, then everything is fine. Unfortunately this only works with ASCII files. If the file happens to be a binary file, Subversion will alert you that someone has made changes to the file since you downloaded it and won't let you overwrite their changes. Keeps people from stepping one eachother's toes. Might be a pain in the ass to see what changes were made and reupload, but it sure beats overwriting inadventantly.
The interesting thing about the program as a whole is that it's a windows shell extension so everything is very well integrated and intuitive. The client is also extremely lightweight as well (<20MB). It's free too? WTF?
It's too bad I don't do anything important enough at home to really put this to any use...
(After linking up my post with the appropriate informational links, I've come to the conclusion that I have a lot to learn yet, haha)
Posted at
9:03 PM
0 Comments
