I’ve been using it for a week or so now.  It’s pretty useful.  Those times when a phone call is too disruptive, and you don’t want to/can’t type a text message is the perfect use case for this app.  In fact, I can see it replacing text messages for several of my contacts.  It’s found it’s way on to the first page of apps.  The only real blemish with the app is how it handles your contacts.  There is no way to tell if you can send a message to a particular contact.  If you send a message to someone you haven’t friended, it sends them an invite to download the app along with a URL they can use to “friend” you.  There needs to be some way to tell who your friends are (i.e. show me the list of people I can talk with).  Overall, it’s been a useful tool  already and is worth checking out.

• mac-mini quiet, fast, flexible.
• Plex Really nice XBMC fork to work as a media center.  Can launch other apps, comes with a server for iTunes/iPhoto from another box.
• RemoteBuddy Software that makes the apple remote more useful.
• RipIt DVD -> Hard Disk
• HandBrake Ripped DVD -> Video

I recently picked up a mac mini to plug into my television.  I’m a mac user in general, and the mini seemed like it would make a good htpc.  I hadn’t really done much research on it, but I figured I could make it work.  I have to report, yes, it works, and it works very well.  Getting things running smoothly took a little bit of work and a few dollars (beyond the cost of the mini).

Hardware
Not much was needed beyond the mac mini. I picked up the late 2009 refresh of the mini (low end) which has been more than fine. I needed to pickup a mini display port to VGA adapter, and the goofy 1/8th inch to toslink cable. I also ended up getting the aluminum apple remote (to assist in doing the multi-code remote hack I’ll discuss later). VGA to my TV, toslink to my receiver, power cable, and I was ready to go.  Since I’m running the mini wirelessly, I needed to pickup a dual band G/N router (I need G for my phone, old laptop etc).  I got the WRT610n V2 and promptly put dd-wrt on it.  Works great, simultaneous G and N.

Software

Plex

The first piece of software is my main media center application. For this I’m using Plex. This is a really nice fork of the fantastic XBMC project.  It is tailored to OSX, as such it integrates nicely with iPhoto, iTunes, DVD Player, and other OSX media apps (including Hulu Desktop, Boxee, etc).  It has plugins that support Hulu, Netflix, last.fm, etc.  I’ve been underwhelmed by the netflix and hulu plugins.  I generally end up using netflix on my xbox, or running Hulu Desktop.  The ability to launch other applications from within Plex make it an ideal “hub” for all of my media applications.  Once nice feature is the built in Plex Media Server.  I have all of my content (Music, Movies, Pictures) sitting on my desktop machine.  The Plex Media Server allows me to serve my iTunes and iPhoto libraries from my desktop to Plex on my mini.  For movies I just have an AFP automount setup (seems to work well)

Remote Buddy

The next piece of software, and the glue that really holds everything together is Remote Buddy.  This software basically presents a customizable menu that you can drive with your apple remote.  The menu allows you to launch applications, turn your remote into a mouse, and play movies/audio directly.  Remote Buddy calls each of these different contexts behaviors.  For example, when I switch to the Plex behavior, Plex is launched, and remote buddy knows that when I hit the pause button on my remote, that it needs to send the spacebar to Plex.  Remote Buddy  has built in configurations for Hulu, Boxee, Plex, iTunes, iPhoto, Finder, etc.  It really improves Apple’s pathetic remote handling (7 discreet codes, really apple?  is that the best you can do?).  The apple remote can only send 7 discreet codes (14 if you count holding down a button as a new code).  This hack allows you to create limitless button mappings with a programable remote.  I think RemoteBuddy costs about 20 bucks, and is well worth it.  Makes my whole system work without having to break out a keyboard/mouse.

RipIt

The next piece of software is one of two things I’ve been using to slowly get my DVD collection onto my computer.  When I started I was using HandBrake to both rip and transcode.  This worked pretty well, but the ripping took forever, and was difficult to do in bulk.  Enter RipIt.  I was introduced to RipIt by the most recent MacHeist.  It seemed interesting so I grabbed a demo.  All this application does is rip DVDs (there is a beta transcoding feature that doesn’t work very well).  The good people at The Little App Factory have started a DVD identification service so RipIt can accurately name the discs you rip with it.  The workflow becomes: insert disc, when disc ejects put a new one in.  This allows me to get the raw DVDs into a place where I can start to transcode them in bulk.  RipIt seems to be faster and more reliable than HandBrake’s DVD ripping feature.

