VSSConverter Failures/Flaws

I am having no luck using VSSConvert to migrate a large VSS database into VSTF.  I could not convert the database in beta 2 and I still cannot convert it in beta 3.  I'm trying to convert a single root project and VSSConverter runs for a few hours then crashes with a Send Error type exception.  Neither VSS Analyze nor VSSConverter analyze reports any errors on the database.  VSS analyze does report several warnings associated with loss of Share/Branch, files still checked out in VSS, and a single "TF60067: Data loss due to folder move warning".  I don't really care about the checked out files right now.  I'm simply trying to test whether the process will succeed.

Before the crash occurs, I receive several (~14,000) errors of the type "{Total Errors 14440} ERROR: The item $/Project/Folder/FileName could not be found in your workspace."  Immediately before the crash, the following is in ConverterErrors.txt:

{Total Errors 14456} ERROR: The item $/ProMax/Interfaces/Enumerator.idl could not be found in your workspace.
{Total Errors 14457} ERROR: The item $/ProMax/HEX/HexObj.h could not be found in your workspace.
{Total Errors 14458} ERROR: The item $/ProMax/HEX/HEXObj.cpp could not be found in your workspace.
{Total Errors 14458} ERROR: A database error occurred (SQL error 1205) ---> Transaction (Process ID 60) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
{Total Errors 14460} ERROR: The item $/ProMax/Interfaces/ITrayedColumn.h could not be found in your workspace.
{Total Errors 14461} ERROR: The item $/ProMax/Interfaces/Tray.idl could not be found in your workspace.
{Total Errors 14462} ERROR: The item $/ProMax/Interfaces/TrayedColumn.idl could not be found in your workspace.
{Total Errors 14463} ERROR: Cannot rename '$/ProMax/Interfaces/ITray.h' back to its original path of '$/ProMax/Interfaces/IStage.h'. Use undo instead.

Even though the conversion process failed (it actually did convert some of the project), I noticed another flaw that I absolutely abhor.  VSSConverter is not maintaining the case sensitivity of file names that are present in the VSS project.  I thought this was a trait of applications written in the 1980's, not the 2000's.  Our VC++ solution contains >6000 files and most of the file names are compound names that can be somewhat long.  Having mixed case in the file names makes reading the names much easier, especially when dealing with such a large number of files.  Using mixed case names is not simply a recommendation to our developers, we require it.  This is obviously not a problem with VSS or VSTF itself because I can create mixed case names in both applications.  The converter is simply taking this liberty on its own.  This is enough of a problem that we probably will not use VSTF unless it is fixed because there will be no way to get back what we've lost in the conversion.  (Obviously we are not going to use VSTF if the converter fails.)



Answer this question

