Regarding the "Experimental Testbuilds" Workflow/Setup...

I've never been really comfortable with the workflow that's in place for doing the experimental testbuilds using the buildbot infrastructure on b.org. Specifically, there are two weaknesses in the current scheme (and also the previous one):

1. Needing to push squashed commits and revert them via a publicly visible branch, on the canonical reference repository when using a distributed version control system is quite ugly. It amounts to polluting the project history (which everyone has a copy of) with 3 commits per build, in order to satisfy the arcane requirements/limits of a centralised single-instance service/tool - which, not everyone can really use to create builds.
2. The sequence of steps required  to generate one of these test builds is convoluted and prone to user error. I've gone back and counted them, and there are seven! Yep, 7 individual steps - and that's provided there are no conflicts/typos which mangle things up at some point and require more drastic interventions.

[Second Attempt] Getting Ralink RT3290 Wifi working on Linux Mint 15 (and HP Envy 17)

Last year, I posted a short tutorial about a failed attempt at getting a stable wifi connection on HP Envy 17 under Linux (Mint 15) with the crappy Ralink RT3290 card it uses. Initially, things looked promising with that fix... that is, until I was about 90% complete writing that article, and the whole machine locked up, in what I soon came to learn was known as a "kernel panic".

Yesterday, in preparation for a potential repartitioning attempt sometime "soon" to resolve some upcoming disk-space availability issues (i.e. I initially set aside > 500GB of my disk for Linux, but since I'm not using it that much now, the measly 200 GB for Windows is almost exhausted now), I finally got around to uploading to Github the sources for the patched driver I've had running on Linux since my last post.



Quick Links + Instructions
* The sources can be downloaded from:
 https://github.com/Aligorith/ralink3209_drivers/tree/x64_PanicFixesPorted
(NOTE: To be clear, you need to be on the "x64_PanicFixesPorted" branch, NOT the master)

* IIRC, you should be able to just compile that straight (without any further tweaks), and then install it as per the instructions in my previous tutorial.

Thoughts on Rebase-Based Git Workflows - Rebase Considered Harmful

Personally, I'm not a fan of the "rebase" tool in Git workflows. Having initially tried it when starting out using Git over 2 years ago, abandoning it not long afterwards, and finally having to (grudgingly) start using it again for Blender's repos, IMO, it ends up being more of a hassle than benefit.

In all my other repos, I've settled on using an GitFlow-inspired workflow, which I think works better in the long run for distributed/parallel development streams with small granular commits - something we're slowly migrating towards. This post discusses some of my concerns with rebase-based workflows, and the kinds of issues that arise from using it.

Blender Git Migration - Productivity Tips for using Git Gui

As I've written about before, IMO the "Git Gui" frontend is one of the best tools around. Sure, it looks butt ugly - like some nasty 90's relic when run on anything other than Windows (surprisingly!) - but what it lacks it more than makes up for in terms of being 1) flexible and easily extensible, and 2) it very clearly exposes you to the Git tools and workflow as it was meant to be done.

For all the pretty gloss and extra OS integration that all the others offer, you'll find that they fall down miserably on these fronts, and eventually end up just complicating things a bit.

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 Blender.org repository. For everyone else, the

git clone --recursive git://git.blender.org/blender.git

on the wiki is the recommended procedure.

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

Git Tip - Reverting latest bad commit(s), and which have also been pushed already

By and large, working with Git is "not that scary" (TM) once you figure out a safe subset of commands which will let you achieve what you want to do during a typical work session.

However, from time to time, especially when effectively "working blind" via commandline, things go wrong. Really really wrong.

Getting Git + SSH to play nice with the COSC Servers...

This post is more of a little reminder-to-self should I forget how to get this working again in future. The intro below gives a bit of background info about the situation of how I came to be using Git, but also the troubles trying to get it to work with the SSH/Remote access to my department's Linux servers.

Git Tip - Attaching Local Branch to Remote

So, you've just pushed your local repository off to some external server for the first time, and now you'd like to grab some changes back off that server (just like when using SVN) that you'd made from some other machine.

Except now, when git pull chastises you for now having "No remote repository specified". Gah!

Today's tip is just a quick way around this without going in an messing with config files (I've done it once, but it was a bit hairy on some of the other repositories I tried repeating the feat on, hence the advice today).

From a posting on StackOverflow, I found the following gem:

git branch --set-upstream local_branch remote/remote_branch

In practice:
- local_branch = remote_branch  --> Unless for whatever reason you've given things strange names
- remote = the short name you gave the remote repository when you added it as a remote (NOTE: this is more convenient that trying to remember and lug around those great heaping SSH-URL's that are usually needed). For me, this is either "Bitbucket" or "Github" or "Gitorious"

Blender-Bullet Branch Online

From comments received in response to my "Bullet Todo List" post last week, there were several main themes coming through:
1) Baking, especially via Alembic support, is a very desirable prospect.
2) Phymec's work on fracturing, etc. would be nice to integrate with this (and also BGE)  at some point. This fits in the "fancy stuff" basket
3) Interactions between animated objects and physics sims (and also animating when physics sims work) is an issue that many people care about. IIRC, there is some support for this already, though your mileage with overriding simulated objects mid-sim may vary.
4) Many are just dying to get their hands on this functionality.

This last point I'll address here and now :)