vssmigrate Issue Tracker Rss Feed

Created Issue: Unable to get shared status after migration from vss 2 svn [8250]

mayankc — Tue, 04 Sep 2012 13:38:43 GMT

I get the status of shared file as added in svn

Created Issue: Unable to migrate file with extention .o .so file from vss 2 svn [8249]

mayankc — Tue, 04 Sep 2012 13:37:26 GMT

When I migrate my vss database to svn some file with extention .o , .so files missing in svn

Created Issue: Documentation for uploaded patchset [8161]

SoonerDave — Sat, 04 Aug 2012 06:43:55 GMT

As noted on the patches page, I have uploaded a patchset for my changes to VSSMigrate that deals with several issues and problems I've encountered in migration efforts, hopefully dealing with the worst of them. I've created the attached Word document explaining what's been done in my changes as best I can.

Commented Issue: How to handle deleted files and shared files in vss migrate [7807]

SoonerDave — Sun, 10 Jun 2012 03:51:52 GMT

I am facing problem regarding migration of project having deleted file and shared file for such projects I am getting error some time old working copy error and some time file is out of date .
Comments: ** Comment from web user: SoonerDave **

Just thought I would update my experience on migrating deleted files from VSS to Subversion...

Clearly the next biggest chunk of problems re deleted files was resolved with the fix mentioned above - catching the "not a working copy" exception and performing an Update, then retrying the Deletion. So far, so good.

Right now, my local updates to VSSMIgrate - and I've rewritten quite a bit of it - have migrated my worst-case VSS project as a 5,200-revision SVN project. I also took to writing a validation tool that scans my VSS project and ensures every file in the source exists in the SVN version, and darned if that didn't reveal still more files that didn't get migrated. Out of several thousand files, I think about six were missing. Talk about a needle in a haystack!

I think I've figured out why they were omitted, and that leads me to this caveat to anyone planning a full-history migration of VSS to Subversion via VSSMigrate: There are quite a few holes that VSSMigrate doesn't handle, and they manifest themselves as runtime errors that simply cause some situations to be skipped.

The biggest problem is that revisions in SourceSafe can encompass any one of about nine "Action" verbs, but VSSMIgrate really only handles a few of them properly. Renames, Shares, and Recovers are not handled at all, and that's directly responsible for the remaining omitted files in my migration. I'm working on fixes for each of these issues.

As an aside, I've also modified VSSMigrate to support multiple simultaneous instances so I could migrate more than one project at a time via command-line switches.

I've been talking with another member here about a possible DIFF release of these changes, and if anyone else is interested, I'll see if I can get the OK to do that.

Commented Issue: How to handle deleted files and shared files in vss migrate [7807]

SoonerDave — Wed, 16 May 2012 02:19:12 GMT

One other bit of info is that I've recompiled my copy of VSSMigrate against SharpSVN 1.7. As I read the docs here, VSSMigrate was written against 1.6, and there were several (breaking?) repository changes between Subversion 1.6.x and 1.7.x, not the least of which was how the hidden client-side .svn working copy folders are structured. I suspect that is driving at least some of the problems I've worked through, but I can't swear to that.

It seems there are some opportunities to enhance VSSMigrate, eg a configuration/settings dialog, some general code cleanup (especially following my changes LOL), but I don't know if there's enough ongoing interest in VSSMIgrate at this point to pursue them...?

Commented Issue: How to handle deleted files and shared files in vss migrate [7807]

SoonerDave — Wed, 16 May 2012 02:07:38 GMT

Here's a bit more info on your specific "out of date" and deleted file/project problems. I have discovered that the "out of date" errors can occur when folders deleted from the migrated VSS project have been added, then deleted, but not yet been updated to VSSMigrate's working copy from the committed repository. This took some eyeballing to figure out and fix!!

The clue for the resolution of this problem was in several Google searches where people had experienced the "out of date" problem, and it was fixed nearly every time by simply updating the working copy of the project. So I applied that idea to VSSMigrate.

I fixed this in my working copy by locating where the Commits() take place - there are two - and then adding code to catch the SvnInvalidNodeException that is thrown with the "xxx is out of date" error. At that point, I perform an svnClient.Update, which updates the working copy against the repository. In the same handler block, I then retry the Commit that fired the exception, which now succeeds!

