bzr branch lp:trunk_project merge_temp_dir
cd merge_temp_dir && bzr merge ../your_original_branch
vi path_to_the_conflicted_files #and make your merges
bzr resolved
bzr commit -m "resolving commits."
bzr push --overwrite lp~myusername/path/to/my/branch

I hate this. And I’m storing it here so I can reference it in the future.

If 2 fails, google substrings of the error message.

Only after several failed iterations of this process should you bug your cool programmer friends. You’ll be glad you did. They’ll be glad you did.

And, if you actually needed to ask your cool programmer friends for help (or discovered the answer yourself in spite of failed searches) you should make a public blog post with the error message itself in the title and the entire problem you experienced (with solution) in the body.

In this way, you are improving the internet and making the next guy’s life easier. Also, writing about the solution will help you remember it yourself next time, so it’s a double-win.

I figure, eh, I can build a package. So then I download the source and do the make dance. After a bit I get to:

Package lua5.1 was not found in the pkg-config search path.
Perhaps you should add the directory containing `lua5.1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'lua5.1' found

And that’s where I got stuck after several googles. The internets were unkind to this problem.

So I stepped away for a bit, and when I got back to the computer I decided I was probably approaching this from the wrong angle. At which point I did a search on macports and found lua-lua-gd.

Ratholes aren’t fun. Sometimes it’s best to take a step back instead of pounding a round peg into a square hole.

Global setup:

Download and install Git, and then…

git config --global user.name "MY NAME"
git config --global user.email MY@EMAIL.COM

Next steps:

mkdir
cd MY-NEW-REPOSTORY
git init
touch README
git add README
git commit -m 'first commit'
git remote add origin git@github.com:GITHUB-USERNAME/MY-NEW-REPOSTORY.git
git push origin master

Existing Git Repo?

cd existing_git_repo
git remote add origin git@github.com:GITHUB-USERNAME/MY-NEW-REPOSTORY.git
git push origin master

sudo chown -R www-data .

(replace www-data with whomever your apache user is if it’s not www-data.)

Yeah, that’s it.

What ensued was 10+ hours of hell. Here are the high points:

• You need the matching Macbook Pro OS X Install DVD to the hardware version you have. This is very frustrating because I had my girlfriend’s previous-generation 13″ Macbook Pro disc, but couldn’t find my own.
• Apple is retarded for not putting Bootcamp files on their website downloadable by all.
• the 13″ macbook pro didnt have a working sound jack even after running bootcamp. The sound drivers are at http://www.cirrus.com/en/products/pro/detail/P1233.html

The fun part is that my next-door neighbor had borrowed my Macbook Pro’s Install Disc a day or two before (nobody informed me). He’d done it to make a master image to avoid just this sort of hell. He was very sorry when he found out my plight. ;(

sudo apt-get install sun-java6-jdk

The internet is filled with false paths involving

sudo apt-get -u install java-package

and

fakeroot

and

make-jpkg

.

None of that is necessary anymore.

Two years ago I ran into a problem with my SVN filesystem and got “Could not open the requested SVN filesystem” as the front-end error.

This appears to be an annoying catch-all error for “shit is broken with your SVN, dawg.”

Last time, it was because I had SVNPath defined in my apache’s httpd.conf file instead of SVNParentPath (when I had many repos in the same root directory.) This time I did not have that problem, but I did have the same error message.

That is annoying.

After several dead-ends, the vital kernel of information came from Mr. Mike Rooney’s suggestion to go to the host server itself and run:

sudo svn ls file:///path/to/local/repo

The two important parts here are that I’m trying to access the bjorked repo from the local filesystem, so the webdav layer isn’t being retarded at me and giving me the same enigmatic error message. The second important part here is that I’m running sudo to get past possible permission problems.

That command produced the following output:

$ sudo svn ls file:///path/to/local/repo/
svn: Unable to open an ra_local session to URL
svn: Unable to open repository 'file:///path/to/local/repo/'
svn: Berkeley DB error for filesystem '/path/to/local/repo/db' while opening environment:

svn: DB_VERSION_MISMATCH: Database environment version mismatch
svn: bdb: Program version 4.6 doesn't match environment version 4.4

At this point, I used the tried and true google-the-unique-error-message technique. After googling “svn: DB_VERSION_MISMATCH: Database environment version mismatch” (including the quotation marks for an exact search), I found this blog post that solved my problem.

Here’s the punchline:

$ cd /path/to/myrepo/db
$ db4.4_checkpoint -1
$ db4.4_recover
$ db4.4_archive
$ svnlook youngest ..
$ db4.6_archive -d

BUT…

The double-punchline that screwed me for a while was the fact that the berekley db utils for 4.4 were unavailable via apt-get in modern times. Thankfully, long-time systems-administration bad-ass Ted Reed was here to suggest the following set of commands:

$ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/db4.4/libdb4.4_4.4.20-12_i386.deb
$ wget http://mirrors.kernel.org/ubuntu/pool/universe/d/db4.4/db4.4-util_4.4.20-12_i386.deb
$ dpkg -i libdb4.4_4.4.20-12_i386.deb
$ dpkg -i db4.4-util_4.4.20-12_i386.deb

All of these commands (run as root or through sudo) grab the neccesary files from arcane places and got them installed. After that, the previous blog post’s wisdom could be applied. From there, I was a chmod, a chgrp, and a chown away from actually being able to access my old repository again.

Of course, this was about 10 hours after where I expected to grab my old repo’s contents…

Specifically the searchbox partway down the page under “Search package directories”.

Yeah, hat’s about it.