Lastly comes the transcoding software.  For this task I am continuing to use HandBrake.  It threads nicely on my Mac Pro and has done everything I’ve asked of it (subtitles, multi language, etc).  I’m using the MKV container format because it seems a bit faster as it doesn’t have to touch AC3 audio.  I’m still mucking with settings, but the video quality is quite good.

Overall I’m really happy with the mini as an HTPC.  It’s quiet, and I can do more with it than just play movies/music.  My kid plays her games on it, and I’ve been using Google Earth to show her where various places are on the planet.

Enter Virgin’s broadband2go service.  The usb adapter costs ~145 and includes a micro SD card slot (lets you use the thing as a thumb drive).  The device is the Novatel MC760 (pictured). The pricing is decent for my needs as well (they’re steep for heavy use, but I’m not a heavy user).  The pricing ranges from 10.00 for 100mb to use in 10 days, up to 60.00 for 1G to use within 30 days.  In my mind, paying 10 bucks for a few days of light net usage occasionally isn’t too bad.  The speed is definately usable for browsing, and shell work.  I haven’t taken the time to run a bandwidth test on it.

One note, if you use a Mac you’ll need a windows box to get the device activated (I was able to use an XP vm in fusion).  Once activated it works great.  The device comes with drivers that will install the first time you plug it in.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> tree repo
repo
`– myProject.trunk
1 directory, 0 files

Just my trunk branch in the repository.  All of these files (the .bzr, the directories etc.) are owned by me.  I should be able to do anything I want in the repository.  Like creating a new branch.  So, I have my trunk branch, and my first release branch in the repository.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr branch repo/myProject.trunk repo/myProject.R1
Branched 0 revision(s).

[andrew karma] /Users/andrew/Development/BZR
>>>>>> tree repo
repo
|– myProject.R1
`– myProject.trunk
2 directories, 0 files

Testing with various permissions

Below is a table of various permission settings and the directory/files I applied the permissions to.  I chowned all of the files to root:wheel and messed with the global permissions.  In actual production you’d want to use some combination of group permissions/setuid bits/umasks to make sure everything works.  So, when I list the permissions below, I’m only referring to the permissions I had on  the specified directory/set of files.  x was only ever set on directories.

Conclusion

So, permissions in bzr work about as I expected.  The only time you really care about permissions on any directory other than the .bzr directory (and its contents) is when you want to create a branch.  Creating a branch requires rwx on the branch target.  To create a read only branch you need to give your users r-x permissions on all of the files in the .bzr directory.  To allow them to write, they’ll need rwx.  The next trick is to figure out how to manage these permissions.  There is a tool called sheila for CVS that handled doling out permissions as needed.  I’ll need something similar for bzr.  Another way to approach this issue is to look at the hooks provided in the bzr server.  I’d like to not have to mess with groups/file permissions if I don’t have to.  Having restrictions enforced by the software controlling the commits gives me a bit more flexibility.  Perhaps for my next post I’ll dig into that a bit.  As always, let me know if you liked this, or if you have any other comments.

Mockups

I’ve used two basic strategies for developing UI mockups.  First is hand drawing/using some tool like visio.  Hand drawing is fairly inflexible, and the tools I’ve used have been fairly clumsy.  I’d love to use something that is as quick as hand drawing, that still has the flexibility of using software.   A second method of generating mockups is to write user interaction code to drive the mockups.  While this method is also time consuming, ideally you will end up with some usable code.  When you show the design to the user, you can actually demonstrate how things will work in a live environment, this too is a good thing.  If your initial design is too far away from what the user wants, you may end up having to throw away work you were hoping to use later.  I know we don’t have time for this in our organization, I doubt others do either.  I think it’s useful to develop a set of hand drawn/computer drawn mockups to help present different design options to your potential users.  Once you have an idea of what they like/dislike, you can start working on the coded interaction.  This way, you are helping to ensure that you are effectively using your time.

Balsamiq Mockups

