File Organization & Version Control [part 5]: Daily Use

[previously - part 4, part 3, part 2, part 1]

Last time we got TortoiseSVN installed on two machines and we set up our SVN repository on a memory stick (or perhaps a server). Now we'll look at how to use TortoiseSVN as part of our everyday, SketchUp workflow. I promised that integrating version control into our workflow would not impact our model development but there are a few basics that you must learn and use. This description is not meant to replace TortoiseSVN's own documentation "Daily Use" but describes how I use TortoiseSVN in real life.

Let's assume that I did some work at home last night and when I get into my office I want to sync my office PC so it has the changes I made at home on it. I plug in the USB memory stick and I navigate to the file structure on my local PC using windows explorer - the power of the Tortoise user interface is that it is totally integrated into the familiar windows file explorer. How does it achieve this? The version control status of your files and directories is represented by a set of icons and all actions you can perform are executed via context menus (right click). In practice this means that when we navigate to the subversion controlled directory on our work PC we will see an icon showing that something has been 'modified' in the repository and our local copy is out of date. At this point we could just update and resolve these changes in our whole local SketchUp file structure or we can drill down further and resolve a specific file. As we drill down directories and files that have now updates will be easily identifiable from those that have changes via augmented explorer icons. To update either a specific file, directory or whole tree we simply right click on the item we wish to resolve and use the menu options TortoiseSVN > Update. A tortoiseSVN window will then pop up reporting what files have been updated.

Once we have ensured that our local copy reflects the current state of the files in the repository we are ready to get to work. If you are working in a multi-user setup with the repository hosted on a file server, we would lock the files we wanted to work on. This would prevent anyone else from working on the file we are working on and so avoids file conflicts. In the programing world we are usually working on ASCII (text) files and SVN is smart enough to be able to merge changes if to people work on the same file at the same time. Unfortunately SketchUp model files do not currently have this kind of functionality in SVN so, in a team setting, you would want to 'exclusively lock' a file before you began changes on it.

When you are working solo you could lock a file too - it would help you to stop different file versions from different machines over writing each other. In reality I don't find it very useful - in practice I edit a model and check it back into SVN when I am about to change location (work to home or visa versa), just before I put the memory stick and repository into my pocket.

When you work on a model you will notice the icon in the file browser indicates that the file is changed from the repository version as soon as you save any changes to the file. As I said, I keep making changes to the file and then I check it back into the repository before I leave the office. You commit your changes to the repository by right clicking on the file you have been working on and selecting SVN Commit. At this point a dialog window is displayed allowing you to add a text message describing the changes you have made to the file. You don't have to write anything but you really should just write a one sentence on what you have done since the last time the file was checked out. In the coding world we can 'diff' text style files to find out what changed but we have to really on these hand written messages to describe the changes applied to a model.

Once you've checked your models into SVN you are ready to eject the memory stick and go home (don't just pull it out of the port - disconnect your hardware properly). At home, you sync up your home machine to repository as you did for your work machine. Again you check in your changes when you are done and rinse and repeat.

Hopefully you can see how this keeps two or more machines in step with each other so both are always at the same high-water mark but other cool features does this provide? We said that the repository contains every version of every file that you've every checked in so how can you utilize that? Say you're working on a big, long-term project and you want to see how your model looked 6 months ago before the spec changed. If you right click on a file and select TortoiseSVN > Show Log you will be shown a list of all the versions of your model. You can select any version of the file and open it - it will open 'read only' allowing you to see the old model but you can save a copy off somewhere safe if you need it. If you get to the end of a day (or a bad week) and realize that all the changes you have made have corrupted the model or messed something else up you can revert back to a previous good version. I won't document the specifics of all these features, but be aware that these facilities are there, and refer to the TortoiseSVN documentantion when you need to utilize them.

So there you have it - the basic work flow is to check your instance is up to date at the beginning of the working day and to check in your changes at the end. To me it seems like a minimum inconvenience for maximum peace of mind - if you agree I hope you will start using TortoiseSVN, if you don't at least you now know what you're missing and I thank you for making it through this whole tutorial.

[previously - part 4, part 3, part 2, part 1]