Saturday, November 16, 2013

Blender Git Migration - Getting the sources for devs with commit access (as of Nov 16, 13:57 UTC)

As you may have heard, Blender development is finally moving over to Git. This is the second version control system switchover that's occurred over the years that I've been involved in Blender (the first being the CVS to SVN switch; and event that I still remember!).

After several delays, the repository is finally in place this evening, so I tried cloning (i.e. grabbing the sources) from this repository to get my dev setup with this sorted out again. Thanks to Sergey for help resolving some of the issues I encountered - hopefully many of these will be resolved by the time many of you start using this for real.

NOTE: These notes are only for developers with commit access to the main repository. For everyone else, the
git clone --recursive git://
on the wiki is the recommended procedure.

EDIT: Also, I'd strongly recommend using the setup I describe in my followup post.

(*) UPDATES NOV 16 - 14:33 UTC:
- The permissions problems with other repos seems to be fixed now. The hacks below shouldn't be needed unless you run into any difficulties
- With "older" versions of git (e.g. - standard on Linux Mint 15), you'll want to use "git submodule update --recursive" instead of "git submodule update --remote" (which isn't a supported parameter). My original suggestion below works as a quick fix, but isn't what we want to be doing in the long term.

1) Cloning the repo
git clone --recursive

There were originally some permissions issues on the server, but these should be clear now. You may need to enter your SSH key password.

2) Resolving issues with submodule repos you don't have commit access to  (*)
Currently there are some issues where using the "" way of cloning breaks when dealing with submodule repos that you don't have commit access to. In my case, the offending repo is the translations one.

According to Sergey, you'll currently need to go into the ".git/config" file and fix the entries for the offending repos by changing the url's for those from "<offending_repo>.git" to "git://<offending_repo>.git"

In my case, I ended up just simply commenting the whole thing out, to save downloading it at all (since I don't use/need it anyway).

WARNING: You'll need to be careful to ensure that these hacks don't end up getting committed to the main repository. I'm not sure yet what I'll need to do to ensure this doesn't go astray, but I'll check on this again tomorrow.

3) Getting the updates working for the missing submodules (*)
When the first submodule clone operation fails, all the remaining submodules are also skipped. To get things moving again, simply use:
git submodule update


Hopefully the remaining issues will be sorted out soon, and the notes here are no longer needed :)

No comments:

Post a Comment