I have not spent a lot of time looking for other software in this space, so I don’t really have much to compare to, however, Balsamiq Mockups seems to provide the speed of quickly sketching a mockup, with the flexibility of using software.  There is a video on their website that shows the tool being used to generate a mockup of a familiar music player.  This is done surprisingly quickly and accurately. To the left is a picture of the main screen.  The lower portion of the screen is your canvas, and the top contains the toolbar of widgets.  There are a ton of widgets to choose from, including iPhone specific UI elements, and some OSX specific elements, like coverflow.  To start creating a mockup, you can either drag widgets from the pallet, or use quick add to search for and add widgets.  One of the more interesting widgets is the data grid.  This  widget allows you to draw a table with your own data inside.  To enter the data you simply double click on the widget and start typing. Columns are separated by commas, the first row is your table header, and you can use special sequences like [x] to indicate things like a checked checkbox.  Being able to use your own data inside a mockup is a great feature of this tool.  Balsamiq handles things like scrollbars, window actions, and other common UI elements very well.  As you can see, the visual style of the mockups look hand drawn, which I actually like.  I haven’t spent that much time using Mockups yet, so there may be some quirks I’m not seeing, but it looks like a potentially useful tool.  I’m looking forward to trying it for my next design.  One thing that is missing, according to their website, is the ability to add custom widgets to the toolbar.  At my job we have some standardized UI components, like headers, that I would love to be built into the tool.  You can save and import your own templates, which addresses the issue, but putting them in the pallet would be great.  I’d like to be able to point the data grids at a text file rather than having to enter the data in the program (I only spent a minute looking, so this might exist).  This would make re-using the same data-set across multiple designs easier.  Overall, I’m very impressed by the software, and it seems reasonably priced at ~80.00 USD.

First Steps

After doing some research I ran across Linode for my hosting solution.  They were offering everything I wanted for not a ton of money.  I get a pretty fast box, with 36oMB of ram, 12G of disk an 200G a month of transfer.  This seemed like more than enough for me.  I get full control over the machine; I can reboot/reinstall/do whatever I want.  They even provide a remote console in case something goes wrong.  They give you 10+ common linux distributions to choose from for the base install.  The process was as easy as: pay them, pick your distro, click go.  30 second later I had my vanilla install.

I needed a domain name so I went to godaddy and was underwhelmed by their site.  Their service was actually very good, but I really had to dig around to find what I was looking for.  They also really try to attach every possible service in the world to a simple domain.  In the end I just got the domain and privacy option (doesn’t expose stuff like my home address under whois).  As soon as possible I transferred DNS for the domain over to linode’s dns servers.  This process was quick and painless.

I think it took me about an hour from getting off my butt to get this setup to having a machine and working DNS.  All of this happened on a Sunday afternoon.  Things definitely seem to work better than they did when I had to wait for a few days for Network Solutions to turn around registrations for me “back in the day.”

Wordpress

Installing wordpress was fairly straight forward.  I followed the 5 minute install guide and was mostly running pretty quickly.  The one thing that they don’t mention clearly, that they probably should, is that you really don’t want to use the default wp_ prefix.  Leaving as default makes it a little easier for an attacker to get to your tables from vulns in wordpress.  Changing this isn’t a ton of protection, but it can’t hurt.  I did this after I was installed, so making the change was a bit of a pain, the instructions here worked fairly well.  I also followed several of the suggestions here about securing wordpress.  I also took some additional steps at the OS level.  I’m sure if someone wanted to get in they could.

There were a number of other things I wanted to get working.  Google Analytics was pretty easy to get going.  Add the slug to my template footer and it just worked.  AdSense was pretty easy as well, just added the code to a text widget.  Feedburner was really the most frustrating part of the experience.   I really wanted the feed to be a one or two hundred word summary, but I just couldn’t make it work.  The feed summarize feature in feedburner just seemed to use the wordpress auto generated excerpts which are surprisingly inflexible.  I know there are plug-ins that will deal with that, but it really wasn’t a huge deal.  I got a plug-in that can inject css into the feed so I can get a little bit of styling on my feed.

Other

I wanted to make sure I had regular backups of my system.  So I wrote a [Download not found].   It’s not anything special, but it gets me backups.  I then got awstats setup using a pretty decent reference on how ubuntu wants awstats to work.  I’ve been going against my natural inclination to do everything by hand, and letting ubuntu’s package management stuff take care of things for me (for the most part, wordpress was still a hand install).

I used google’s tools for webmasters to get my site added to google, added a plugin to auto generate and submit site-maps, and added an appropriate robots.txt.  The site is actually getting indexed now.  I’m waiting for the flood of people who want to read about bazaar. 

Closing

