Sublime Subversion

Sublime’s powerful Repository Template feature allows you to create templates that users can select when creating new repositories.  These templates can include folder structures and files that should be created for each new repository.  Creating a basic template is as easy as creating the folders and files, and then editing a few lines in a text file.  However, one of the more powerful features of Sublime is to create templates customized to each new repository.  This, can take a bit more work.

A customized template is one where repository details (name, description or owner) are used when the new repository is populated from the template.  Typically this is used to simply rename files or folders to match the name of the new repository.  But what if you wanted to go farther?  In this post I’ll show you how to create a template containing full Visual Studio solution including multiple projects, all of which will be customized to each new repository.

1. Create a new Visual Studio Solution

Start up Visual Studio and create a solution to be used as your template.  You can create multiple projects, default classes, etc.

New Visual Studio project

2. Rename Files and Folders

Next, close Visual Studio and navigate to the folder containing your solution.  Rename your files and folders using the placeholders below so that they will be renamed when your new repository is created.

• %name% – name of the new repository
• %name-formatted% – name of the new repository formatted for a file system (removed spaces and special characters)
• %description% – description of the new repository
• %description-formatted% – description, formatted for a file system
• %owner% – owner of the new repository
• %owner-formatted% – owner, formatted for a file system
• %guid[0]% – %guid[100]% – unique guids which will be generated when the new repository is generated

Be sure to remove any unwanted files and folders such as bin, obj, or .suo and .user files.

Renamed files and folders

3. Modify Solution Files

The next step is a bit tricky.  Open your Solution File (.sln) in a text editor such as Notepad.  Locate the project names and again, use the placeholders above to rename the names and paths.

Modify project names and paths

Next you must replace the solution GUID and project GUIDs with placeholders so that new GUIDs will be generated for each new repository.  Start with the solution GUID used for each project and replace it with %guid[0]% (leave the GUID braces).

Replaced solution GUIDs

Next you must replace the GUIDs for each project.  Assign numbers to each project starting with 1 and keep a note of which project has been assigned what number.  In my case I chose to use alphabetical order.  Now, select the GUID for the first project, and using Find and Replace, replace it with %guid[1]% (again, leaving the braces).  Do the same for each project, each time using a new guid.

Project GUIDs replaced

Save and close the modified solution file.

4. Modify Project Files

Next, open each project file (.csproj, .vbproj, etc) in a text editor such as Notepad.

First, replace the GUID in the <ProjectGuid> tag with the guid that you assigned in the last step (i.e. %guid[1]%).  If you set up project dependencies when you created your solution, you may need to update those as well.

Next, update the <AssemblyName> and <RootNamespace> tags to use the placeholder names for your new repository.

Modified project file

5. Modify Code Files

Next you may need to modify your source code files to replace namespaces with placeholders.  For example, in this example we replaced the namespaces within the Global.asax and Global.asax.cs files.

Renamed Namespace in Global.asax.cs

6. Finalize Repository Template

Next build out the rest of your repository template structure.  Remember that the files and folders you create will populate the entire repository, so you must create the “tags”, “branches” and “trunk” folders as well.

Complete repository template structure

7. Register the new Template on your Sublime Server

Finally, copy the entire template structure to the Templates folder on your Sublime server (typically C:\Program Files\Sublime\Templates).

New Template copied to Templates folder on Sublime server

Then open the “templates.txt” file and add the details for your new repository template.  See the administrator guide for details on modifying the “templates.txt” file.  Be sure to include the “replaceTokens = true” line for this new template.  Otherwise the placeholders you created will not be replaced with actual values.

Add the new template to templates.txt

Save “templates.txt” and perform an IISRESET.

8. Test the Template

Finally, create a new repository using the new template to ensure it is working properly.  It is a good idea to create a repository, check it out, and open the solution in Visual Studio to ensure that the project builds and that all names are being replaced properly.  If you missed any files or namespaces you can simply edit the template on the server and try again.

Create a repository from the new template

Download the Sample

You can download the sample repository template created for this walkthrough from the link below.

Download the sample Template

