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

[Stephen Lee]

Alexandre Ferrieux wrote:
>
> 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.
>
I'll step in and give a partial answer since I've been dealing with a 
similar situation...

For one case of what I'm referring to as a "true orphan" for a file, you 
can see this yourself in SourceSafe...

When you select "Properties..." on one of the files that has been 
branched, and go to the Links tab, you can see the branching structure 
for that file, and each branch will show where one of the shared copies 
of that file is (you can use the Links button to find any other shared 
copies). Branches that show as "** Deleted **" are not contained within 
any project, but unless you got an error like 'File 
"......\SourceSafe\data\r\ryoaaaaa" not found' when opening the dialog, 
these branches still exist in the underlying storage for the file.

Another case is if a file was created originally in (for example)
$/Branch1/Project/MyFile.cpp
then shared to
$/Project/MyFile.cpp

... and later Branch1 was destroyed/archived/ etc...

In this case the conversion will initially create the file as "orphaned" 
and then share (copy) it to the main project.

> 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.

Also the way you've done this is possibly creating the problem you 
see... when you "restore" a project, then as I understand it all of the 
files and subprojects within that project are "created" before the 
project itself according to the timestamps, so vss2svn has nowhere to 
put them up to the date of the Restore action, apart from the "orphaned" 
folder... and this would be in addition to other sources of orphans.

Check the history on your converted database - you may find that your 
main project is 'created' only during the final few revisions and then 
populated by copying various items from the "orphaned" folder.

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)

> 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 !!!
>
This will be the case for (most of) the files that are in individual 
subfolders of 'orphaned'. Where there is a project tree hanging off an 
orphaned folder this means the entire project is orphaned (perhaps due 
to an archive/restore, or perhaps because the conversion script got 
confused by a number of renaming and moving of the project earlier in 
its history.

> Does this make sense ?
> Is there a way to "cut off" files from their former Shared/Branched 
> status in
> VSS ?
>
I am not aware of a method. I think the file only actually disappears 
from the underlying database if all shares of all branches of the file 
are destroyed.

You might get this effect from other vss to svn conversion programs that 
work backwards from the current project structure (and call vss itself 
to get each older version of the files) rather than forwards from an 
empty database though. You just need to evaluate which is most 
appropriate for your needs.

The vss2svn tool would be most appropriate if you want to take the trunk 
and all existing branches across to svn, as it should properly preserve 
the branching structure, in which case you'd be best evaluating it in 
that context... if you need a smaller database for initial tests, 
perhaps destroy all but a few subprojects (in all branches) rather than 
destroying all non-trunk branches.


If you do decide to attempt to take forward what I did with my 
filterorphan tool (which is, in effect, just a complicated way of doing 
a multiple search/replace in the dumpfile), note that you only need to 
do the vss2svn part once - ideally on the entire database. You can keep 
reprocessing the dumpfile in as many different ways as you like afterwards.


In my case, although I have a defined pipeline of operations that I know 
works, I have still yet to do the final "live" conversion. My SourceSafe 
database uses the file sharing mechanism to distribute some header files 
between over a dozen subprojects for individual dlls. It would be 
unrealistic to expect these changes to be manually merged across to 
other copies of the files every time they changed, so I will be 
adjusting the layout so that all subprojects pick up the header files 
from a central "include" folder. I expect that for the initial fix of 
this I will simply check in a final revision of the widely shared file 
consisting of a single line #include-ing the file's new central location.

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....?).
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).

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!

-- 
Stephen Lee <Stephen.Lee at hexagonmetrology.com>
Software Engineer, Vision Group - Pro-Measure Leader
Wilcox Associates Inc. (U.K.)