This has been a really fun project.  It has been interesting to see how things are done now vs. when I was setting up medical journal sites.  The parts haven’t changed a whole lot, but what used to take a month can be done in a few days.  Kudos to Google for the amount of stuff they give away.

[andrew karma] /Users/andrew/Development/BZR/myBranch
>>>>>> bzr push ../myBranch.mirror
Created new branch.

I now have a branch called myBranch.mirror in my BZR directory.  I’m going to take a look at it now.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> ls
total 0
0 myBranch/        0 myBranch.mirror/ 0 myRepository/

[andrew karma] /Users/andrew/Development/BZR/myBranch.mirror
>>>>>> bzr info
Standalone tree (format: pack-0.92)
Location:
branch root: .

Related branches:
parent branch: /Users/andrew/Development/BZR/myRepository/myProject/myBranch

At this point, it appears that a pushed branch is really no different than a branch that you’ve made using the branch command.  You can use push and pull to keep the mirror in sync, as long as the branches have not diverged.  A branch is considered to be diverged if there is a check-in in the dest that is not in the source.  You can work around this by merging the dest onto the source prior to running the push, or by using –overwrite command that will overwrite the information in the target.

One thing I’m starting to notice is that there are many ways to get to the same place with bazaar.  bzr branch/bzr bind is identical to bzr checkout while bzr checkout/bzr unbind is identical to bzr branch.  I suspect that there are options to checkout/branch/bind/unbind that makes the operations a little more convenient but they really aren’t dramatically different commands.  I think that push/pull fall into this camp.  I don’t think they do much that you can’t accomplish with branch/commit/update, but they may let you think about what you’re trying to accomplish in a different way.

Below are a number of other commands that I’ve mentioned but haven’t really talked much about.  I’m not going to go through examples, just describe what they do.

bind/unbind

Bind is used to make a branch behave like a checkout in CVS.  Commits made to the local branch will automatically update the parent branch.  In fact, the commit must succeed on the parent before the commit is allowed to happen locally.  Unbind is the reverse, switch to a mode where all commits are local.  I don’t know what all of the implications are of binding a diverged branch are.  Perhaps I’ll cover that later.

export

This is a neat command that allows you to “publish” your branch to somewhere.  The result is not under version control, it’s just a copy of your branch suitable for distribution.  The neat thing about this command is that it can export directly into a number of different formats.   For example:

[andrew karma] /Users/andrew/Development/BZR/myBranch.branch1
>>>>>> bzr export ../foo.tgz

[andrew karma] /Users/andrew/Development/BZR/myBranch.branch1
>>>>>> cd ..

[andrew karma] /Users/andrew/Development/BZR
>>>>>> ls
total 8
8 foo.tgz           0 myBranch/         0 myBranch.branch1/ 0 myBranch.mirror/  0 myRepository/

[andrew karma] /Users/andrew/Development/BZR
>>>>>> tar ztvf foo.tgz
drwxr-xr-x user/group        0 2009-04-20 22:11:14 foo/myDir/
-rw-r–r– user/group        0 2009-04-20 22:11:14 foo/myDir/test4.txt
-rw-r–r– user/group      142 2009-04-20 22:11:14 foo/test1.txt
-rw-r–r– user/group       60 2009-04-20 22:11:14 foo/test2.txt
-rw-r–r– user/group       30 2009-04-20 22:11:14 foo/test3.txt
-rw-r–r– user/group       20 2009-04-20 22:11:14 foo/test5.txt

This is a pretty neat way to package stuff up for deployment or download.  It appears that the export command understand bz2, tar, tgz, and regular directories.

revno

This command shows you what revision your branch is on.  Unlike CVS, bazaar seems to verion the entire branch rather than files within the branch.   This has been the strangest thing to get used to with bazaar, and it’s really not a huge deal.  When you revert a file to a particular revision, what you are saying is revert this file to it’s state as of version x of the branch.

revert

The revert command allows you to roll back changes in a file.  This command also lets you throw away locally made changes that you don’t want to commit.  bzr help revisionspec contains a ton of information about how to specify a revision in commands that use a full revisionspec (like revert).

I’ve figured out that push/pull really aren’t anything special, and added some information on other commands.  This wasn’t the most detailed post in the world, but I’m short on time, and wanted to get something posted.  Perhaps I’ll tackle repository permissions in my next post.

Repositories

