Sublime Subversion

Repository Templates are a great way to reduce the time required for setting up a new project, and encourage consistency across projects.  Consistency is important especially in an organization with many different repositories spread over different projects and development teams.  Having a consistent repository structure drastically reduces common errors made by new developers or even experienced developers in an unfamiliar repository.

Setting up Repository Templates in Sublime is as easy as creating a folder structure on your Sublime server containing the files and folders you want to include in your new project.  In this walk-through we’re going to create a Repository Template for new projects using Sharp Architecture.  Sharp Architecture is a perfect candidate for a Repository Template because there are quite a few dependencies that can take a while to download and organize.

In the following steps we’ll be creating a Repository Template for Sharp Architecture, but the same steps can be applied to any number of project types you may have.

1. Create the new Repository Template Folder

The first step is to create the new Repository Template folder on your Sublime/Subversion server.

1. Connect to your server using Remote Desktop
2. Navigate to the “Templates” folder beneath your Sublime install location (typically C:\Program Files\Sublime\Templates)
3. Create a new folder inside Templates called “SharpArch” (note: the folder name can be different from what your users see when choosing a template)
   

   Create a new folder for the template

4. Open the new folder and create the standard Subversion trunk, branches, and tags folders.
   

   Create the branches, tags, and trunk folder

5. Open the “trunk” folder you just created.  Now it’s time to start creating the folder structure for your new project.  For starters, Sharp Architecture projects tend to have a defined top-level folder structures for the different elements of a project: app, build, db, tests, etc.  So let’s create those folders now.
   

   Create the project folder structure

6. Next, if you like you can create README.txt files in each folder explaining what should be placed there.  This is optional of course but can be useful for new developers who may not be familiar with the project structure.

2. Download Sharp Architecture binaries

Now that our basic structure has been created, it’s time to download the related Sharp Architecture binaries as well as their dependencies.

1. Open a web browser and navigate to the Sharp Architecture download page.
2. Download and extract the latest revision (or which ever revision you prefer) of the compiled binaries
3. In the extracted folder, locate all of the DLLs and associated files (located within the “bin” folder as of this writing) and copy them all to the “lib” folder we created back in step 5 of the previous section.
   

   Copy Sharp Architecture binaries to template

3. Register the Template with Sublime

The last step is to register the newly created Repository Template with Sublime.

1. Navigate back to the Templates folder and open “templates.txt” in Notepad
2. This file follows a simple INI file format and you should have two templates already listed (Standard and Empty).  Create a new section with the following structure:
   [SharpArch]
name = Sharp Architecture
description = Use for Sharp Architecture based projects.
   

   Insert new template description into templates.txt

3. In the example above, the section header “[SharpArch]” must be the same as the folder name for the template.  But the value for the “name” attribute is what will be displayed to your users.  There is also an optional “default = true” attribute you can add if you want this template to be automatically selected as the default choice when creating new repositories.
4. Save templates.txt and close Notepad.
5. Next you must restart IIS by opening a command prompt and typing
   C:\> iisreset

4. Test the Template

Open a web browser and navigate to Sublime.  Click on the Create New Repository tab and in the Template section, you should see the new “Sharp Architecture” template.

Preview the new template

Wrap-up

In this walkthrough we’ve created a new Repository template for projects using the Sharp Architecture framework.  We created a folder structure and pre-downloaded all binaries and their dependencies so that new repositories would automatically have this structure and these resources.  This same approach could be taken for any number of project types relevant to your organization.

Using these same techniques you could make your template more robust including common resources such as:

• NANT build script templates
• Visual Studio .sln or .csproj files (although your users would most likely have to re-name them for your project)
• Common scripts or tools used by your organization
• Default config files with references to your development or production environment
• etc

For additional information and complete documentation on creating Repository Templates, please see the Sublime documentation.

This article summarizes a few tips and tricks for working with Subversion from the Visual Studio IDE.  Note that these tips assume that you are using TortoiseSVN as your SVN client.  However, they should hold up whether you are using an SVN client integrated with Visual Studio or simply the command line.

1. Ignore bin and obj folders

One of the first things you should do with any new solution or project is to ignore the bin and obj folders that are automatically created when you compile your project.  Here are the steps I follow when adding a new project to your solution:

1. Add the project in Visual Studio
2. Compile once
3. Close Visual Studio and add the new project folder with TortoiseSVN
4. When adding the project folder, be careful not to also add the “bin” and “obj” folders
5. Commit your changes from TortoiseSVN.  When the commit dialog comes up, right-click on the “bin” and “obj” folders and select “ignore”
6. Finish the commit.

2. Ignore .suo and .user files

