Hi, I've been trying to work around the same problem. I'm not a Perl expert, so I couldn't really understand what vss2svn is doing. So I just created a shell script (I'm better at that) that reads up an intermediate output (the output from ssphys) and creates file externals on the HEAD revision of the svn repository.
There is a remaining problem and it's related to what you suspected: svn file externals and VSS shared files are not semantically the same. Close, but not the same. In subversion a shared file has to live somewhere connected to your tree. If you delete that file and other projects were pointing to it, there is no way to know that happened until you try to get one of the other projects and the file is found missing. The only workaround I've been able to come up with is to create pre-commit hook scripts that checks for that and moves the source of the file to one of the remaining projects. Other problem is that looking at the source file you have no easy way to know that it is being used as a source for a share, so you don't really know that you have to "unshare"-it before modifying it in non-compatible ways. Perhaps the best way to deal with that problem, now that I think about it, is to have a shared repository tree that mirrors the repository without the externals. Every time you try to link a file using the svn:external you would delete the file in the source and make BOTH source and target point to the shared tree. That way you always know that the file is shared and the semantics is closer to that of VSS. Notice that having a single shared folder won't work because there is potential for name conflicts. It still feels like a hack, though. The best solution, of course, is to refactor your projects so that they use common folders instead, but we both know that's not always practical. On Mon, 2009-05-11 at 15:30 +0100, Matthew J Fletcher wrote: > Hi, > > vss2svn does a very good job of importing the history and the project > layout, unfortunately it does not seem to cope so well with files that > have been shared in VSS between projects. Actually, it doesn't cope at all, it just makes a copy, so the sharing information is lost. > > Would it be possible to modify the script to use the 'export' property > of SVN, not being an expert on such matters i am not sure if the two > functionalities are the same. > > regards. > > --- > Matthew J Fletcher > Serck Controls Ltd > Firmware/Software > > Tel: 02476 515089 > mfletc...@serck-controls.co.uk > > > > ********************************************************************** > Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK > A company registered in England Reg. No. 4353634 > Tel: +44 (0) 24 7630 5050 Fax: +44 (0) 24 7630 2437 > Web: www.serck-controls.com Admin: p...@serck-controls.co.uk > A subsidiary of Serck Controls Pty. Ltd. > ********************************************************************** > This email and files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please notify > the above. Any views or opinions presented are those of the author > and do not necessarily represent those of Serck Controls Ltd. > > This message has been scanned for malware by SurfControl plc. > www.surfcontrol.com > > _______________________________________________ > 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 _______________________________________________ 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