According to the bzr documentation a repository is nothing more than the database that holds all of the branch data.  When you run bzr init, you create a repository within your branch (the .bzr directory).  There is also what the manual calls a shared repository, these are created by the bzr init-repository command.  A shared repository allows multiple branches to share the same database.  This can yield some space savings, as well as keeping everything organized.  I suspect that this organization can aid in keeping a sane permissions model.  We’ll look at that in a later post though.  For now, let’s start playing around with repositories.  First I’ll create a repository.  Remember, myRepository can use any of the remote URI specifications that Bazaar supports.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr init-repository –no-trees myRepository
Shared repository (format: pack-0.92)
Location:
shared repository: myRepository

The –no-trees option tells init-repository to not create a working-tree of the branches within the repository.  Since we won’t be working in this directory, the –no-trees option makes a ton of sense.

Looking at the repository directory shows us that it’s empty, aside form our repository database (the .bzr directory)

[andrew karma] /Users/andrew/Development/BZR
>>>>>> ls -al myRepository
total 0
0 drwxr-xr-x  3   andrew  102 Apr 19 15:54 ./
0 drwxr-xr-x  4   andrew 136 Apr 19 15:54 ../
0 drwxr-xr-x  6   andrew  204 Apr 19 15:54 .bzr/

Now, lets add our new project to the repository.  First we need to initialize myProject.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr init myProject
Created a standalone tree (format: pack-0.92)

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr add
adding myDir
adding test1.txt
adding test2.txt
adding test3.txt
adding test5.txt
adding myDir/test4.txt

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr commit -m “Initial Commit”
Committing to: /Users/andrew/Development/BZR/myProject/
added myDir
added test1.txt
added test2.txt
added test3.txt
added test5.txt
added myDir/test4.txt
Committed revision 1.

Now, lets put this branch into the repository.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr branch myProject myRepository/myProject
Branched 1 revision(s).

[andrew karma] /Users/andrew/Development/BZR
>>>>>> ls -al myRepository
total 0
0 drwxr-xr-x  4 andrew   136 Apr 19 16:05 ./
0 drwxr-xr-x  4 andrew   136 Apr 19 16:04 ../
0 drwxr-xr-x  6 andrew   204 Apr 19 16:04 .bzr/
0 drwxr-xr-x  3 andrew   102 Apr 19 16:05 myProject/

At this point myRepository/myProject behaves like a normal branch (see previous post about branching).  You can create a local branch from it, commit to it, checkout from it, etc.

The last thing I want to examine is creating branch hierarchies within the repository.  Let’s see if we can create a sub branch in the repository.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr branch myRepository/myProject myRepository/myProject/myBranch
Branched 1 revision(s).

We’ve just added myBranch as a sub branch of myProject.  Let’s see what myRepository looks like.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> tree myRepository
myRepository
`– myProject
`– myBranch

myBranch is a branch just like any other.  I would imagine that the shared repository is smart enough to merge some of the shared info together to cut down on size and possibly improve performance.  How you organize your repository appears to be a very arbitrary decision.  This is very unlike what I’m used to in CVS land.  The bzr documentation contains a great writeup of some different repository organization schemes.  That’s it for now, in the next post I’ll look at push/pull.

As I said in part one I still like the idea of a central branch, a “HEAD” if you will. I think there is also a need for “official” branches. Things like maintenance branches for each release/patch should be managed. However, I think users should be free to create their own branches for features as needed. In this post I’m going to take a look at how bazaar handles branches.

Creating a branch is very simple, you just issue the bzr branch command

[andrew karma] /Users/andrew/Development/BZR
>>>>>> bzr branch myProject myProject.branch1
Branched 2 revision(s).

[andrew karma] /Users/andrew/Development/BZR
>>>>>> ls
total 0
0 myProject/ 0 myProject.branch1/

As you can see, the branch operation created a new directory, myProject.branch1. Again, this would work with local files, remote files (via SFTP, or other protocol) as described in the documentation. Lets take a look at what myProject.branch1 is.

[andrew karma] /Users/andrew/Development/BZR
>>>>>> cd myProject.branch1

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> bzr info
Standalone tree (format: pack-0.92)
Location:
branch root: .

Related branches:
parent branch: /Users/andrew/Development/BZR/myProject

We have a complete copy of myProject, and the info says that our parent branch is myProject. Seems good. Let’s play around with committing.

