by default svn externals are not handled at all. But immediately after ‘subgit configure’ command you could do one of these things:
externals = true
option in subgit/config. This will enable bi-directional translation between svn:externals and .gitsvnextmodules file in the Git repository root. Unfortunately .gitsvnextmodules format is now obsolete. It could only be useful if you would like to write a script that would add corresponding Git submodules (or Git X-Modules — our upcoming product) into the corresponding paths with a script or manually.
You could keep ‘externals = false’ but enable “other properties” translation:
otherProperties = true
This will create .gitattributes file corresponding to all SVN properties not handled by other translate.xxx options, and svn:externals in particular. Again, the only reasonable usage of it is to write a script that would read such .gitattributes file and act accordingly. I don’t recommend to use this approach and if you would like to write such a script, it’s better to query the SVN repository directly.
So as you see, there’s no reasonable way to handle svn:externals preserving their semantics. There’s a reason for that. svn:externals properties points to some SVN server by some URL. In Git one cannot use an SVN repository as a kind of module directly. Even when this SVN repository is also converted by SubGit, there’re technical difficulties (e.g. such a repository doesn’t know its own URL because this information is beyond the repository scope; while svn:external contains SVN URL or its shorter version). So we didn’t implement any more reasonable support of svn externals in SubGit than that I’ve described above.
I don’t understand your second question regarding “deep copy”. Probably if you could reformulate it or describe the problem in detail, I could help you with that.