Many organizations use SharePoint for team and project collaboration.  SharePoint is an ideal location to store project documents, issues lists, and other project artifacts.  However, without a view into the actual development progress for your project you won’t have a complete picture.  With Sublime 1.2 it is very easy to view your repository commit history directly within your SharePoint team sites or even your My Site.

Viewing Project Progress in a SharePoint Team Site

Having a SharePoint site per project is a very common model for organizations who rely on SharePoint for collaboration.  With Sublime’s RSS feeds it is possible to display the commit history for a single repository right within your SharePoint project sites.

1. First, navigate to your project site.
2. Next, under the “Site Actions” menu, choose “Edit Page”
3. Once the page is in edit mode, choose a web part zone and click “Add Web Part”
4. In the Add Web Parts dialog, choose the “RSS Viewer” web part and click “Add”
5. Once the web part is added, click the “Open the tool pane” link to edit the web part properties
6. Next, open a new browser window and navigate to Sublime
7. Click on the Browse Repositories tab, locate the repository for your project, and click the repository to view repository details.
8. In the “History” section at the bottom of the repository details page, locate the orange RSS feed icon.  Right-click on this icon and choose “Copy Shortcut”.
9. Switch back to your My Site and in the RSS Feed URL textbox for the RSS Feed web part, paste the shortcut you copied in step 7.*
10. Click “OK” to save your settings.  You should now see the activity feed for your repository on the project team site.
    

    Subversion history on a SharePoint project site

View your Activity Stream in your My Site

One of the best features in Sublime 1.2 is the personalized activity stream.  This activity stream shows you all activity on any repository you are a member of so you can easily stay up to date with all your projects.  And because this view is personalized it is an ideal candidate for your SharePoint My Site.

1. First, navigate to your My Site.
2. Next, under the “Site Actions” menu, choose “Edit Page”
3. Once the page is in edit mode, choose a web part zone and click “Add Web Part”
4. In the Add Web Parts dialog, choose the “RSS Viewer” web part and click “Add”
5. Once the web part is added, click the “Open the tool pane” link to edit the web part properties
6. Next, open a new browser window and navigate to the Sublime home page
7. On the right-hand side, next to the activity stream there should be an orange RSS feed icon.  Right-click on this icon and choose “Copy Shortcut”
8. Switch back to your My Site and in the RSS Feed URL textbox for the RSS Feed web part, paste the shortcut you copied in step 7.*
9. Click Okay to save your settings.  You should now see your activity stream on your My Site home page.
   

* RSS Feed Permissions

Depending on how you have configured your Sublime security settings, you may need to modify the RSS Feed URLs slightly.

• If you have turned off RSS Authentication in Sublime (available from the Administrative Security page) then you don’t need to make any changes.
• If you require RSS Authentication then you must specify a username and password in the query string for the RSS feed.  The username and password are added to the end of the feed URL as follows:

http://myserver/Feed.aspx?f=repo&r=/path&username=myusername&password=myurlencodedpassword

Let me paint you a picture.  It’s 5 minutes till 5 at the end of a long work week and you’ve just wrapped up a new feature on your current project.  It’s time to commit those changes and head out for the weekend.  You pull up TortoiseSVN, write a helpful and descriptive commit message (feeling vastly superior to your less-than-thorough colleagues with their randomly generated commit messages), and hit the Commit button.

AAAAAAAARRRRRRGGGGHHH!!!!

AHHHH!  The last thing you want to do is spend the next hour picking through other people’s changes to make sure your code still works.

Now here’s a little secret about developing software with a team.  Merging is just a fact of life.  Unless you want to go back to the old lock/modify/unlock model you’re going to have to merge your changes with someone else’s at some point.  But with today’s software, most merges can be handled automatically by our development tools.  The only real problem arises when you have to merge lots of changes all at once across many different parts of your code-base.  Resolving conflicts (deciding what code to keep when two changes contradict each other) requires intimate knowledge of your code and your colleague’s code.  Not the activity for 5PM on a Friday!

There are two keys to keeping merges simple:

1. Commit frequently with simple, focused changes
2. Update your working copy after each of your colleagues commits changes which may impact you

