Using Subversion with Visual Basic 6
https://stackoverflow.com/questions/24680
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
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.)
Solution
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.
OTHER TIPS
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.
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...
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.
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)
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)
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.