This problem also led me to two other semi-related problems. VSSMigrate maintains a list of files/folders that are marked as "deleted" in SourceSafe at a particular revision. This list gets updated following each Commit(). The way the code was originally structured, however, any exception from a Commit() would skip the block that updated the deletion list, meaning the files were never scheduled for deletion. The result would be "live" (not deleted) migrated files in the SVN project that were deleted in the original VSS project.

I fixed this problem by putting the file-deletion list update code in a finally() block after the Commit() exception handler. That way, files get marked for deletion even if the Commit() to SVN fails. I also had to add a check to ensure the same filename was not added to the deletion list more than once to avoid an exception on the 2nd attempt to delete a file - that 2nd attempt would fail, and except.

Lastly, I had to make sure that the actual Deletes of files/folders were immediately committed back to the repository. Doing that shut off a boatload of the "xxx is not a working copy" errors.

I'm still running through some final tests, but I'm cautiously optimistic I'll be able to migrate nearly if not *all* deleted files and/or projects from our archive, which should make some of our other staffers happy! We'll see!

Commented Issue: How to handle deleted files and shared files in vss migrate [7807]

mayankchoubey — Fri, 11 May 2012 06:03:36 GMT

Thanx for reply let me try also with VssFolderExclusionRegex if i get proper output then surely i will post here.
Anyone else have some other way to solve the respective issue .I have to migrate my all porject with deleted and destroy history.I have sucessfully migrated those projects that don't have deleted history.

Commented Issue: How to handle deleted files and shared files in vss migrate [7807]

SoonerDave — Tue, 08 May 2012 03:09:40 GMT

For our purposes, I am not migrating deleted files or folders. For shared VSS files, I am having to make two passes through the VSS project structure with our shared files so that our release history is preserved as tag releases, but then deleting the folders that are actually shared, recreating them with svn:external declarations.

I had experimented with setting the vssExcludeFolderRegex value in the configuration file, and that works, but then I realized all the release history from our shared folders is omitted.

In my work with VSSMigrate so far, deleted files and folders seem to cause the most problems. I've finally made the decision to eliminate deleted objects from the migration.

Created Issue: How to handle deleted files and shared files in vss migrate [7807]

mayankchoubey — Tue, 13 Mar 2012 07:26:09 GMT

I am facing problem regarding migration of project having deleted file and shared file for such projects I am getting error some time old working copy error and some time file is out of date .

