I've been using Subversion along with TortoiseSVN (and VisualSVN inside of Visual Studio) for a few months now. It's been relatively painless, up until recently when I've attempted to really start using it for more than the standard "make changes, check it in". Unlike Visual SourceSafe where you check out a file and it gets locked until you check it back in (which is just the default; it can actually be changed to allow shared checkouts), Subversion lets everyone use all the files all the time, then merge on check in. I haven't attempted to try Subversion with any of my VFP projects yet, it's been strictly the .NET applications, so I haven't had to try to deal with merging the binary files created by VFP (eg. for forms, the SCX and SCT files, or for classes the VCX & VCT files). If you're enterprising, you can try out TwoFox from Christof Wollenhaupt. I'm leaving that hill for another day.

I ended up moving around my repository to support the more standard folder structure, since I didn't do this when I first started out. So my folders are now in this format:

branches
tags
trunk
  |--Project A
  |--Project B

The other suggested route was to put the branches/tags/trunk folder inside the project folders themselves, ex.

Project A
  |--branches
  |--tags
  |--trunk

This looked a little too confusing, especially since most of our projects are build into a single solution. To move everything around, I opened TortoiseSVN and went into the repository (right-click in Explorer, select Repo-Browser). Then I navigated to where I had my .NET development stuff, \Server\DotNetDev, right-clicked and selected Create Folder. I created the branches folder (which is meant, strangely enough, for any branches in the source code), then created the tags folder (this is equivalent to a label in VSS, although Subversion doesn't make a distinction between a branch and a tag), then the trunk folder (which is meant to hold the primary set of source code).

Then I dropped down to a command prompt and moved everything from it's original location to it's new location:

svn move -m "Relocating Project" svn://Server/DotNetDev/Project svn://Server/DotNetDev/trunk/Project

I kept the Repo-Browser open and hit F5 to make sure the change took place (it did, so far, so good). The rest of this didn't go so smoothly.

I needed to point my local copy of the source to the new repository location. It turns out there are two different options to do something like this: Relocate and Switch. I thought I might want Relocate, so inside of TortoiseSVN I right-clicked on my DotNetDev folder and selected TortoiseSVN > Relocate. Here are my notes of how this went:

- Immediately see scary message about me doing this, did some Googling, decided I really DO want to relocate.
- Get another error about it not being the root. Decided to try Switch instead.
- Get another error about one of my projects not being in the same repository.
- Realize I may have mistyped the new repo. name, try svn://Server/DotNetDev  to svn://Server/DotNetDev/trunk instead.
- Get errors about it not existing in that location for that revision.
- Great.
- Select the option to Update to Revision.
- Suddenly panic that I'm going to lose my changes that haven't been checked into source control yet. Wish I had thought to make a backup first.
- It doesn't seem to help.
- Realize I had one folder which still pointed to it's original source on the web (I'm using an open-source project that I had grabbed via TortoiseSVN, so it's still pointing to that website)
- Try to relocate it and get errors about relocating only changing the repository part of a URL (regardless of what I try to change)
- Get irritated and go to lunch.
- Get back from lunch.
- Delete the .svn folder that was pointing to the wrong server (the open source one).
- Make a backup of the directory where the .svn folder was.
- Get new version via SVN checkout for that specific folder.
- Try to use Switch.
- Get error about needing to cleanup the project.
- Cleanup.
- Try to use Switch again.
- Get a different error about some file not being able to be added to the repository because it already exists (it's the same folder I've been having problems with).
- Erase the entire folder including the .svn folder this time.
- Do a checkout on this folder again.
- Finally get around to making a backup of all my files, just in case.
- Try Switch again, it seems to do something and not give any errors.
- Ran a diff on the folder I had problems with to check to see if I lost anything and/or grab files from my backup.
- Fire up VS and force a rebuild to see what/if anything was broken.
- All good (!)

Relocate = Source is switched to a completely different server.
Switch = Source is on the same server in a different directory.

I'm not entirely sure why these are two different options.

Fast forward two weeks. I decide to test out the idea of creating a private branch where I can make all my daily changes (and do a check in at the end of the day). I basically don't want to check in stuff that isn't complete, may break things for other developers, etc. But I want to make sure it gets checked in daily so it's backed up. Branching seemed like a good way of handling this. The initial branch seemed to go smoothly so I made changes over the next week or so and kept checking them in. Today I decided to merge the branch back into the trunk so we could get a good copy of the files on another dev. machine. It seemed to go about as well as moving the repository (I'll spare you all the ugly details).

Ultimately, I think the problems were related to the fact that I had a completely different mental model of how merging a branch should work: I though you would just select the option to merge, then select the branch you want to merge from (my local copy) and select the branch you want to merge to (the trunk), let it merge and resolve any conflicts (if any). The UI even looks like this is how it should work. It doesn't.

I must have tried merging 20 different times, each time with different errors or issues. I read and re-read the docs and just didn't seem to understand how this was supposed to work. Here's what finally worked for me:

I had to check in all of my changes into the branch I had been working with, then use "Switch" to switch back to the trunk copy (which does some scary things like delete source code in your local copy). Once I had a copy of the trunk, I did the Merge again, pointed the "From" option in TortoiseSVN to the trunk, not my local copy. Pointed the "To" to the branched copy I had been working on. Then I selected the last revision before the branch in the trunk and all of the revisions in my branch, and it seemed to merge OK. Then I committed my local copy back into the trunk.

It appears you need to track the revision numbers manually (the check-in notes are probably the simplest) when merging branches back in; so, for example, if I had revisions 50-55 in a branch which I then merge into the main trunk, then make changes 56-60 in the branch again, I have to make sure I only merge revisions 56-60 into the trunk. Otherwise, I risk duplicating changes (essentially, Subversion doesn't track your merges). I looked at the roadmap and it appears that functionality is scheduled for build 1.5 (it's currently at build 1.4.5). That's definitely going to be a welcome enhancement.

One thing I noticed in the docs is that they mention that new Subversion users have problems with the From/To issue, and with picking the correct revision to merge against. It's pretty clear they're forcing users to deal with implementation details that I think should be hidden, so that the mental model most of us have of all this actually matches what we need to do in the UI to accomplish things. Having to mention that most developers make mistake "X" or "Y" should be a red flag that maybe things need to be changed.

The one saving grace of all this is that I haven't lost any changes yet. I'm starting to get in the habit of checking all my files in before I attempt to do anything out of the ordinary (which seems to be a good practice to get into).

Links

http://subversion.tigris.org
http://tortoisesvn.tigris.org
http://www.visualsvn.com
http://www.foxpert.com/downloads.htm