Commit Frequently with Simple, Focused Changes

As you are making changes to your code, keep a mental note when you shift from one focus to another.  Are you fixing a bug?  Developing a new feature?  Optimizing a query?  As soon as you shift from one focus to another – assuming you are finished with the first thing – commit those changes along with a short, simple description of your changes.  This is good practice in general, but it also greatly reduces confusion when a team member has to merge their changes with yours.  A small, focused change is much easier for someone who isn’t familiar with your code to comprehend.  So if I have to merge my changes with yours, and I see that your change fixes a certain bug, I can be sure to pay attention to that detail when merging so as not to re-introduce the bug into the code-base.

Update your Working Copy Frequently

Staying up to date with the activities of your team is a critical step in reducing and even eliminating the pain associated with merging.  If you see that a colleague committed a change to a file you are working on, you can update your working copy right then and there.  This offers two significant advantages: (1) you will be dealing with smaller conflicts that are usually much simpler and (2) the other developer is probably still in the office if you have any questions.

This is where Sublime enters the picture.  Sublime allows you to stay up to date with your development team using email notifications and RSS feeds.  If you enable email notifications on your project repositories you will be notified immediately when another users commits changes.  If you don’t like email, you can use the personalized activity stream RSS feed which notifies you whenever a user commits changes to any of your repositories.  Both of these methods allow you to quickly scan the commit details including the commit message, and changed files so you can determine if their changes might conflict with your work.

Viewing the Commit RSS feed in Outlook

The amazing thing about these two practices is that (a) they are actually pretty simple to implement and (b) the time and mental energy required for merging changes practically vanishes.  And it’s not just that you are spreading that hour merging commits across the day so it doesn’t seem like it takes as much time, it really does take less time.  The reason for this is that you are eliminating the mental ramp-up time required when you save this for the end of the day or worse, the end of the week.

A good way to think about this is efficiency in testing and fixing bugs.  Fixing bugs while your team is actively engaged in development is vastly more efficient than fixing bugs after your team has disbanded and moved on to something else.  While development is in progress, everyone is already engaged and can rapidly jump to the source of a problem, get it fixed, and move on.  Your brain operates the same way.  While you are working on a particular piece of code, your brain keeps a mental model of that code so that you can quickly navigate from one area to another implementing features.  If you have to merge changes and you already have that mental model, you know exactly how those changes will impact your code and what needs to be done to resolve any impacts.

These two practices really aren’t that hard to implement with your team.  Sublime has features that are designed specifically for making this easy, but even if you are using a different product you can still work to implement these practices.  Once you have worked this way for a few days I guarantee you’ll never want to go back.

As you may know, last week saw the Subversion Vision Conference in New York City. This wasn’t a large event, rather it was a small meeting of several core members of the Subversion team. Their goal wasn’t marketing, community building, or flag waving, but rather to step back a moment and take a look at where Subversion was headed. And although they didn’t come away with a finalized roadmap or vision statement, it does appear that some good progress was made on mapping out the direction for Subversion.

I think this is great and I’m glad to see the Subversion team taking some time to map out the future. But I do wish we had seen some indication that Subversion may evolve to incorporate some distributed functionality. However, according to Michael Pilato the immediate plan appears to be to “Maintain a centralized approach to version control”.

Considering the composition of the team – most members being from companies such as Collabnet or WANdisco who serve the enterprise – this isn’t exactly surprising. Centralization is still a key concern for enterprise IT organizations who need to maintain tight control on their systems for compliance and governance reasons. But I hate to see the team dismiss different approaches to source control simply because it doesn’t appeal to the enterprise yet.

I think distributed version control systems have some great advantages and not just in the open source space. I think cheap, personal branching and merging is an extremely powerful tool. From personal experience I can tell you that it can completely change your development workflow for the better. My opinion is that anything that stops a developer from committing changes is a bad thing. Your version control system is your safety net – it should be there to support you, not to impose speed bumps.

I’ve watched the rise in popularity of DVCSs over the last few years. Git made the DVCS sexy but they’ve been around for quite a while. Microsoft supporting Mercurial on Codeplex is just one example of DVCSs being taken seriously by very large players.

