There are two aspects you need to think a lot about: The first one is the
organizational one. Read this experience report from
some more ideas on what to think about (there are plenty more reports
like this around the web). The second is the technical approach, meaning
how do you physically get the the code and history out of SVN and into Git.
In combination of these two aspects, you need to decide whether you want to
do either or a combination of these migrations:
1) a gradual migration, where you migrate subprojects/teams one-by-one
2) a backward compatible bridge-setup (like the one I've documented
where people can try out Git while still using Subversion at the same time
3) a complete cold-turkey migration, where people leave the office one day
having used subversion, and the next morning everything is in Git (requires
a *lot* of preparation, a few failed attempts, and pulling off an
all-nighter for the final migration).
Before you decide on a strategy, it is wise to start experimenting with how
a migration can work. I find the best way is using git-svn, and just clone
*something* out of the SVN repo, and see how it works. git svn clone
[url-to-project] and off you go.
It is possible to do a git-svn clone of the entire Subversion repository
into a huge Git repository, and then start splitting it into smaller
repositories using filter-branch. You could try this to simulate how a cold
turkey migration could work.
Once you have some experience on these strategies, you can start thinking
about how to work the svn:externals into this. Perhaps
git-submodules<http://git-scm.com/book/en/Git-Tools-Submodules>is a good fit
for them, or a different tool like
Depending on your organization, be prepared for weeks or months of hard
work for this to come through, plus a lot of organizational resistance.
You'll probably have to become a Git/git-svn guru on the way in order to
On Wednesday, September 26, 2012 12:04:49 PM UTC+2, GadgetSteve wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Hi All,
> We have a large project with several sub-projects all SVN with several
> thousand commits, branches, tags, etc., and to allow the development of
> the sub-projects to proceed with different teams our main project
> references them as externs at fixed revision numbers - we would love to
> move over to running GIT but do not wish to loose the history of the
> I have been able to figure out that I need to make the externs into
> sub-projects but not how to populate them at specific revision numbers
> but what we would really like to do would be to create a GIT repository
> that replicates the SVN structure and history including creating and
> populating the sub-projects at the specified revision number at the
> appropriate points in the project history.
> Can anybody suggest a good way of going about it?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (MingW32)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> -----END PGP SIGNATURE-----
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To view this discussion on the web visit
To post to this group, send email to email@example.com.
To unsubscribe from this group, send email to
For more options, visit this group at