Using Subversion with Visual Basic 6

Question

My team is moving from Visual SourceSafe to Subversion soon, while developing/supporting a legacy project in Visual Basic 6.0, 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 Visual Basic 6.0? (file types to ignore, etc.)

Vanguard

Answer 1

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.

Transit

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+. – Oui

@Oui - 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." – Transit

From 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." – Ghislainegholston

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. – Darwindarwinian

Answer 2

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.

Isoline

How can you set up SubVersion to require locking on certain file types (like frx)? – Cran

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. – Isoline

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. – Idomeneus

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. – Isoline

+1 You can require locking on certain file types by default by editing the local SVN configuration. This needs to be done on each client machine that uses SVN :( If you are using TortoiseSVN then you can open the file with TortoiseSVN\Settings\General\Subversion configuration file. Then in [auto-props] put *.frx = svn:needs-lock – Hoye

Answer 3

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. (Yes-- a quick Google search confirmed it.) That way you wouldn't be losing the revision history.

Humfried

A reference to the answer by Keith that you were quoting (useful since it has fewer upvotes than your answer ;^) ): https://mcmap.net/q/614947/-using-subversion-with-visual-basic-6/… – Cran

Answer 4

File types to ignore:

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

MSSCCPRJ.SCC
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).

*.log
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...

Cran

Answer 5

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)

Rox

Answer 6

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)

Chthonian

*proj.user files and .suo files are not VB6! The VB6 equivalent is *.vbw. – Cran

thanks, I've only seen vb6 under glass, I'm a web person and in its hay day I was doing php. – Chthonian

Answer 7

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.

Fernandes

Why the -1 vote? Not sure why this was unhelpful - especially as the downvote is more than a year after the answer :-/ – Fernandes

I disagree with this answer. When we took our code base and moved to SVN a couple of years ago, we simply kept our VSS repository and locked it, so no one could update it. We still have the history in VSS if we need to look something up (which has happened a handful of times), but we are not shackled by VSS's limitations and we gain all of SVN's benefits. – Historian