Created Issue: System.Runtime.InteropServices.COM Structure (Exception from HRESULT: 0x800 at SourceSafeTypeLib.IVSSVersio at VssMigrate. [7641]

mayankc — Wed, 18 Jan 2012 06:34:58 GMT

I have migrate project successfully but in case of deleted file it is showing above error. i have used this code .
private static void BuildRevisionList(IVSSItem item)
{
IVSSVersions versions = item.get_Versions(0);
foreach (IVSSVersion version in versions)
{
try
{

if (version.VSSItem.Deleted)
{
// if (version == versions[versions.Count - 1])
// {
AddRevision(version, true);
// }
}

if (item.Type == (int) VSSItemType.VSSITEM_PROJECT)
{
//if (projList.Exists(proj => string.Compare(proj.Spec, item.Spec, true) == 0))
//{
// migrateLog.Debug(item.Spec + " already exists!");
// continue;
//}
projList.Add(item);
}

AddRevision(version,false);
}
catch (COMException ex)
{
switch ((uint) ex.ErrorCode)
{
case 0x80040000: //version is corrupted and unavailable
searchLog.WarnFormat(
"Skipping version due to corruption {0} in file {1} [cannot read resource]",
version.VersionNumber, item.Spec);
continue;
case 0x8004D68F: //file not found
searchLog.WarnFormat("Skipping version due to corruption {0} in file {1} [file not found]",
version.VersionNumber, item.Spec);
continue;
default:
throw;
}
}
}
}
but it didnt work showing error. please can any one help me.
I have used Sourcesafetypelib but this lib won't work for this code
if (version == versions[versions.Count - 1]) as count need Interrop.SourcesafeTypelib
I am using vss6.0 thanx in advance.............

Commented Issue: System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component. [5476]

thedailycommute — Wed, 16 Nov 2011 13:06:19 GMT

Using revision 47996. This is happening when it hits a deleted file. I have added code to catch the exception, but would still like to preserve the history of these files.

2010-08-23 08:24:45,296 FATAL - - System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
at SourceSafeTypeLib.IVSSVersions.get_Item(Object sItem)
at VssMigrate.Program.BuildRevisionList(IVSSItem item) in ~\VssMigrate\src\Program.cs:line 496
at VssMigrate.Program.BuildFileList(IVSSItem fromVssProject) in ~\VssMigrate\src\Program.cs:line 449
at VssMigrate.Program.BuildFileList(IVSSItem fromVssProject) in ~\VssMigrate\src\Program.cs:line 429
at VssMigrate.Program.BuildFileList(IVSSItem fromVssProject) in ~\VssMigrate\src\Program.cs:line 429
at VssMigrate.Program.BuildFileList() in ~\VssMigrate\src\Program.cs:line 384
at VssMigrate.Program.Main() in ~\VssMigrate\src\Program.cs:line 102
Comments: ** Comment from web user: thedailycommute **

I fixed this problem as follows:

try
{
// Comment check added because, for some reason, several temporary (and deleted) files appear here with the
// .Deleted property == FALSE.
if (version.Comment.Contains("Temporary file created by Microsoft Visual Studio"))
continue;

// Normal file/folder/label
AddRevision(version, version.VSSItem.Deleted);
}

This allows ALL revision history to be maintained, including for deleted items (if you don't want the deleted items to be included, you can simple create a copy of the VSS repository and purge all deleted files!).

HTH,

John

Commented Issue: migrated .sln file won't open on double-click from Windows Explorer [485]

TamusJRoyce — Mon, 17 Oct 2011 19:13:37 GMT

In the process of removing VSS bindings, the solution .sln and project files are modified, and when the modified file is rewritten, the code uses the wrong (i.e. non-Unicode) encoding. This is problematic for the %PROGRAMFILES%\Common Files\microsoft shared\MSEnv\VSLauncher.exe program (which handles the DDE open command in the shell rather than devenv.exe directly for purposes of 2003/2005/2008 version selection), which fails to open a non-Unicode-encoded .sln file.

This is a simple code change to fix, but until then, people should know a relatively simple workaround is to convert the file from ASCII to Unicode encoding. I used UltraEdit, but I imagine your favorite power text editor should handle the job.
Comments: ** Comment from web user: TamusJRoyce **

Just wanted to say thanks for this patch!

Commented Issue: System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component. [5476]

pathan — Mon, 19 Sep 2011 06:24:10 GMT

I did some debugging and this seem to happen because that there is several different files in the revision where one is deleted. this make the lines version==versions[version.count-1] to crash.

It also seems that the revisions are reversed in the loop that suggest that the line should read version==versions[0] maybe i miss understood something but it seems that the file will be added twice if it is deleted also maybe a missing continue.

But the bottom line was i couldn't get it to work because of the first error and i don't have more time for this...

Created Issue: System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component. [5476]

tdahlke — Mon, 23 Aug 2010 16:01:02 GMT

Using revision 47996. This is happening when it hits a deleted file. I have added code to catch the exception, but would still like to preserve the history of these files.

2010-08-23 08:24:45,296 FATAL - - System.Runtime.InteropServices.COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.
at SourceSafeTypeLib.IVSSVersions.get_Item(Object sItem)
at VssMigrate.Program.BuildRevisionList(IVSSItem item) in C:\Documents and Settings\tdahlke\My Documents\VssMigrate\src\Program.cs:line 496
at VssMigrate.Program.BuildFileList(IVSSItem fromVssProject) in C:\Documents and Settings\tdahlke\My Documents\VssMigrate\src\Program.cs:line 449
at VssMigrate.Program.BuildFileList(IVSSItem fromVssProject) in C:\Documents and Settings\tdahlke\My Documents\VssMigrate\src\Program.cs:line 429
at VssMigrate.Program.BuildFileList(IVSSItem fromVssProject) in C:\Documents and Settings\tdahlke\My Documents\VssMigrate\src\Program.cs:line 429
at VssMigrate.Program.BuildFileList() in C:\Documents and Settings\tdahlke\My Documents\VssMigrate\src\Program.cs:line 384
at VssMigrate.Program.Main() in C:\Documents and Settings\tdahlke\My Documents\VssMigrate\src\Program.cs:line 102

Commented Issue: Convert links in svn:external properties. [3259]

danneesset — Mon, 02 Aug 2010 12:04:55 GMT

The files linked in VSS are not identified in SVN as svn:external property.
Comments: ** Comment from web user: danneesset **

I have a possible solution.
I would suggest placing / moving all non-shared files into another directory with some dummy name like dir_nonshared (if the original folder was named "dir") and then creating externals in the empty folder "dir" to both shared and non-shared files.

Created Issue: System.Runtime.InteropServices.COMException (0x8004D689): Version not found [5113]

abdulwahab — Wed, 14 Jul 2010 08:51:49 GMT

The application is continuously giving warning that "Invalid svn status detected for $project/test." and in the end it completely raised this exception "System.Runtime.InteropServices.COMException (0x8004D689): Version not found".

Can any one help me regarding this issue ?

Created Issue: System.Runtime.InteropServices.COMException (0x8004D689): Version not found [5112]

abdulwahab — Wed, 14 Jul 2010 08:51:42 GMT

Closed Issue: Cleanup issues releated to SVN file permissions (With Fix) [1364]

stjopa — Tue, 15 Jun 2010 13:21:58 GMT

Not sure if other people have run into this, but I had problems with Cleanup() not being able to delete certain files (generally ones in the _svn or .svn folder). I dropped the SVN_ASP_DOT_NET_HACK just to make sure it wasn't that, but it was still there. I tweaked the Cleanup() and added another method:

private static void Cleanup()
{
Console.WriteLine(" Cleaning up " + repoDIR);
UnlockFolder(repoDIR);

Directory.Delete(repoDIR, true);
Console.WriteLine("Cleanup done");
}

private static void UnlockFolder(string folder)
{
foreach (string subfolder in Directory.GetDirectories(folder))
{
UnlockFolder(subfolder);
}
foreach (string file in Directory.GetFiles(folder))
{
try
{
File.SetAttributes(file, FileAttributes.Normal);
File.Delete(file);
}
catch (Exception ex)
{
throw new SystemException("Error removing file: " + file, ex);
}
}
}

The main issue was related to how SVN creates the hidden files. This cleans the permissions before the delete.

Hopefully, this was just my issue. Figured I'd throw the fix up just in case.
Comments:

Closed Issue: VSS Interop fails on x64 [1661]

stjopa — Tue, 15 Jun 2010 13:21:13 GMT

If you attempt to run this on x64, you'll get a failed COM lookup for {783CD4E4-9D54-11CF-B8EE-00608CC9A71F} (VSS interop) with error code 0x80040154 (not registered).
To fix this, compile for "x86" instead of "AnyCPU"
Comments:

Closed Issue: Encoding problems with 2-bytes characters in svn:author [4297]

stjopa — Tue, 15 Jun 2010 13:18:05 GMT

In Version 0.2.0.0 SvnRevProps uses Encoding.Default and assumes that one character has size of one byte.
This causes wrong 'Author' names in svn:author in Russian Windows XP with Russian characters and spaces in Author names in VSS repository.
These names look like "?\222?\240?\232?\233 ?\216?\224?\225?\224?\235?\232?\237" in TortoiseSVN revision properties window and like an empty string in log window (it was the name in the form "XXXX XXXXXXX", where X - cyrillic characters, which should be 2-byte in UTF8).

The bug appears in case of SvnRevProps.Save to be executed, i.e. when SVNREVPROPSPATH is set and some VSS Versions are merged into one SVN Revision.

I've corrected the SvnRevProps.cs (based on VssMigrate-0.2.0.0-src), but I'm not shure where to check it in. So I simply attach my version to this report. It works for me (at least).
Comments: