**Failed** to Get version X of Y to upload - why?

[ancap]

Vault 2.0 release (2120)
Windows 2003 Server/IIS6 server
XP Pro/SP1 clients

I recently moved a small company to Vault and have been importing VSS repositories. I'm following all the import FAQ rules, including VSS 6.0c+hotfix and squeaky clean VSS repository such that analyze -v4 -f has nothing to do.

Some repositories have imported correctly with no incident larger than a label renaming (apparently Vault cannot handle certain characters in a label that VSS could). The problem that concerns me though, is about a dozen files in a couple repositories consistently earn the message:

** Failed ** to Get version 1 of file <filename>
..
** Failed ** to Get version n-1 of file <filename>

where n is the most recent version; essentially all versions prior to the tip were not gotten. The result in the Vault repository is always that the file exists, but only has a single version equal to the tip of the VSS repository for that file. Since the tip is at least imported I consider this a minor rather than major bug, but obviously I'd prefer to have historical versions, comments, etc. also there (hence I'm bothering to us import at all ).

The results are completely deterministic, the same files always import successfully and the same ones always fail to get old versions if I retry import. I've seen this on files with extensions .c, .h, .bat, and .wce, all of which I've also seen other files with the same extension and even in the same repository successfully import all versions. I've verified in the original VSS repository that I can use historical view to get details on, diff against, and get the previous versions.

Are there any known issues with VSS importing that would likely explain this? Anything to look for or attempt to allow the previous versions to be properly imported? If there are no other known issues on importing previous file versions let me know and I can try to get you a minimal VSS repository that can repro this.

Thanks-

Aaron

[Guest]

The files that fail have the "Store only latest version" property checked in VSS. Since VSS doesn't have the data, there is no way for Vault to import those versions.

[ancap]

The files that fail have the "Store only latest version" property checked in VSS. Since VSS doesn't have the data, there is no way for Vault to import those versions.

The VSS files in question do not have that checked. As I said, I am able to view history on, diff against, and get previous versions of the files in the VSS repository.

[jeremy_sg]

Sorry, I was obviously too quick in my reply. Would you mind posting an example of this happening from the import log file? VSS might be returning a more informative error. If you want, you can mail the full import log to me.

[ancap]

I'm posting back here since I discovered how to deal with this one.

The underlying VSS message was always something like:

Unable to get $/Documents/PartsLists/WidgetPartList.xls from the VSS Database.
SourceSafe was unable to finish writing a file. Check your available disk space, and ask the administrator to analyze your SourceSafe database.

**Failed** to Get version 1 of $/Documents/PartsLists/WidgetPartList.xls to upload.


Disk space was a non-issue (~4-5G free) and analyze returned completely clean. Other SourceGear and Microsoft KB articles related to this 'unable to finish writing a file' error concerned previous VSS versions and weren't relevant in this case. Thanks to Jeremy though for checking into this.

The real cause appears to be the non-existence of the VSS temp directory. This is not the c:\windows\temp (used by many SourceGear operations) or c:\documents and settings\<username>\local settings\temp (used by most everything), but an actual directory named 'temp' which is a subdirectory in the directory containing srcsafe.ini (ie. it is a peer of the data subdirectory).

It is not clear to me why, but all versions of almost all files can successfully be gotten regardless whether this directory exists. However it is clear from experimenting on multiple repositories on multiple machines that VSS Import using VSS getting old versions of some files will deterministically fail if this VSS repository temp directory does not exist. Please either add the requirement of this VSS temp directory to your FAQ/sticky-note, or investigate further why it matters. Thanks.

Aaron

[Michael]

I am getting the same error. The import is running on Win2k3 server, the VSS db is 6.0d (where can I get a copy of 6.0c and why does it matter?).

I've run the import multiple times and the results are 100% consistent: all projects created after 2001 import fine while none of the files in projects created prior to 2001 import. In VSS I can look at, diff, get files just fine. No issues with HD space or temp folders.

Any ideas?

Thanks!
-Michael

[ancap]

I am getting the same error. The import is running on Win2k3 server, the VSS db is 6.0d (where can I get a copy of 6.0c and why does it matter?).

There's a link to a direct download of 6.0c with hotfix in the sticky topic about using VSS import. The description sounds like it is just the hotfix for 6.0c, but fortunately it appears to be the entire 6.0c Win32 directory. I have no idea why 6.0c+hotfix is good and 6.0d bad; I just followed SourceGear's exact recommendation out of paranoia .

Aaron

[jeremy_sg]

Michael,

You emailed me your logs, and the failed versions all have the same error:

Code: Select all

**Failed** to Get version 1 of $/path/to/file.sql to upload.
Created 	($/path/to/file.sql) at 5/7/2000 3:46:52 AM
Change set type: AddFile
Unable to get $/Forums/DB/APOLLO_Forums/Stored Procedures/p_Forums_create.sql from the VSS Database.
Version not found

**Failed** to Get version 1 of $/path/to/file.sql to upload.

Can you get those versions from VSS using the VSS GUI client?

[Guest]

Yes, I have absolutely no problems manipulating those files from VSS Explorer.

-Michael