But even though distributed systems are the hot “new” thing, most organizations – big or small – still place a high value on centralization. As a small business using Subversion, I see the value in having one location with all of our valuable IP. I have one asset to back up, one place to go to find repositories, one place to go to manage access, etc. These are all great arguments for a centralized system but I think there can be a middle ground.

The combination of a centralized version control system supporting distributed working copies could be extremely powerful. Allowing your developers to commit, branch, merge, and revert locally and then pushing changes up to the master repository as appropriate seems like the best of both worlds.

This is where the Git users out there yell at me and tell me that Github already works this way. I’m aware of that and have used it myself. It’s a great workflow – but it’s not ready for the enterprise, or even smaller companies. It will work for some, but not for the majority.

This is where I think the Subversion team can make some serious traction – not just supporting the status quo – but really moving the product forward in a new and exciting way. I think that Subversion is in the unique position of being able to take advantage of the benefits that distributed systems offer while at the same time serving those who care about centralization.

In the coming months I expect that the Subversion team will make their roadmap public and I’m excited to see what’s on it. I really like what I’ve been hearing about the Working Copy changes (no more .svn folders littering my working copy!) and love to see the momentum in the community. Subversion is still hands-down the best source control solution for small, medium and enterprise organizations, but it can always be better. I hope that the core team will consider some of these opportunities when mapping out Subversion’s future.

Sublime 1.1 has been released and is available for download now!  Current users of Sublime 1.0 can download 1.1 and upgrade their server for free.  Please see the upgrade instructions for details on upgrading your server.

Below are the new features added in Sublime 1.1:

• Repository RSS Feeds
  Each repository exposes an RSS feed for repository commits.  Repository RSS feeds contain the same information included in repository email notifications such as commit message, date, changes, and author.
• Event Log RSS Feed
  For server administrators, the Sublime event log is now exposed as an RSS feed. This allows administrators to see errors or backup notifications as they occur without having to check the event log or Sublime web interface.
• Disable Repository Folders
  If you do not plan on organizing repositories into folders, or your Subversion server doesn’t support a folder structure (i.e. Apache) you may now disable repository folders in the Sublime interface.  When disabled, the repository list page will no longer display the folder hierarchy, and users won’t be prompted to choose a folder when creating new repositories.
• Support for SMTP Servers requiring SSL (e.g. Google Apps)
  When configuring email settings for the server, administrators can specify that the server requires a secure connection.  This is required for some email servers such as Google Apps.

For a complete list of changes and bug fixes in 1.1, please see the release notes.

The Board of the Apahce Software Foundation (ASF) has voted to approve the graduation of Subversion from incubation.  Subversion is now a full-fledged ASF project.  This is just one more step in the life of Subversion and one that will hopefully encourage greater community involvement and innovation.

Even if you are new to Subversion you have likely heard terms like “trunk”, “branching” and “tags” thrown around.  If you are coming from a source control system like CVS you may already be familiar with these terms but if you are coming from a tool like Visual Source safe they may be new.  This post provides an introduction to these concepts in Subversion.  For more in-depth information please see Chapter 4 of the Subversion Book.

First things first – the trunk.  In Subversion, the term trunk refers to your main source code tree.  If you are starting out a new project, you will spend the majority of your time making changes and committing them to the trunk of your repository.  This is because early in a project there are fewer situations where you need branches or tags (there are certainly exceptions depending on your team and development practice, but this is an introductory article and we won’t get into that).

Now, let’s say your project is moving along and getting fairly stable, but you want to experiment with adding a new feature.  You could simply start making changes in your working copy and see how they work out without ever committing them, but this would be a mistake.  If this is a large set of changes your work could span multiple days – even weeks.  At some point your manager is going to wander over to your desk and inform you that there is a critical change that needs to be made RIGHT NOW. Now you’ll need to set aside those experimental changes, get a fresh copy of the trunk, commit those, somehow port those changes into your experimental code, etc etc.  It gets complicated fast.

