Bazaar: Do I need branches?

Question 1

The Feature branches option of Bazaar Explorer creates a so-called Shared Repository and a single branch called trunk inside it (called a Repository Tree). In your example:

_Source Control == Shared Repository
_Source Control/trunk == Repository Tree

The idea is that in this setup you can create multiple branches next to trunk, and they will store revision data efficiently, by sharing stuff in the shared repository, to put it in a nutshell.

If you are a beginner, then don't worry about branches. At some point it will probably naturally come to you. For example you realize you want to do something experimental but you don't want to mess up your trunk. The obvious solution will be to create a branch.

Now about your workflow:

I think you can use the bzr upload plugin for both the staging site and the live site.
To roll back your live site to a previous version, use bzr upload -rREV --overwrite where REV is the revision you want to rollback to. Using the --overwrite there looks dirty, and it probably is. But that's the only way it works for me, I think it's a bug in my version of the plugin (1.0.1dev), I suggest to try first without that flag.
To fix the bug, no need to roll back locally, just fix the bug and confirm it, then upload again with bzr upload without the other flags to bring the website up to the latest version.

There are many ways of working with Bazaar. You can implement a beautiful and sophisticated workflow, or use this somewhat dirty but simple and easy to understand workflow. Let me know if you have further problems.

And no, you don't need checkout in the setup you described.

Question 2

In Bazaar, a single branch is a linear history of your project files. You need multiple branches as soon as you want to work on multiple versions of your project concurrently. That naturally happens when multiple developers are involved, but can also be useful for one-person projects.

For example, it allows you to continue to develop a new feature as part of a feature branch, while adding, testing, and deploying bug fixes on the main branch. Once the feature is finished, it can then be merged back into the main branch. Similarly, if you want to experiment with something that you may or may not want to have as part of your main codebase, it is a good idea to have an experimental branch for that.

For simple projects, a single main branch may be all you need, but it is a good idea to familiarize yourself with branching regardless, as it has a number of very practical use cases.

In order to deal with the "problem" scenario you describe: First, get the last working revision that you have. There are a number of ways to accomplish that:

bzr checkout can be used to create a new checkout of a specific branch and revision in a different working directory. You then have a directory containing the old version and a directory containing the new version.
bzr branch does largely the same thing as bzr checkout for this purpose, but also creates an independent branch in the new directory based off the specified revision. This is useful if, as described above, you need to work on both the old and the new version concurrently.
bzr update can be used to switch the current directory to a different revision. You can then do whatever you want to deploy the old version and use bzr update again to switch back to the most recent one.