Bullet SoC - Doing the SVN Dance - Part 1

In order to start work on this project again, especially on Point Cache support, I figured it was time to grab a more up-to-date Blender trunk to work from, since many things have changed there AFAIK, not to mention in a few other places too.



The "Traditional" Approach
Those people who've heard one or two things about SVN (the revision control system we use for the codebase) or even the developers of it, would say "Why don't you just do a merge to HEAD?"

If you fall into this category, please read this before continuing. Basically, SVN's "merge" capabilities ("log" capabilities are equally bad, especially in TortoiseSVN's GUI) are both sluggish (especially on a stressed server located half-way around the world, though even a server several blocks away on campus is still quite bad) + fickle to work with (it's very easy to get conflicts or missing changes from specifying the wrong bounds for the merging).

It doesn't help when the server's SVN version is several years old (IIRC, it's something like 1.4.x or worse, which means that the "improved" merge-tracking stuff isn't available) or that the version of TortoiseSVN I updated to a few months ago is even more defunct than older versions in this regard (put simply, it refuses to do anything at all when clicking through the merge dialogs, even after trying every last combination of options).

Furthermore, to compound this misery, consider that the branch that you need to merge changes from trunk into was created about over half a year ago, and hasn't had a single merge from trunk in that time (given the defunctness of the TortoiseSVN version involved, and the desire to limit downtime appeasing the svn gods).

The Turnaround
Having worked a bit with command-line SVN now (thanks to becoming the de-facto SVN guru a SE group project at uni), I finally felt comfortable enough with using "vanilla" SVN to install such a client on my computer.

Among the benefits this brings is that now I can finally delete the old SoC branch that I never used (stupid (Tortoise)SVN refused to overwrite the existing branch when trying to branch trunk for the current branch, but TortoiseSVN doesn't offer any way of deleting branches that don't exist on your HD!). Another is that now I also get the revision numbers in my splash screens (I was too lazy to install commandline SVN for JUST that purpose when Tortoise already covered my standard SVN needs!)

A Modern Twist
While thinking through my options for how to get an updated branch based off trunk, I decided that it's probably less work rebranching from trunk and then reapplying all changes to this new branch, given that most of the changes were fairly localised.

However, the problem of keeping this up to date was still unresolved.

What I really wanted was a way to just update my working copy "normally" and have the updates reflected, without doing any of the stupid merging dances. In essence, this is really what using a branch should really have been all about IMO. Any other crap about keeping track of "ancestry" really ends up compromising the basic cases.

Enter my latest idea: why don't I try and set up my working copy so that it can be updated to/from 2 different svn branches at a time? That is, doing an update from trunk works perfectly normal, but I can still commit these and other changes to my branch while I keep developing this stuff, and later on I could just commit all these changes to trunk normally too!

After a previous "incident" while trying to update Blender's copy of Bullet, I realised the branch that SVN will commit to/from depends only on what is stored inside its little private ".svn" folders. If we could just trick it into using other little private folders like this, or just replacing the contents of these directories, then maybe we have a hope of achieving this goal.

After some investigations, it looks like it might actually be possible! In particular, it helps that I'm working on Windows, as there's "Official support for Windows '_svn' directories" since SVN 1.3, which is enabled by defining an environment variable "SVN_ASP_DOT_NET_HACK". If one branch's metadata is stored in ".svn", the other's could be stored in "_svn". Defining this environment variable per (commandline) session would hopefully be enough to force SVN to only be able to "see" one of these sets of directories, which in turn would allow one branch at a time to be used.

Well, at least that's my theory, based on reading up about this option.

When I have some more time, I'll go and try to test this out for real - probably I'll need to hack up a few scripts to make this easier to do. And hopefully if this works, then my SVN branch-management problems will at last be solved... at least until I move to Linux, though by that time, we might finally have moved to a distributed VCS like git (which apparently handles merging much better - merging then will only depend on CPU speed vs Network Latency + Server Speed). Fingers crossed...