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 _______________________________________________ vss2svn-users mailing list Project homepage: http://www.pumacode.org/projects/vss2svn/ Subscribe/Unsubscribe/Admin: http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org Mailing list web interface (with searchable archives): http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
