If you already have the "mess", git and the submodule options are
probably the best way to go in the process of cleaning up.
If you are in the position to influence/enforce the "next generation
work flow" I would recommend to get into the submodule setup details
anyhow, even if the initial "expense" is high. But I would only do that
if the cores in the submodule is considered a clean library with (maybe
automated) unit tests, so you can immediately see when things break. If
changes are required, have the hacking happen on another branch...
The thing is, it can get really nasty when switching branches with
corresponding external modules that are of a specific revision (like for
buggy IP referred by a wrapper with workaround, so updating the bugfix
will break everything upward). This is where SVN would force to more
discipline, your team would need to stick to a possibly less 'agile'
test/development strategy.
You'll definitely have to do the math for your IP collection and find
out if it can be better maintained in a reasonable number of branches or
better in the submodule 'library style' setup. On the other hand, you
wouldn't want too many svn:external alike references.
> I looked at git submodules/subtree/subrepo, but the learning curve seems
> a bit too steep for my coworkers. and I am not sure if it is worth it.
>
If you can be (or make one guy) the git expert, you can fix up a lot
later on by reorganizing branches the surgical way. In fact, I did quite
a bit of cleanup work by just chucking the whole IP tree into one big
repo, and then split off the common 'library' stuff into a cleaner
separate repo, later used as submodule. This cleanup work is a lot
harder to do in SVN (history is never forgotten..)