I had no idea what these files were and initially I mistook them for the .org files created by SourceSafe during the merge process. (If you're interested what the .org and .mrg files are you can find an explanation in this MSDN page http://msdn2.microsoft.com/en-us/library/ek8hk7e2(VS.80).aspx.)
I then realized the org/mrg files are created locally, on the client machines, and they have the same name with the sources files involved with the merge, while the .old files were reportedly created in the VSS database. And so I realized my mistake and started to search again...
It turned out that SourceSafe does create .old files in the VSS database.
Analyze.exe may create such files when it is run with -f flag (fix mode). When Analyze -f finds a corrupt file, it places a copy of that file in the backup directory, then rewrites the fixed file in the appropriate data\
I believe this is the main cause why orphaned .old files may exist in the VSS database. The old files are likely safe to delete in this case (after making sure that fixes made by analyze are correct).
DdConv.exe tool may also create .old files (when converting a VSS4 database format to VSS5 database and it finds out duplicate file entries or mismatches in the parent projects, etc). I guess this was most common back in 1997 but now it is probably less common to see .old files created because of ddconv (databases created by VSS6 should be already in VSS5 or VSS6 format; databases created by VSS2005 are in VSS6 format). Again, investigate the warnings displayed by ddconv, verify the database after conversion is what you expect to be, and it's probably safe to delete the .old files.
And I found out another case when SourceSafe uses .old files (in fact .new files may be created, too). During a Rollback operation, SourceSafe will create a .new file and will write in it only the entries that have a timestamp older than the date you rollback to. Then, it will rename the current physical file into a .old file, will rename the .new file into the current physical file and will delete the .old file. I suspect it's more likely to see .new files remaining on disk in this case if there is an error during the rollback process (while creating the .new files) - it should be safe to delete these orphaned .new files. I can see .old files remaining on disk in this case if VSS crashes or is killed during this rename process, or if another user writes a new physical file (VSS is not transactional!) causing the rename of .new -> physical to fail. If you have an .old file but not a physical file without extension you should probably rename the .old file back (discard the .old extension) and run analyze on the database. Otherwise just look in the file's history and see if you need/want to redo the rollback, delete the .old file and redo the rollback if necessary.
No comments:
Post a Comment