My team is moving from Visual SourceSafe to Subversion soon, while developing/supporting a legacy project in VB6, so I have a couple of questions:

  • What's the best tool for Subversion IDE integration in Visual Studio 6? (or is it not worth the trouble...)
  • Are there any best practices for using Subversion with VB6? (file types to ignore, etc.)


+3  A: 

My guess would be to not bother with integration and just use Tortoise SVN in Windows Explorer.

As for file types to ignore, give it a test, checkout, build, and see if any files changed (for modern Visual Studio I tend to ignore the .suo files)

+7  A: 

I would agree that Tortoise SVN in Windows Explorer would be the best way to use SVN with VB6.

The biggest change you will find migrating to SVN is the idea of "Check out" and "Check in" aren't exactly the same as "Update" and "Commit". . . thus, any IDE integration with VB6 is limited because VB6 supports MSSCCI, a check-out/check-in mechanism. I once used TamTam SVN (http://www.daveswebsite.com/software/tamtamsvn/index.shtml) with Visual Studio 2003, but stopped since I found it limiting. Merging/branching/blaming, etc. are very powerful features Tortoise SVN provides that weren't in TamTam. Tigris also has http://svnvb6.tigris.org/, but I have not tried it.

Again, while you quite possibly get an IDE to work with VB6, I would not recommend it since the greatest strength of migrating to SVN is to break the Source Safe philosophy of check-in/check-out.

Richard Morgan
VSS locking does not mean the SCCS API requires locking - ie you can use a different SCM with the IDEs and it will still work as you expect - look at Ankh in VS2005+.
@gbjbaanb - I'm not an expert but from Ankh's own site: "AnkhSVN 2.0 implements the new style SCC VAPI Microsoft introduced in Visual Studio 2005, when they also introduced TFS. This removes the locking requirements of the old style MSSCCI api and several other limits."
Richard Morgan
From http://svnvb6.tigris.org/: "[svnvb6] does not comply to the interface which Microsoft designed for Source Code Control plugins. This interface is not really suitable for an integration of Subversion."
Mike Spross
we used svnvb6 and it works fine, personally i used it only for changed files marking, but for all other things - Tortoise is the best.
+1  A: 

@Pat VisualSVN is an addin for Visual Studio so wouldn't work for VB6.


For the server side, VisualSVN Server, is a super simple solution, we are running it in a vmware virtual, and its humming along.

If you are a command line guy, I really like the command line interface for svn, I find it less confusing to get to certain actions than tortoise, such as status of the folder. But if you are an explorer fan, tortoise is more than adequate, coming from a source safe world.

The main things to ignore are:

  • Reproducable artifacts (dll, pdb, exe)
  • Environment specific settings (i.e. the settings file for vs, csproj.user file, .suo files)
`*proj.user` files and `.suo` files are not VB6! The VB6 equivalent is `*.vbw`.
thanks, I've only seen vb6 under glass, I'm a web person and in its hay day I was doing php.
+8  A: 

Since Subversion uses an update/edit/commit cycle (rather than checkin/checkout), you will need to be especially careful with binary files. Most forms in VB6 consist of two files: MyForm.frm and MyForm.frx. The *.frx files are binary, and thus cannot be merged.

Given that, I would set up Subversion to require "locking" on .frx files. This means that only one person can check the file out at a time. By doing so, you will enforce that only one developer can modify these files at a time, and it is always clear who that person currently is. If you don't do this, you are setting yourself up for some major headaches.

Matt Dillard
How can you set up SubVersion to require locking on certain file types (like frx)?
Unfortunately, the svn:needs-lock property must be set on each .frx file individually. With a little script work, I'm sure a pre-commit hook could be written that automatically sets that property on all .frx files, but I haven't gone that far.
Matt Dillard
Can you give an example of where this would be a problem?Also, if I'm working alone, is this going to be an issue? (I'm guessing the problem is that Programmer1 modified the .frx file but not the .frm file and they get out sync.
Clay Nichols
Clay, you've nailed the issue. If multiple people modify an .frx file at the same time, it can't be merged, since it's binary. An alternative to locking the file is simply to update to the latest version of the file, throw away your changes, and redo them. In your particular case, since you're the only one working on the project, this multi-user merge scenario won't be an issue for you.
Matt Dillard

Depending how much you're planning to do on these legacy projects I would consider not switching.

When digging through legacy code it really helps to have all the history and blame. SVN is miles better than VSS, but you'll be losing the history when you switch.

If you're going to be a lot of ongoing development in VB6 then it may well be worth switching to SVN, but if you're going to be doing that much going forward is it also worth reviewing the project?

I have a similar problem, only the legacy projects are in Delphi. Were they in VB6 I think I would consider 'upgrading' them to VB.Net, just for maintainability.

Why the -1 vote? Not sure why this was unhelpful - especially as the downvote is more than a year after the answer :-/
+1 because this answer doesn't deserve to be on -1.
Gavin Schultz-Ohkubo
+4  A: 

Depending how much you're planning to do on these legacy projects I would consider not switching.

I would really advise you to switch to SVN. I know of a few projects that lost source code because the VSS database became corrupted.

I think there are tools that perform the migration from Sourcesafe to SVN. A quick google search confirmed it. That way you wouldn't be loosing the revision history.

Antoine Aubry
A reference to the answer by Keith that you were quoting (useful since it has fewer upvotes than your answer ;^) ):http://stackoverflow.com/questions/24680/using-subversion-with-vb6/25035#25035

Thanks guys. I'm in a similar situation. I'm taking over a VB6 project that is being open sourced. The goal is to move it to .NET while seriously cleaning up the project. SVN will be the way to go


File types to ignore:

Workspace file that is automatically generated when you close a project, and contains which files you have open etc.

The source control status file generated by the VB6 IDE (if you go with the solution of controlling SVN in Windows Explorer, you should disable the source control plugin in VB6 and this will not be generated).

This is files generated if something goes wrong in loading a form GUI. The file is located in the same place as the form file with name equal to the form file.
Example: MyForm.frm generates MyForm.log.

You should of course only do this if you don't have log files that you need in source control...