Version control systems have a reputation, at least in my mind, for being complicated, difficult to manage, difficult to implement, difficult to use, the list of difficulties goes on! So why on earth would I want to implement this stuff?
One of the most frustrating parts of development for me has always been the risk of breaking something, and spending hours rolling back and sometimes not be able to completely roll back. Then you have to restore from backup, and lose hours or even days of work - because at some junction in the development design I took the wrong turn for whatever reason (I'm sure I'm the only one who ever does that;). Then I find that I ended up on a dead end street going nowhere.
A well implemented and well functioning version control system can completely eliminate this risk. It will allow you to go digging into whatever blind alley of programming that you want, and make sure that you can come back to the real world without a scratch.
Many developers look at version control as being only for developer teams, where more than one developer is working on the same piece of program at the same time. While most good version control systems support exactly that, that is not their primary goal. Their primary goal is to make sure that you can, without risk, save your work and create copies of your work and roll back to any revision that you want, without losing anything. They enable you to pull out a two year old source file to check something, or pull out a whole system from last year, compile it and run it to see how your project looked a hundred builds back.
I currently have 20 products that I'm putting into version control (no, I didn't quite finish getting them all set up over the weekend). That is a total of 25,627 files in 2,599 folders! They include all the current Icetips products, some old products that I have not worked on for quite some time, and some new ones that are in development. I also have some in-house projects in there, too, that I work on from time to time and want to have the freedom to experiment on. With the safety net of version control, I am protected from myself. 😉
That is exactly what version control is about for me: Freedom to experiment without risk. Version control allows me to commit my project, create a branch and experiment on that branch. Note that Subversion/TortoiseSVN uses the term "commit" for saving the local files to the repository, which is the database with all the projects and all the revisions of the projects. Other version control systems also use the term "check in" about committing changes to the repository.
For example, I have been experimenting with some code for our OutlookBar. To do that, I make sure that my OutlookBar product folder is committed to the repository and then I right click on it and select "TortoiseSVN | Branch/Tag..." What this does is make a copy of my current project into a "branch". See the screen shot above.
I think a small tutorial on terminology is in order before I go any further. From the start you will hear references to Trunk, Branches and Tags. It took me a while to figure out what those things were and how they worked. Not necessarily because it was complicated, but just about every reference to those terms that I found did not explain them at all or did not explain if they are something that you create or the version control system should create for you.
The Trunk, Branches and Tags are simply folders inside the version control that make it easier to deal with versioning. If you are using Subversion/TortoiseSVN, it is up to you to create those folders in the root of the repository. See the screen shot above with the structures I have now set up for Build Automator. I have not created any Tags or Branches yet, so those folders are empty. When you create the repository, you should create those 3 folders.
The Trunk folder is where your current development version resides. This is what will become your next public release. This is where you copy files from to tags and branches.
The Branch folder is where you create branches of the trunk to work on without disturbing your trunk. This is where you create your experimental code, try things out, play like a pig in a pool of mud, do what ever you want to do without risking your precious code in the trunk! You simply copy your trunk there by using the "TortoiseSVN | Branch/Tag..." menu option. Use a descriptive name, like "Testing sub-classing in WindowsClass" for the branch.
The Tags folder is for your builds when they are done. Once you create a new build (hopefully using Build Automator and SetupBuilder:)) this is where you copy your trunk using the "TortoiseSVN | Branch/Tag..." menu option. Just like for the branches, you just pick the Tags folder instead of the Branches. As with the branches you should use a descriptive name for your tags, like "Build 1.2.1234, 2010-08-23" for a tag to give a good indication of what it is.
So in essence the tags are what you had, the trunk is what you have and the branches are what you will have! Actually pretty simple when you think about it! Once you have created the branch, you check it out to your working folder and work with it and commit to it. When you are done with your experiments, and if everything has gone well and you are satisfied that your new code is good, you can then merge your changes back to your trunk or basically copy the branch back to the trunk.
TortoiseSVN provides merge tools that can merge code for you and show you differences between files. It cannot merge binary files, so you cannot merge Clarion app files. To work with Clarion apps, you must work with TXA files and export them and import them to Clarion. For what I need, I'm not going that far at this time (I probably will sooner than later, though). For more information about how to deal with TXA and version control I strongly suggest you watch Rick Martin's webinars from Clarion Live. See my first blog about the version control for links to the webinars.
I will be away for most of this week and will resume my blog on Friday, August 27. Tomorrow I am going to Redmond for a .NET user group meeting where they will be demonstrating the new Microsoft LightSwitch - and the LightSwitch project manager will be there. Tuesday through Thursday the whole clan is going camping for the first time! For those of you who like photos and don't follow me on Facebook, please take a look at my online photos at http://arnor.zenfolio.com/ I will post some photos there when I get back!
Arnor Baldvinsson
