I am a big fan of Git, the distributed source control system created by Linus Torvalds and using on the Linux kernel. The system is really fast, and it is so configurable that it makes life really easy (at least after you learned enough about how it works).

But the reality of the of industry is still very different from what we can do on open source. Companies don’t want a distributed system, because they like to have control of code in a central location. That is why not even Google is using Git these days (they use Perforce, a closed source control system).

The big advantage of Git, however, it that is doesn’t need permission from management to be used in your local machine. And since Git works on a local machine is well as in a server, this is all you need to have a lot of fun.

Playing with Git and Svn

My first try at Git was as a local client for Svn. The general idea is that you can get Git to checkout your project and translate all Svn information into its internal format. That way, you can work with Git locally, and after doing your local development, push the commits to the Svn server.

That worked for me for some time, as I was learned as all pieces worked together. The problem that I had, however, was due to the fact that the Svn importer for Git is not as stable as Svn itself. That is, from time to time there would be some problem in the import/fetch phases, and since you depend on the importer to get anything from Svn, you are in pretty bad shape if that happens.

It also contributed to my problem the fact that my project uses non-standard names for branches, and that they are moved from time to time (don’t ask me why).

I learned the hard way that it maybe easy to use any one of two version control systems, but it is not so easy to mix them…

Trying Git a Second Time

My next try was to use something a little easier. Instead of using Git full time as an svn client, what I do now is to use svn as always (through Tortoise-svn). Then, on top of Svn, I use git to handle changes between Svn commits.

The setup is really easy. The first step is to have a normal Svn tree. Then, use the command

git init

to create a .git directory. Since Git uses only a single directory to hold all its internal information, it will not interfere with the information kept by svn itself in its .svn directories.

Now, I can just hack and commit code on git as I go. Then, when a feature is complete after several small iterations, I can do a Svn commit. I can even decide to spend a long time working on Git, and then go back and make incremental Svn changes. I can also decide to keep hidden branches on Git alone, and merge then only when needed to check in to Svn.

All this can be done without much trouble. The only added work is that I need to do some extra commits to Svn, to make sure that my work is integrated with the other developers, but the fact that everything was ready on Git makes things much easier — I can even use the same summaries.

Conclusion

As any interesting idea, this is one is not new. I just did a quick search on “using git with svn” and found at least another person that uses this idea (see references). Which also means that I am not the craziest developer either.

I am still tweaking my setup with Git and Svn. For example, it is useful to add the .svn directories to .gitignore, as well as other binary files. However, everything has worked Ok, and I feel that this is a good solution for some problems we have when using Svn alone.

References

• Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development
• Progit: tutorial

Related Articles

• Why a large code base is a liability
• Using SVN merge tracking effectively
• Keeping your users in control

Similar Posts:

• Using Git Efficiently
• Day 3: Keep a Programming Diary
• Using SVN merge tracking effectively
• How is Your Software Designed?
• First Impressions of Lotus Notes 8