Welcome to my adventures in Subversion. This is part one of a pretty good-sized project that will integrate a lot of open source tools. Right now, there are about 10 tools that will be integrated together to support software development efforts. A few of the tools are Subversion, DotNetNuke, and Community Server (Forums and Blogs). There will also be Windows and web-based access to Subversion and tracker and wiki utilities. This is only the beginning. Should be a pretty eventful project, I think. Hopefully, I can get things up and running smoothly. Anyway, here is what I went thru to set things up. This is mainly just intended to be for documentation purposes, but hopefully someone else can benefit from it.
Setup
First off, I started with the Windows installer version of Subversion 1.1.1 (file list). I was going to use the Solaris version, but it hasn't been updated since June (1.0.5). After I downloaded the installer program, the installation was self-explanatory, as most Windows installers are. Thanks Jostein Andersen.
Repository Creation
First, let me say that there's a quicker way to set things up than to use the command line. I downloaded and installed TortoiseSVN after installing Subversion, but I didn't really play with it, yet. After looking at it, I found out that I should've just stuck with it, instead of the command line. But, for those who are having command-line issues, here ya go...
I was looking through the quick start instructions and the first thing I ran into was this:
$ svnadmin create /path/to/repos
$ ls /path/to/repos
conf/ dav/ db/ format hooks/ locks/ README.txt
Recognizing that the path was a UNIX file path, I replaced it with a test path: c:\svn\path\to\repos. This didn't work, tho. I got the following error.
svn: Repository creation failed
svn: Could not create top-level directory
svn: Can't create directory 'C:\svn\path\to\repos': The system cannot find the path specified.
I thought that maybe Subversion had something special setup and knew where to create the repository. So, I tried it exactly as the docs specified it, but to no avail. I tried several variations before looking it up online. It turns out that the repository being added must have all parent directories in place. So, for my example, I had to have the path, c:\svn\path\to already setup. Once I added this, I was good to go. I ran the following with no problems after creating the c:\svn directory.
svnadmin create c:\svn\test_repository
Now, this is about when I tried TortoiseSVN, so I'm going to recap what's necessary for that client. First, create the c:\svn\test_repository directory. Second, right-click on that directory and select TortoiseSVN > Create Repository Here. That's it. You should get a message confirming that the repository was setup correctly.
Next, you will need to create a working directory. Since a lot of my old stuff is in PVCS, I'm just going to use the c:\work directory that I already have setup. So, within the c:\work\test_repository, I created branch, tags, and trunk directories for branched files (see branching and merging), labeled, or “tagged,” revisions, and the actual working directory of the checked-in files, respectively. Put the files you will be checking in and out in the trunk directory. For my purposes, I created Documentation and Source directories to start off with. Using TortoiseSVN, I imported the files (right click and select TortoiseSVN > Import...). Pretty easy. Just know that when you specify your repository location, you have to precede the local file path with file:///, so my test URL would be file:///c:/work/test_repository.
After importing your files, you'll need to delete everything within the working directory (it's all in source control, now). Once you do this, simply check-out the files from Subversion (right click on directory and select Checkout...). Now, everything should be setup for you to modify files as needed. If/when you need to connect to the repository browser, simply right click anywhere (preferably from the appropriate working directory) and select TortoiseSVN > Repo-Browser.
Subversion Oddities: Revisions
The first thing that I found odd about Subversion was that revision numbers are applied to entire hierarchies. So, given the following structure:
Documentation/
Project Mgmt/
Project Plan.xls
Requirements/
Requirements.doc
Vision.doc
Assuming that everything was imported at one time, everything would be given the revision number 1. Let's say that the Requirements.doc file was modified. Once committed, the revision number for the Requirements directory and all of its contents would be set to revision 2. Now, let's say that the Project Plan.xls file is updated. The Project Mgmt directory and its contained files would be set to revision 3; however, the Requirements directory would still be set to revision 2. The odd thing is that in revision 1, 2, and 3 of the repository, the Vision.doc file is the same.
This isn't a hard concept to comprehend, it's just different from a lot of other SCM suites. Most SCM systems (that I've seen) have a per-file versioning system. In my mind, the per-file solution works a lot better. That way, I know exactly how many times a particular file has been updated and I can predict the revision number of say, 3 changes ago. This way, it's a lot harder to know. If you want to do a diff, you'll first have to figure out what the last updated revision number was, and then accomplish the diff w/ a different tool (still a part of Subversion, just a different command). Maybe this isn't that big of a deal, it just seems to be odd to me. Perhaps it'll be something I get used to fairly quickly. Nevertheless, I'd like to see some sort of combination of the repository and file versioning systems. This isn't all-too thought out, but perhaps using major.minor.revision would be a good way to do it. These would correspond to repository, directory, and file revisions, respectively. So, based on my previous scenario, the versions would look like this:
Documentation/
Project Mgmt/
Project Plan.xls (3.2.2)
Requirements/
Requirements.doc (3.2.2)
Vision.doc (3.2.1)
Another thought would be to reverse those numbers. That might be a little odd to see, but it would put emphasis on teh file version instead of the repository version. For instance, since the Vision.doc file never changed, its version number would be 1.2.3, representing the first cut of the file, second of the directory, and third of the repository. I kind of like this better, but it depends on whether you want to have a repository- or file-based versioning system. Perhaps the option would be nice.
Subversion Oddities: Checkout and Lock
I guess CVS and a number of other tools do this, too, but the idea of “checking out” a file doesn't implicitly lock the file. This seems kind of odd to me. I'd like to know, with the option to override, that a file is being worked on by someone else. This is for obvious reasons. I don't like the idea that I have to explicitly lock the file when checking it out to edit it. So, essentially, think of “checkout” as “get latest”.
Subversion Oddities: Tagging vs. Labeling
I don't really know too much about labeling, but from what I understand, you attach a name, or label (duh), to a particular set of files, or a revision within Subversion, and this can mark your major releases. For instance, you might have v3.1 Stable and v3.2.1003.1042 Nightly labels for stable and nightly builds. This would allow you to checkout all files with a particular label and build it as that particular release. In Subversion, you would think that this would be fairly easy. All you need is a property file specifying a label name and the repository revision number, right? Wrong. You have to make a copy of the revision and place it in the tags directory. Granted, this isn't that big of a deal because it doesn't make a physical copy of the files, just a logical one. I just think that it is overly complicated for what you're wanting to do.
Work in Progress
This post is kind of a work in progress. I'm still learning about Subversion, so as things come up, I'll have to update the post. I haven't setup the server portion (svnserve), but will have to do that soon - well, either that or Apache. I'm waiting on a server to load that on, first. For now, I guess I'll move on to my next task: finding tracker open source software (hopefully in .NET).
Suggestions
- I hate the versioning system. When I'm working with a single file, it'd be nice to know how many times that one file has been changed, not how many times anything in the directory hierarchy has been changed. That's so aggravating. If I want to do a diff or something, I have to know the revision number of the last time it was changed. That drives me crazy.
FYI
There is a PVCS-to-Subversion tool available here. This was created by Thomas Wolkenstein. Thanks Thomas!!! If anyone uses it, please let him know if you have problems with anything.