Up and Running with Tortoise and Subversion
You're now set up for source control. Remember that Subversion uses Copy-Modify-Merge style, which means that files are never locked (unless you explicitly do so) and you can freely change source files.
For general operation you can simply edit files and Subversion will keep track of the changes for you. You can use Tortoise SVN in Explorer any time to see any changes that have been made to files. Any changed files will show with a red warning icon, which means you've made changes to the file that haven't been updated onto the server.
|Figure 11. Changed Files: Files you've changed show with a red warning icon meaning they need to be committed.|
The red icons appear next to files as well as folders. If there's a folder that has unsubmitted changes, that folder will recursively show the red icon. Note that the red icon does not tell you whether the file has been changed by anybody else! It only tells you that you have changed the file and need to commit it.
To update your changes to the Subversion server, you use the SVN Commit option to synch with the server as shown in Figure 8
You'll get a dialog box (shown in Figure 11) that lets you quickly see all the files that are going to be updated by the commit operation. You can also selectively clear files, which is useful if you have one or two files that you might not usually update, such as web.config/app.config or your project file if you have special build steps.
|Figure 12. Viewing Changes: SVN Update lets you see and choose files that have been changed in the repository.|
You commit updates of your changes to the server, but to receive changes that other users have made and have committed to the server repository you need to explicitly call Update—either on an individual file or on a directory (see Figure 12
The Update command gets the latest changes and automatically merges any changes from the server with your code. There's no update warning or notification unless there's a conflict, but if a conflict occurs, you must resolve the conflict before the Update will complete.
In most scenarios you should first update, and then recompile your project before committing changes to the repository to ensure that merged changes won't crash the build. In general, it's best to commit frequently with few changes, to make sure that the repository is as up to date as possible.
|Keeping checkouts as short as possible ensures the fewest possible conflicts.|
If you need to see differences between your local copy and any version of the file in the repository, you can check the repository against your local copy and run a comparison. There are two useful options: "Check for Modifications" and "Diff," both of which let you know that things have changed.
The "Check for Modifications" option shows you all files that differ between the local and remote versions. In a list view you can click on a file, which then brings up a Diff viewer. The built-in Diff tool shown in Figure 13
shows a side-by-side view of the differences between your local copy and the server copy.
|Figure 13. Side-by-Side Changes: The built-in Diff tool lets you quickly see changes between your local copy and any version in the repository, and lets you update your copy.|
Subversion and Visual Studio
|The tool shown in Figure 13 is the default Diff tool, but you can also specify a custom Diff tool, such as Beyond Compare.
There's really not much to say about Visual Studio support, because Subversion and Tortoise don't work inside of Visual Studio. This also means that neither Subversion nor Tortoise SVN understand anything about Visual Studio file relationships (such as that between .aspx
files). Every file is treated as a single entity, so you need to manage any file relationships on your own, by checking in and updating all files explicitly.
When you're dealing with projects and solutions you also want to carefully consider whether project and solution settings affect other users. For example, you may have local settings for connecting to a local copy of SQL Server that has a different server name than for other users; or the Web virtual path you created locally is different than that in the main application; or your local paths may not be the same as the projects in the repository.
You may have to check out the project and solution files, modify them, and then leave them checked out permanently on your end to avoid updating your locally specific changes back to the global repository. It's best to have settings configured in such a way that they work for all developers on the team, but that's not always possible. Documenting which parts of .config files need to be managed explicitly can be extremely helpful in getting new developers up to speed as quickly as possible.
|Figure 14. VS Integration: VisualSVN integrates Tortoise SVN directly into Visual Studio.|
If you prefer to have Visual Studio integration for source control, you can check out VisualSVN
, which provides integration with Tortoise SVN directly from within Visual Studio (see Figure 14
). VisualSVN works with your existing Subversion folders, so it doesn't use the Visual Studio version control provider (SCC). Instead, it talks to the Tortoise SVN APIs and gets its data directly from the file store.
VisualSVN gives you access to most of Tortoise's functionality directly from Visual Studio, and you'll see Tortoise dialogs pop up for most of its operations. What's nice about the integration is that VisualSVN knows about Visual Studio .NET file types, and automatically adds project files to source control. That saves an extra step, and lets you use standard Visual Studio project workflow to manipulate project items. One thing that's definitely easier is creation of new projects; you just select Add to Subversion and VisualSVN takes care of creating the branch and checking out the files for you.
Although I've been using VisualSVN for a while now, I still find myself working in Explorer with the shell integration frequently—it's often faster. It's definitely nice to see file status right in the IDE, and it's also convenient if you frequently add new files to the system, because VisualSVN also understands Visual Studio file associations, and automatically adds all related files.
VisualSVN isn't free—it costs $49.00 per user—but it's well worth the price if you need the Visual Studio integration.
There are several other Visual Studio Subversion add-ins available, including a free tool called Ankh, but I had a number of issues with it so I didn't try it for long. Development on Ankh seems to have ceased a long while ago, so it may be an abandoned product.
Subversion has been a great boon for me. How can it not be with such a subversive name? I've teetered back and forth between using source control and not using it in the past, because I've had my share of problems with various Visual Studio source control providers. I've used several different tools on projects and in my own work, but most of the problems seem to originate not with the tools but within Visual Studio itself. The end result was that I'd use source control for a while, and then give up, because it got in the way.
However, since I started working with Subversion, I've had no complaints about problems or compatibility in projects—even when using projects across multiple source control repositories; and that's as it should be. I now use source control on every project, even if it's purely local and for myself. Source control should be an unobtrusive tool that helps you be more productive, not get in your way. Subversion fits that bill nicely.
In this article, I've covered only the basics to get up and running. Subversion supports all the advanced features you'd expect of a top-notch source control system. If you need that functionality, it's there for you. But if you're just getting started, stick with the basics until you get familiar with Subversion and how it works—even the basic features take you a long way towards source code security and proper sharing between multiple developers.
There's much more functionality to cover. To find out more, read through the comprehensive and very readable Subversion and Tortoise documentation. Check it out—and get subversive yourself.