Hi Dirk! > I don't know which version you used before, but I wouldn't expect this > behavoir.
You were right. I didn't remember correctly. I checked the behaviour again and now I know what did bug me so much :-) I had used the nightly build of Feb 14th. But have a look at these two examples: Node-copyfrom-path: orphaned/_TRIAAAAA/jsp/screens/de/xyz.txt Node-copyfrom-path: orphaned/_ZRIAAAAA/css/bla.css I did use the VSS History function to find out where these 2 files originally were: oldprojectname/web/jsp/screens/de/xyz.txt oldprojectname/web/css/bla.css In this particular case renaming in the resulting dumpfile is possible, because the orphaned name and real project name have the same folder depth. But look at this example: Node-copyfrom-path: orphaned/_DSKAAAAA/abc.xml Node-copyfrom-path: orphaned/_ESKAAAAA/def.xml Node-copyfrom-path: orphaned/_OIJAAAAA/ghi.tld The original paths of these files were: oldprojectname/config/abc.xml oldprojectname/config/def.xml oldprojectname/config/taglib/ghi.tld So I have two different orphaned names for the same original folder. Renaming in the dumpfile is not so easy anymore because the orphaned name of ghi.tld hasn't got the same folder depth as the original file. This makes renaming in the dumpfile quite a pain. This situation arose because these steps were done in VSS: - Create a new project "container" - Create project "container/newprojectnameA" - Create project "container/newprojectnameB" - Share contents of "oldprojectname" into "newprojectnameA" - Share contents of "oldprojectname" into "newprojectnameB" - Destroy "oldprojectname" This is where all my orphans come from. And this is why I had the idea to actually find out, where a file was shared from and tweak ActionHandler.pm in the way I did. This did work out very well, and for every project I can now see where it once came from. Is there really no way of putting something like this into vss2svn? Maybe with a big warning "use at your own risk?" But you do know a lot more about VSS than I do. But I hope by describing the situation, maybe something can be done for just this situation. I can imagine that other users come across this very same problem. > Destroying unneeded projects is ok. THis is the best way to go in order > to convert only singular projects. But you should use the "-d" switch > also and it is still possible that you will see a few orphans. You mean -d for analyze.exe? This is how I invoke it: analyze -C -D -F -I-Y -V1 X:\path\to\db\data I am still documenting my script. I don't have much time at the moment :-( But it will come :-) Cheers, Ingo =;-> _______________________________________________ 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