VSSConverter Failures/Flaws

  • AJC

    No you cannot have a path length>260 in VSS same is true for TFS also. Try manually creating a folder with path lenght >260 in TFS you will never succeed. This is not due to limitaion in SQL field size but the decision was taken as such long paths are impractical looking at windows limitation. The problem as i see it is that in your VSS to TFS project mapping destination tfs project is longer than source vss project. Like in

    <ProjectMap>
       <Project Source="$/short path" Destination="$/My Long Path/This is a very long path" />
     </ProjectMap>

    you may want to keep your destination folder name length <= VSS folder name.

    hope this helps you.


  • rgny

    I understand that it is not a great migration experience and trust us we are working hard to make the experience smooth. See below for the issues that you have noticed:-

    >>Before the crash occurs, I receive several (~14,000) errors of the type "{Total Errors 14440} ERROR: The item $/Project/Folder/FileName could not be found in your workspace." 

    We suspect that most of these errors are could be due to corruption of VSS database. We are going to change the error message to be more meaningful. Like "Converter could not migrate version 3 of $/Project/Folder/FileName".

    Still for the confirmation we need to have a look at the VSSConverter.log and ConverterError.txt created in same folder where converter is running. Can you zip these files send me(akashm at microsoft.com) through email. Incase size is more that 5MB let me know I will find out an alternate way (FTP site where you can upload the log file).

    Even to investigate the possible cause of crash we need the log file.

    >>Even though the conversion process failed (it actually did convert some of the project), I noticed another flaw that I absolutely abhor.  VSSConverter is not maintaining the case sensitivity of file names that are present in the VSS project.  I thought this was a trait of applications written in the 1980's, not the 2000's.  Our VC++ solution contains >6000 files and most of the file names are compound names that can be somewhat long.  Having mixed case in the file names makes reading the names much easier, especially when dealing with such a large number of files.  Using mixed case names is not simply a recommendation to our developers, we require it.  This is obviously not a problem with VSS or VSTF itself because I can create mixed case names in both applications.  The converter is simply taking this liberty on its own.  This is enough of a problem that we probably will not use VSTF unless it is fixed because there will be no way to get back what we've lost in the conversion. 

    Believe me it is a bug in converter and it is already fixed it post Beta3. 

    Thanks,
    -Akash

  • Erch

    Actually it's VSSConverter analyze that reports the warnings.  The VSS Analyze command reports no problems. -- Sorry about the typo.
  • Ross Miltenberg

    I thought about trying that and still may try it if I have to.  There are a lot of projects and subfolders, however.


  • Cl&amp;#233;mentM

    I can't help with your problem, but I CAN agree that the loss of filename case is very annoying!

    Is there any chance that you could convert your project one 2nd level tree at a time Or have you too many level 2 nodes (by which I mean, nodes immediately under the root node) to make that feasible

  • ripleym

    Thanks simdoc,

    I should have been more clear. The error occurs when I'm importing files into TFS source control from VSS using the "vssconverter" utility. The import operation fails with the following message:

    TF10128: The path $/COEVSS1/PathName contains more than the allowed 260 characters. Type or select a shorter path

  • AllDisplayNamesRBelongToUs

    Thanks Ankur,

    However if this is Windows limitation, then I'm puzzled why it doesn't affect VSS In VSS we have sub-folders that are fairly deep and combine it with the actual file name, it exceeds > 260 chars. This is only an issue when I try to import files into TFS source control. So I don't believe this is a Windows limitation per se. The 260 is probably a file system limit but these files are saved in SQL Server.

  • Gary Varga

    Can you do something like map/substitute a drive letter to cut down on the length of the file names
  • PatrickC

    this is a windows limitation. you cannot have a file with path length > 260. hence both VSS and VSTF do not support path length >260.
    thanks

  • Dub

    Another annoying limitation I found is the file path length must be < 260 chars. Will this limitation be fixed for the RTM release

    Thanks.

  • Kuik

    Good, I'm glad to hear that case sensitivity will be preserved.  Is there a way to obtain a converter that has this fixed because I'm not going to use it for anything but testing VSTF unless I can make the conversion without losing case sensitivity.  If I have to wait until release, I won't be able to use the product for quite some time.

    I will also send you the log information.  I don't doubt there could be some corruption in the VSS database.  It is somewhat large and has been in use for several years on the continuous development of a product.  However, I don't know what I can do since none of the analyze utilities reports and problems.  I also have noticed that the log contains some information for projects/files that I'm fairly certain that I've deleted and purged in the past.

    Thanks.

  • ChandraP

    You can use UNICODE file names with some APIs and prepend the  "\\ \" sequence to get longer paths, but that's rarely implemented.  See http://msdn.microsoft.com/library/default.asp url=/library/en-us/fileio/fs/naming_a_file.asp for more info.
  • Swatanya

    I'll get you the log information ASAP.  I'm rerunning the conversion process again because I need to rebuild the logs since they got deleted when I retried the conversion.   It takes several hours for the process to complete.
  • rocco n

    What I was implying was the implementation of VSSConverter could have been written to take advantage of this capability.
  • VSSConverter Failures/Flaws