Branching is specifically designed for situations like this.  A branch is a copy of your source code – typically a copy of the trunk – with a special name like “experimental feature”.  It sets up a space for you to work and make changes without committing to the main trunk.  Once the code in your branch is complete, you can merge your changes back to the trunk.  In addition, as new changes are committed to the main trunk, you can merge those changes into your branch so your branch is up to date with the latest changes from the trunk.  This is a great habit to get into by the way because it makes the process of merging your branch back to the trunk much much easier when the time comes.  Not to mention the fact that you are much more likely to catch potential integration issues early.

I’ll come back to branching in a bit, but now let’s move to tagging.

A tag is simply a named version of your code at a particular point in time.  For example, let’s say you’ve reached version 1.0 of your project.  Rather than having to remember that version 1.0 was revision 638, you can create a tag and give it the name of “1.0″.  Best practice is to create a tag for every major release or milestone (beta, 1.0, 1.1, 2.0, etc) but you can create tags for any point in time you think developers will care about in the future.

So we’ve covered the basic concepts, now I’m going to let you in on a little secret.  Ready?  In Subversion, there is literally nothing special about a branch, or a tag, or the trunk for that matter.  It’s just a directory in your repository which holds a version of your source code.  That’s it.  In most Subversion repositories the directory for storing branches is called, well “branches”, but that is just a naming convention.  You could call yours “superman” and Subversion would still behave exactly the same.

Here’s what I mean.  Most repositories will have the following structure at their root:
/branches
/tags
/trunkEach path above is simply a directory in your repository.  Trunk is self explanatory – it contains your main development tree.  Branches is a folder which will contain sub-folders, one for each branch.  Tags is the same – a folder which will contain sub-folders for each tag.

Here’s what your repository might look like with several tags and branches:

/branches
/branches/new_feature <- branch for implementing a new feature
/branches/1.0_maint <- branch for doing maintenance on version 1.0
/tags
/tags/0.9 <- version 0.9 release
/tags/1.0 <- version 1.0 release
/trunkWhen you create a branch, or a tag, Subversion is simply copying your current code usually from the trunk (although not required) into a new folder in /branches or /tags. Once your code is copied, you can check out a new working copy from that location, make changes, commit, etc. Since your working copy points at the branch folder rather than the trunk, changes you make will only be committed to the branch and not to the trunk. The act of merging is essentially picking the changes you have made and moving them back into the trunk. Subversion gives us tools to make this easier, but it essentially boils down to just that.

Now, why is this important? Well for one it means you aren’t stuck with the standard naming convention of branches, tags, and trunk. If you prefer something like “variations”, “labels”, and “root” it is entirely up to you – Subversion won’t care. However, unless you have a compelling reason to change, it’s best to stick with branches, tags, and trunk because it is widely accepted as the standard naming convention.

Another reason this is important is that Subversion isn’t going to limit you from making mistakes like checking out a tag and making changes to it. Making changes to a tag goes against the entire purpose of a tag because a tag should be a static point in the history of your code – not something you make changes to. If you need to make changes to version 1.0 outside of your trunk (maintenance for example) you should make a new branch using your 1.0 tag as the source (step by step instructions is beyond the scope of this article).

So that’s it. Branches, tags, and trunk are simply standard folders in your repository set up to help you manage your development process. You can change these conventions if you wish, but you should have a solid reason for doing so. You can also add to this structure if you need additional controls for your development team or process.

Before closing I want to make one point about how your code is copied to a branch or a tag. Subversion is smart enough not to make an entire duplicate copy of your code each time you create a branch or tag. It simply creates a pointer to the revision your branch is based on. When you make a commit to the branch, Subversion stores the difference between the modified version and the original file. It does not create a full copy of the file.

I came across this article today in another forum.  It’s a translation of a Russian article about how the source code for websites that use Subversion can be obtained if they don’t remove or block the hidden .svn folders from their site structure.

Basically, since Subversion maintains a text-based copy of your files in the hidden .svn directory, it’s possible to view the source directly if you know that a given website is using Subversion.

For example, if you want to view the source to index.php on a given site, you could try a URL like this:
mysite.com/.svn/text-base/index.php.svn-base
The server would see that as a request for a .svn-base file, not a .php file and it would simply serve up the source rather than running through PHP.

There are two ways to protect you against this.  First, as I mentioned in a previous post, DON’T DEPLOY .svn FOLDERS.  The svn export command lets you grab a full tree of your source code without the .svn folders – so use that if you are deploying a website.

Second, you can set up your web server to block .svn folders.  The article has some examples of how to do that for apache and nginx.  I haven’t tried this on IIS yet but I’ll give it a shot and update this post with steps to protect yourself on Windows.

Sublime automatically backs up all of your Subversion repositories on a schedule you define.  In this short article we will walk through the process of configuring your backups, monitoring your server to ensure backups are happening, and restoring a repository.

1. Configuring Backups

To configure your backups, navigate to the Administration section in Sublime and click the “Backups” tab.  First, enter a path for your repositories to be backed up to.  When you install Sublime, it will default this path to be a Backup folder within your Sublime installation directory.  However, it is strongly recommended that you back your repositories up to a network device such as a NAS or remote network share.

Next, enter a time of day and the days of the week that your backups should occur.  Generally this should be a time of the day that users are not using Subversion.  However, Sublime uses the subversion “hotcopy” command when making backups so even if your users are still accessing Subversion you are not at risk of corrupting data or interrupting the backups.

Lastly, enter a backup account to be used when performing the backups.  This account must have read/write access to the Backup path.  It will also be added to the local administrators group on your subversion server.

Scheduling subversion backups in Sublime

2. Monitoring Backups

Each time Sublime backs up your Subversion repositories, it will write an entry to the Windows Event Log.  You can monitor this directly from the Sublime web interface, or by connecting to the server using remote desktop.  Each entry in the windows event log will list the number of repositories backed up, the number of errors (if any), and the duration for the backup.

Successful Subversion backup in the Windows Event Log

If you are using Windows Server 2008, you can create a Custom View to show only Subversion backup messages.  Simply create a new Custom View to display “Information” events filtered where the Source is “Sublime.SubMaint”.

3. Restoring a Subversion Repository

Restoring a repository is essentially copying the backup repository from the backup location back to your Subversion server.  However, as a best practice we recommend the following steps:

1. Take your Subversion service offline.  This ensures that while the restore is underway, your developers cannot commit to the repository.  If you are running Sublime in SVNSERVE mode you can take the Subversion service offline from the administration home page.  If you are using Apache you will have to stop the service manually in the Services console in Windows.
2. Locate the folder containing the repository you want to restore on both your Subversion server, and in the backup location.  The backup location should be a mirror of your repositories folder on your Subversion server, so locating the correct repository should be easy (see below for tips on identifying a repository folder).
3. On your subversion server, delete or rename the folder containing the repository you want to restore.  Then, copy the repository folder from the backup location over to your subversion server.

Let’s look at an example.  In the screen shot below, the left folder is the Repositories folder on our Subversion server.  This contains all of our current “live” repositories.  The folder on the right is our backup location.  If we wanted to restore the “CommonLibs” repository, first we would delete “CommonLibs” from the “Archive” folder on the left.  Then we would copy the “CommonLibs” folder from the backup location on the right and paste it in the “Archive” folder on the left.  The result would be a fully restored version of the “CommonLibs” repository from the time the last backup ran.

The Backup location is a mirror of your Repository location

Once you have restored your repository you can bring the Subversion service back online.  It is also a good idea to reset IIS (open a command prompt and type “iisreset”) to ensure that the Sublime cache is cleared.

TIP: How to locate a repository folder

If you are new to Subversion it may not be clear exactly what constitutes a repository.  In short, a repository consists of a folder containing a number of specific sub-folders and files.  So when we say “repository” we are talking about the parent folder and all child folders and files.

You can identify the repository parent folder by looking at its children.  A repository will contain the following child folders: conf, db, hooks, locks.  It will also contain a file called “format” and there may or may not be a README.txt.  In the following screen shot, we are looking at the content of “CommonLib”  You can see that it contains these folders, thus “CommonLib” is a repository.  The parent folder “Archive” is not – it’s merely a folder.

Identifying a repository folder

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.