Best Practice for following Subversion repository Trunk: Git (Mirror), Git-Svn, Subversion?

Question

I want to checkout, and then update as necessary, the Django Subversion trunk on a Mac OS X Leopard 10.5.5 machine.

I am only interested in having updated Django code on my Mac. I am not interested in contributing patches to the Django project. I do not need the Subversion history for the Django trunk.

I plan to use Git as the DVCS/SCM for all of my personal projects.

---

What is the best practice for keeping my Mac updated with the latest Django trunk and why?

I am new to Git so understanding why you chose your option will be very helpful.

1. Use Subversion 1.4.4 installed on my Mac: svn co http://code.djangoproject.com/svn/django/trunk/. Essentially using Subversion to fetch Subversion repos and Git for my personal projects.

2. Use Git SVN to fetch the Django Subversion repo. Instructions on how to do this for a Git newbie?

3. Use Git to fetch a Git mirror of the Django repo. I'm a little concerned that the mirror might go away in the future, but I'm willing to use it if it's the best option.

Answer 1

If you're not going to be making changes to the Django code, then there's no reason to import it into Git. Just use option 1.

Using git-svn (either by running it yourself or by cloning somebody else's repository) is useful if you want to make local modifications to a project that uses Subversion (whether or not you send any of those modifications back to the project). But if you're not making any local modifications, then it's just needless complexity.

Answer 2

Well, if you are using git for all your projects and you are reasonably familiar with it I would suggest to use the git mirror, as it seams to be reasonably up to date. Git should also be faster than using Subversion. If the mirror goes away / gets outdated you can always just svn co / svn up to get the current source.

But as you also have Subversion installed - you could also just use it instead ... doesn't make a big difference and is more a question of personal preference.

Git-svn is a little more tedious to setup and keep in sync - you have to fetch the subversion updates first using git svn fetch and then doing a git svn rebase to apply the changes to the git repository. It will also use up more disc space. This is somewhat more error-prone and I would only recommend using git-svn if you actually wanted to do development on the source tree. If you feel adventurous and want to give it a try have a look at this Tutorial - i found it quite useful to get going with git-svn.

Answer 3

Better late than never.. maybe.. I have to disagree with the current winning answer. I would go with

1. Use Git to fetch a Git mirror of the Django repo

About the argument against it : someone who is (or wants to be) comfortable with Git, should not find it "just needless complexity". Note: the argument might be valid for the git-svn case, for some people (not for me).

Some reasons for it:

• speed

• powerful queries (log) and visualisation (gitk & even fancier cousins)

• less disk space in most cases

• bisecting - eg. trying to isolate a regression, helping out with better bug reports

• consistency -if all other project are in git

• even if you don't plan to contribute yet, you can experiment with local changes easier

• if you do change your mind - you can still be one step closer to contributing

Even if that mirror goes away, you can still switch over to another mirror, no need to clone again.

BTW, the current mirror is at https://github.com/django/django, and it's said to be official.

Answer 4

I agree with @cjm. If you just want a copy of the Django sources, use plain Subversion.

My experience with git-svn is that it is most useful for people who prefer and are more familiar with Git who have to track a Subversion-repository, and not so useful to people who are know Subversion but are git-newbies wanting something better than Subversion. There are several limitations to git-svn stemming from the fact that Subversion has inferior merge tracking, and unless you have some substantial git experience those limitations will jump up and bite you at times.