This project is read-only.

Is anyone actively monitoring this project?

May 16, 2012 at 2:37 AM


I was just wondering if anyone was actively monitoring this project anymore. It appears the latest updates are about two years old, and the discussions appear to be mostly orphaned.

Only reason I ask is that I've been working with VSSMigrate over the last couple of weeks against a rather old but still-used and very large SourceSafe library, and have managed to work out quite a few bugs and hiccups along the way - particularly pertaining to files deleted in VSS and the way they can create problems during the migration, some of which can explain a few of the odd "xxx is not a working copy" errors....

It may just be that those who have migrated have already done so, and if that's the case, blessings all!


May 16, 2012 at 4:01 PM

I don't know how many other people are monitoring this list, but I still am :-)

A few months ago I also downloaded the source, and made a bunch of modifications in order to (mostly!) migrate my VSS repositories to SVN. However, after I managed to get a (more or less) working solution, I ran out of time to actually perform the migration (so many deadlines, so little time!), so I'm still using VSS on a daily basis :-)

I also never got around to actually figuring out how to create patches, much less where to upload them. Maybe it's time I dug out my changes and see if I can still remember how VSSMigrate works!



May 17, 2012 at 12:14 AM

Hi, John, glad to see someone else here!

I'm still struggling with some issues on migrating deleted files and folders, but excepting that portion I think I've got a good migration configuration set up for VSSMigrate. We'll see how it goes!


May 19, 2012 at 12:03 AM
Edited May 19, 2012 at 12:04 AM

Well, I've gotten as close to a clean migration tool with deletes as I think I can get.

I kept going in circles in my head decoding BuildFileList(), and finally discovered an omission in that code that led me to rewrite it. I eliminated the two versions in the original source and replaced it with a single version (only one call, not the two), streamlined the recursion, and dropped it down to about 25 lines of code (I think it runs fractionally faster, too, but I haven't put the timing tests on it to verify). The omission I discovered was that revisions of the base project - only its children - would ever get added to the project. I also factored out a method to check if an item meets any of the regexExclusion settings from the config file.

Also think I've fixed most - maybe not all - of the conditions where the "xxx is not a working copy" issues, fixed a *very* hard to trace problem where a particular revision would not get correct properties set.

Jun 6, 2012 at 11:34 PM

Hi David,

I'm still struggling with several "xxx is not a working copy" errors. Can you post/email your code changes that you have?


Jun 7, 2012 at 1:34 AM
SoonerDave wrote:

Well, I've gotten as close to a clean migration tool with deletes as I think I can get.


I would also love to see the changes you have made, if you can make them available. Unfortunately I also have the additional problem of using Source Safe 6.0d.

Jun 7, 2012 at 1:54 AM

FYI, I started working on this with Source Safe 6.0d and ultimately updated to Source Safe 2005. If you can't do that it is possible to modify the Vssmigrate code to use 6.0d. I would reference the discussion at this site to help with getting 6.0d to work: 

Jun 7, 2012 at 2:15 AM
estrennen wrote:

FYI, I started working on this with Source Safe 6.0d 

Thanks, however I have already used those changes to get Version working. Unfortunately Version does not include any label info from VSS.

I have been trying to get vssmigrate-47996 to work. I have added the changes by thedailycommute , and commented out the code in AddRevision that deals with pinned versions (version.VSSItem.IsPinned not available with VSS 6.0d). This seems to work if I just run vssmigrate on small branches of the VSS repo. Although files deleted in vss end up in the trunk of svn. If I try to transfer the bulk of the VSS repo, I just get a complete mess in svn. I have not got very far trying to find the problems as yet.

Jun 7, 2012 at 3:03 AM
estrennen wrote:

FYI, I started working on this with Source Safe 6.0d and ultimately updated to Source Safe 2005.

I would upgrade to VSS 2005 if I could find someone in Australia who stocks it.

Jun 7, 2012 at 3:16 AM

I also found that migrating individual projects is the best approach. Migrating my entire VSS database to SVN resulted in too many issues to clean up.

As far as VSS 2005, not sure where to get that. I have an MSDN subscription, so I was able to download the DVD for it.

Jun 8, 2012 at 5:05 AM
Edited Jun 8, 2012 at 5:23 AM

At lot of my problems seem to arise due to deleted files and projects in the VSS database. If I only call AddRevision with deleted = false, a lot of the errors go away. The deleted files still remain in svn though. Perhaps the program needs to do a second pass to remove the deleted files.

Changeset 14470 of this program seems to work ok also. It however does nothing with labels and does not include any history of deleted files.


Edit: I see that SoonerDave has already made comments about deleted files in much more detail here

Jun 10, 2012 at 4:16 AM

hi dkselw

Deleted files has become a bit of a nightmare. It has also pointed out to me some holes in VSSMigrate that really only arise if you want to migrate history, and in my situation, I think I'm going to have to. I came up with the same change to AddRevision as had been noted in an earlier post. 

I'm going to make an update to that earlier comment re deleted files, but since you made the post here I thought I'd make sure you knew I was going to add a few more $0.02 to it :)

Jun 10, 2012 at 9:12 PM

Hi SoonerDave,


I've just started investigating migrating my 11G VSS database over to VisualSVN Server, the problem I face is the shared file issue (and of course deleted as well).  It looks like you had made signifcant changes to the code ?  Would you me able to share your revised code ?

I figured with shared files I would you the syn:external at the folder level for all shared files under that folder.  I need it at the file level and not at the whole folder level.

With the older version of src 2.0.0, i figured out what I would  need to do to handle the LINKS (shared files) and was just about to start to code the changes.


Jun 11, 2012 at 8:13 PM


I'm also interested in getting your latest changes. I've got ten years of changes to migrate to svn and the current codebase is having some challenges.


Jun 20, 2012 at 9:55 PM

Seems like David is further ahead with updates to VssMigrate, which handle some nasty situations frequent for large codebases. It would be great to see his updates. Meanwhile one can keep reading explanations and fiddling with the code oneself.

Jun 20, 2012 at 10:07 PM

So I've been hacking around the code (not as many cycles as I would like).  I've figured out that trying to keep all the old revisions will just take too long to migrate, so I've modified to only keep the last 3 revisions if the file is older than 3 years and 6 rev's otherwise.

The next big hurdle is how to make the SHARED files propogate properly (I plan on using the sys: externals at the folder level), but I'm not sure how Visual Studio will like that afterwards.

That will probably be the next test before doing the code for the Shared Files.  We have 16 years of shared code and shared files. Ouch !