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<>is a good fit 
for them, or a different tool like 
gitslave <>.

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 
pull through.

On Wednesday, September 26, 2012 12:04:49 PM UTC+2, GadgetSteve wrote:
> 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 
> project. 
> 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? 
> Gadget/Steve 
> Version: GnuPG v1.4.11 (MingW32) 
> Comment: Using GnuPG with Mozilla - 
> dJIOzXR84CLmU942o8LyCVTm1FMWOw/ZTnkI7KRQrjBGQ5sRD8z4kkS1BeB7hFtN 
> hljJiqpAPehCeW/PoB+EcxJWnhbwdVVfBICFuzTXTJb8+hNI84+/TAd2PPQucUTC 
> /Lq4Wie90IJbRlhSITC5wJz347lu+wBJs+uj9GkUp08NMrwC8h9rmLQNHHrYyxVG 
> byai9pzvv3GpwZ/EcTdAyq/J0K3AlF0wmUZ7Zyg4jEDSkyfZSvOapzMrHmce4OzP 
> ulIKQsMZ35Nd7nr09nPKq47GSaO3NJOEtrlIx61vwJfO4zn8zHf5HCaDukzo30c= 
> =AGCt 
> -----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
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to