First, we’ll make a change in myProject.branch1, commit it, then check to see what happens in the branch and in the parent.

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> echo “Change from myProject.branch1″ >> test1.txt

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> bzr commit -m “Committing from myProject.branch1″
Committing to: /Users/andrew/Development/BZR/myProject.branch1/
modified test1.txt
Committed revision 3.

We’ve changed test1.txt and checked it into myProject.branch1. The new text exists in the branch1 directory. Let’s see what happens when we look at baes myProject directory.

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr update
Tree is up to date at revision 2.

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr status

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr info
Standalone tree (format: pack-0.92)
Location:
branch root: .

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> cat test1.txt
Initial Content
Line added from a checkout

Looks like the base tree doesn’t know anything about what’s going on in the branch. This is what I pretty much expected. Now, lets make a change in base myProject.

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> echo “This is a change from the base myProject” >> test1.txt

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr commit -m “Change made in base myProject”
Committing to: /Users/andrew/Development/BZR/myProject/
modified test1.txt
Committed revision 3.

Now, lets take a look at myProject.branch1

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> bzr update
Tree is up to date at revision 3.

Ok, changes made in myProject don’t make it to myProject.branch1 with just an update. Lets try merging myProject down to myProject.branch1. This is what users in a feature branch would do to get changes from their main branch to stay in sync. Supposedly a simple bzr merge will merge the parent branch down into the current branch. Here’s what happens.

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> bzr merge
Merging from remembered parent location
/Users/andrew/Development/BZR/myProject/
M test1.txt

Text conflict in test1.txt
1 conflicts encountered.

Ooh, we have a conflict. test1.txt line3 is different between myProject.branch1 and myProject, bzr correctly, does not try to guess what I meant. So, we have to resolve the conflict.

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> ls -al test1*
8 -rw-r–r– 156 Apr 5 18:01 test1.txt
8 -rw-r–r– 43 Apr 5 18:01 test1.txt.BASE
8 -rw-r–r– 84 Apr 5 18:01 test1.txt.OTHER
8 -rw-r–r– 73 Apr 5 18:01 test1.txt.THIS

You can find full details on how to deal with conflicts here. Bascially, test1.txt now looks like this:

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> cat test1.txt
Initial Content
Line added from a checkout
<<<<<<< TREE
Change from myProject.branch1
=======
This is a change from the base myProject
>>>>>>> MERGE-SOURCE

.BASE contains the previous previous version, .THIS contains the current version in this branch, .OTHER contains the current version in the parent. We just need to edit test1.txt and mark the conflict as resolved. After test1.txt is edited, we have to tell bzr that the conflict has been resolved. According to the documentation bzr is smart enough to know which files you’ve resolved conflicts in and which ones you haven’t. So I’m going to go ahead and run bzr resolve

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> bzr resolve
All conflicts resolved.

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> bzr status
modified:
test1.txt
pending merge tips: (use -v to see all merge revisions)
Andrew 2009-04-05 Change made in base myProject

bzr resolve has also removed all of the .BASE/.OTHER/.THIS files. bzr status tells us that we have a pending merge. I’m going to go ahead and commit.

Now, say we’ve made a bunch of changes on our branch that need to be put into our main repository myProject.

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> echo “New file in branch1″ >> test5.txt

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> echo “Change from branch1″ >> test2.txt

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> echo “Another change from branch1″ >> test1.txt

[andrew karma] /Users/andrew/Development/BZR/myProject.branch1
>>>>>> bzr add test5.txt
adding test5.txt

We’ve added test5.txt and made some changes in test1.txt and test2.txt. Lets get those changes up to myProject.

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr merge ../myProject.branch1
+N test5.txt
M test1.txt
M test2.txt
All changes applied successfully.

[andrew karma] /Users/andrew/Development/BZR/myProject
>>>>>> bzr status
added:
test5.txt
modified:
test1.txt
test2.txt
pending merge tips: (use -v to see all merge revisions)
Andrew 2009-04-05 Changes from branch1 for merge to myProject

Since we don’t have a parent branch, we needed to tell merge where to merge from. bzr status tells us what’s changed. No conflicts this time, we’ll go ahead and commit. At this point, both myProject and myProject.branch1 are identical. Which is what we kind of wanted.

That’s it for branching. I don’t know what I’ll do for the next post yet. I’m thinking either showing how to handle remote stuff, delving into what repositories are, or looking at how to handle authentication and permissions. Anyway, if you like this let me know.