This question is similar to this one and this one, but the scenario is slightly more complex.
I started out a few years ago with a private svn repository (which I use mainly for shared config files and the like between various machines). I wasn't too careful with the layout of the repository (where branches, go, etc.), so it changed quite a lot over time. This was, of course, a mistake, but it's too late now. More recently, I've migrated it to a more standard svn trunk/branches/tags layout, mainly with svn move commands, but of course the old history is still present in the repository (and is, frankly, a bit of a mess).
I'd now like to convert this permanently to a git repository. I've tried using git-svn, but it only seems to handle situations where a consistent trunk/branch/tag convention has been followed (yes, you can provide alternative names, but only one for each, it appears). Quite a lot of the history of my repository has trunk effectively in the root of the repository, for example, with tags/ and branches/ as sub-dirs.
What's the best way to handle all of this? Ideally I'd like the git repository I end up with to at least have all the history accessible in some way, even if the branches and tags aren't properly represented as first-class concepts in git.
More specifically, how will svn-git handle files outside the trunk/branches/tags subdirectories it's provided with? My observations so far are that it misses them out sometimes (definitely not OK), and other times adds them to the new repository.
Any thoughts would be appreciated.