These files pop up from time to time and you want to watch out for them.  These files are specific to each user, so if they get committed, everyone will be continuously prompted to resolve conflicts because their version differs from the version in Subversion.

3. Close Visual Studio between commits

I’m going to catch a lot of flack for this one because it seems like a pain.  But it’s really not that hard and it will help you avoid making multiple commits for a single change because .csproj or .sln files hadn’t been saved yet.  For example, let’s say you add a new .cs file to your project.  You code it up and are ready to commit.  Switching over to TortoiseSVN you see your new .cs file needs to be committed, but nothing else.  You commit that file and keep working.  However, the .csproj file has been changed to, but it has only been changed in memory and not saved to disk so TortoiseSVN doesn’t see the change.  You are now left in a position where only the new .cs file has been committed, and the .csproj file hasn’t.  Ideally both files would be committed at the same time because together they represent the addition of your new .cs file.

My workflow is this:

1. Decide what feature or bugfix I’m going to work on
2. Open visual studio.
3. Make the changes necessary for that feature/fix only.
4. Test
5. Close visual studio
6. Commit from the root of my working directory to get all files changed
7. Go to step 1

4) Don’t accidentally deploy .svn folders

This one is easy to overlook especially when it comes to ASP.NET projects.  Subversion creates a hidden .svn folder inside each folder of your working directory.  If your deployment “process” consists of copying your ASP.NET project folder and all sub folders (images, css, etc) and pasting them on your web server, you’re going to be copying all of those .svn folders along with it.

There are really two options to avoid this.  The first is to use the “export” command from Subversion.  If you are comfortable installing the Subversion command line client on your target server, then you can run a command like this to deploy your changes:

C:\> svn export svn://myserver/myrepo/trunk C:\inetpub\wwwroot\mywebsite

Once you have done that you’ll also need to copy over the DLLs because the bin folder won’t be included in the repository (assuming you followed tip #1).

A better solution is to use some sort of continuous integration or automated build process.  Cruise Control.NET is a great solution for this sort of thing.

That’s it for now.  I’ll return to this post and update it from time to time as I identify more tips and workarounds.  Please share your own tips by commenting below.

When moving to SVN from VSS there are really two different aspects to consider: technical, and social.

Technically, the answers are pretty straight forward. You need to decide where the SVN repositories will be hosted, how they will be served, and how permissions will be managed. You also need to decide whether or not you want to import your existing VSS repositories, and how much of the history you want to preserve. Finally, you need a client for your users – typically TortoiseSVN and optionally a Visual Studio plug-in like AnkhSVN or VisualSVN.

The easiest ways to set up a SVN server is to use one of the pre-packaged installers like Collabnet, VisualSVN Server, or Sublime. All of these will install Subversion and do a lot of the basic configuration for you.

Here are a few resources on the technical side:

• Migrating from VSS to SVN
• Setting up SVN on Windows
• VSS Migration Tool

Now, the social side may be a little more difficult. The biggest change is that VSS works with a check-out, edit, check-in model where SVN works with a edit, merge, commit model. This takes some getting used-to by the developers but ultimately it’s a better model in my opinion. With SVN, you essentially have the entire code-base checked out by everyone, all the time. You are free to make whatever changes you want without checking anything out. Then, when you are ready to commit your changes, you merge them with the latest version in the repository, and commit everything at once.

There are a few major benefits by taking this approach. One is that there are literally no roadblocks between a developer and the work he/she needs to do. I don’t need to wait for a file to be checked in, and if I want to make large changes I don’t need to worry about getting in anybody’s way.

The other major benefit is that each commit can represent a self-contained body of work: a feature, a bug fix, a unit test that passes, etc. All files and changes related to that body of work are contained within a single commit and it’s easy to look at the repo history and see why files were modified and how modifications relate to each-other. This is much harder to do in VSS because people usually check in file by file. Or, if they do check in multiple files at a time, it is probably because somebody else needs to edit one rather than them being finished with their particular feature.

Source control is an incredibly valuable tool for software development, but most people don’t think of it that way. Managed correctly, source control is a safety net giving developers an enormous amount of freedom to experiment, tinker, and implement with the knowledge that they can always go back if necessary.

In my opinion, you can’t do source control correctly with the check-out, edit, check-in approach. At least, not with a team of any significant size. So it’s worth some short term pain in terms of developer education for long term benefits.

Eric Sink has a great set of articles on source control overall. In chapter two he discusses the differences between these two approaches.

It’s worth pointing out that SVN does support locking which lets you get close to the check-out, edit, check-in model typical of VSS. But, I’d still recommend biting the bullet and adopting the other model.