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

[Alexandre Ferrieux]

Toby Johnson <toby <at> etjohnson.us> writes:
> 
> Stephen Lee wrote:
> >
> > Some files, and even entire projects were in the orphaned folder when 
> > they should have been in other locations, mainly it seemed due to 
> > confusion caused by multiple files/projects that had used the same 
> > name at different points in time, or had been renamed back and forth etc.
> 
> Yes, 0.11.0-a1 is still the latest .exe version available; there has not 
> been much activity on this project in the past several months but now 
> that we're seeing some issues get cleared up I'll probably create 
> another one shortly.

Hello,

First, many thanks for undertaking vss2svn. In addition to allowing the 
migration, it also sheds light on the terrible shortcomings of VSS :-)

Now, I'm witnessing similar problems with "orphaned" files (entire subtrees).
I have a very superficial understanding of VSS's semantics, and this notion of 
orphan file is a mystery for me. Anyway, here's the setup:
 - I have a huge VSS base with a given "trunk" copied to several 
parallel "branches" (through VSS's drag'n drop aka Share), one per developer 
in our team, so that everyone has a playground which can be overseen by others.
 - Many files are just Shared, but some are Shared and Branched.
 - From time to time we resync by committing back the branched files.

THE PROBLEM

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.

But when I run vss2svn (0.11.0-a1) on it, near the end I get a bunch of errors 
complaining about missing parent paths for "/orphaned/...". Feeling these 
errors are not fatal, I then load the generated dump in an ampty svn 
repository. There, many files occur in *several* different subdirs 
of /orphaned.

Now looking for the criterion deciding which files are thus handled, the best 
I can imagine is the fact that they were Branched by one of the users in my 
original, multibranch VSS base !!!

Does this make sense ?
Is there a way to "cut off" files from their former Shared/Branched status in 
VSS ?

Also, in your message you seem to indicate that some of the issues are solved 
in the latest source. Is it the case of this orphan problem ? (I'd love to 
recompile to check, but I've already burnt too many days struggling with that 
dripping old bag of VSS -- a new binary would be much appreciated ... if it 
fixes the problem). But maybe the problem is in my VSS base, not in your 
tool :-) [I've already run ANALYZE.EXE -- to no avail ]

Thanks in advance,

-Alex