A horrible and hacky filter for the "false orphan" problem...

[Dirk]

Hi Stephen,

thanks for providing your filter. I needed some time to read through 
your mail and understand all the details.

I found some time in the past to work on the converter again. So let's 
take the chance to have a look at your issues.

>> As a test-run, I want to migrate to svn just the "trunk". To this 
>> effect, I
>> use vssadmin to select just its subtree and Dump it to a .ssa file. 
>> Then I
>> create an empty VSS base, and Restore the .ssa in it. I thus get a 
>> standalone
>> VSS base with just my trunk. So far so good.
>>
> This tool (vss2svn) is designed to work from an empty repository, and 
> build it up one revision at a time, replicating all the actions you've 
> done. By exporting only a single branch (when you work across branches 
> a lot) you're making it a lot harder for it to track the history of 
> various changes it can't "see" any more.
>
> ...
> Instead you probably want to take a complete copy of the entire 
> sourcesafe database, possibly destroy some superfluous projects from 
> this copy (especially if they don't have any shared files with the 
> projects of interest) and then try converting it (it doesn't burn much 
> extra of *your* time to leave something running overnight, or in the 
> background while you get on with other stuff)

... thanks for the above explanations. They are totally correct and the 
suggested workaround, copying the database and tidying out the 
unnecessary projects is the best way to go.

In case where you have an already archive/restored database, there are 
still some problems left in the conversion. I have twisted my mind 
already a few times, in order to find a solution for this, but had no 
great big idea yet. The chronological order is messed up and esp. if you 
restore into a subproject you can not simply fix the parents timestamp.

@Stephen: I expect you orphaned problem is also related to wrong or 
messed up timestamps. I found in my database also a few places, where 
the timestamp is completely wrong, a few times to a garbaged phyiscal 
file. In other times, do to a wrong client machine, that had a wrong 
timestamp.

Sincerelly vss doesn't allow for timestamp editing (you can edit 
comments and labels), but we could provide the tools ourself. So for the 
"real" hardcore converter it would be possible to detect the wrong 
files, fix up the timestamp in the database and run again.



> I will also be watching out for an updated vss2svn.exe to evaluate 
> whether it does a better job for my remaining issues that I currently 
> plan to manually fix-up, which are:
> a) PIN -> UNPIN -> PIN sequence being interpreted as just PIN -> UNPIN 
> (or perhaps PIN -> PIN -> UNPIN, or possibly just UNPIN cancelling out 
> all PINs....?).
I expect you used a similar workflow as I use daily. In a shared and 
pinned file you want to got to another version. So you open the history 
of that file, perform an Unpin and then a Pin on another version. 
Probably you did a wrong Pin, so you directly unpin again and pin 
another version. All this happens in the "same" time.

I'm astonished about this being a problem, since I have a lot of these 
files in my database. Do you have a copy of the PhysicalActions and 
VssActions of such a situation?

> b) One subproject that got completely trashed during the conversion 
> (and which I will have to perform surgery on manually afterwards - I 
> finally decided to give up attempting to get the filterorphan.cpp to 
> fix it up for me, as some of the updated revisions needed simply 
> didn't exist at the right point in time in the dumpfile).
I don't say, that we solved all problems, but the most problems 
remaining are from
 * wrong timestamps
 * missing support for archive/restore
 * broken archives
I expect you ran "analyze -v4" and checked the reported errors?

In any case, I can offer help if you send me the log files (also 
privately). I will keep all information under disclosure.

Best regards
Dirk

>
> Perversely, if the updated .exe does a better job with the false 
> orphans without fixing one or both of the above (I will at least 
> report back if one comes out in time), it will be of less use due to 
> already having the filter in place to fix the current version's mistakes!
>