After 25 years of working with computers and programming I really should know that things rarely, if ever, take the time that looks reasonable! No such luck, I still haven't got it;)
I started the day by sleeping in! Figured I might as well give my brain some rest before digging deep into version control. It was nice, but in the end I'm not sure it helped much!;)
I decided to start by installing VisualSVN Server on the machine where I have the SVN server installed. It told me that it would install Apache, so I stopped it and made a copy of my Apache install and created a restore point in case it messed up my existing Apache install. Ran the install and it went through without any problems and I choose all the default settings. I was able to access my repository without any problems and everything looked very good.
I added a user, very originally called "Arnor" and life was good. That is until I ran TortoiseSVN and tried to create a folder in one of my repositories and got an error about not having access to do that. I checked the user authentication files that TortoiseSVN creates and realized that VisualSVN was not touching those files at all and whatever VisualSVN was doing, TortoiseSVN was completely ignoring. After some head scratching I found that VisualSVN was creating the user files in the root of the repository (see screenshot above) and they did not look like they even had the same format as the TortoiseSVN files in the "conf" folder under each repository, see screenshot below.
After some more head scratching I decided to just skip this user authentication stuff in VisualSVN and copy the authentication files (see screenshot on the right) from TortoiseSVN to all my repositories. Growing up with DOS and BATch files came in handy when copying those files into 16 other repositories!
This got me going so I could now connect properly to my repositories and start messing with TortoiseSVN. I've spent the rest of the day trying to come to grips with TortoiseSVN. One of the design questions is about files and folders that perhaps should be ignored. For example all generated files are placed into subfolders, such as z-clw, z-inc, z-obj32, z-lib etc. This makes it very easy to do a clean compile, just delete all files from those folders and compile! But the question is should they be excluded or not? I'm not 100% sure yet. There are certainly advantages in keeping the generated source files (.clw and .inc) in case of an emergency corruption or something like that. But on the other hand rebuilding an application from clw and inc files would be a heck of a lot of work - besides I do have backups of the original sources outside of the version control. So I'm leaning toward ignoring all generated files.
Setting up the ignore list in TortoiseSVN is confusing. You can set it via properties and use the svn:ignore and check the "Apply property recursively" but it doesn't seem to work recursively on folders or, more likely, I'm not finding the right combination of folder name/wildcards or the right syntax. It appears that forward slash should be used in paths in the ignore list rather than backslash, but it doesn't seem to make any difference for me. Files in those folders are still versioned. For now I will just use the manual method. It is painful and it is easy to miss folders of test apps, but so be it. I can't spend days on chasing down information on software that is not well documented to start with, although it has to be said that TortoiseSVN has better documentation than just about any other open source project I have tried - one reason why I shy away from open source projects.
So, all counted, I'm getting there but by no means done! I've given myself until Monday morning to get this set up and done. I'm really glad I'm messing with this on a virtual machine where I can't mess anything up:)
Monday afternoon I'm heading to Redmond for a .NET user group meeting where John Stallo, who is a Lead Program Manager on the Visual Studio LightSwitch product team, will talk about LightSwitch which is being released into first beta on Monday! I'm excited about this product and think it may be what I had hoped that Clarion.NET would be.
Arnor Baldvinsson
