It had been noted at the time when subversion came out that it was
just a stop gap measure. Essentially Subversion is CVS with some of
it's more glaring rough edges polished. As recently as last year I'd
been arguing that considering SVN as a migration from CVS was a
pointless exercise. In the end I just gave up, mirrored the CVS
repository with a few scripts to import into git and did my
development in git and exported when I needed to.
One thing SVN does have going for it though is the git import tools
for it are more stable than the CVS ones. If a project I'm interested
in hacking is still on SVN and doesn't already have a git repo
associated (most projects usually have at least one git fan already)
then I git-svn import it myself. I'd rather leave it to the core
developer/release teams to decide by themselves what they want to do
than adding my own 2p with a "Please considering migrating to..."
Distributed VCS are the future. Personally I'm a fan of git but there is
scope for many different tools out there. Pretty much all of the open
source options have a good selection of import/export facilities that
allow non-core developers to use whatever their pet favourite DVCS is
to marshal their upstream patches. I'm hopeful that because of this
VC migration will be less of the barrier that it has been between the CVCS
and DVCS generations.
Obviously anyone considering a proprietary non-DVCS system to store
their open or closed source code in these days needs their heads