Ubuntu Open Week - Bazaar - Martin Pool - Wed, Apr 25, 2007

see also Monday Session.

TZ UTC-4

(04:01:52 PM) poolie: ok, let's go
(04:01:52 PM) mohnkern_: Cool.
(04:02:04 PM) poolie: this session is about Bazaar
(04:02:25 PM) poolie: i'm Martin Pool, one of the Bazaar developers
(04:02:39 PM) poolie: we also have jam, John Arbash Meinel, also a Bazaar developer
(04:02:44 PM) jam: Hi all
(04:02:54 PM) poolie: to start with, what is Bazaar?
(04:03:07 PM) poolie: Bazaar is a distributed version control system
(04:03:39 PM) poolie: it keeps a history of changes to a source code tree
(04:04:14 PM) poolie: and aids in: finding out what was changed, when, why, by whom
(04:04:16 PM) poolie: merging
(04:04:24 PM) poolie: merging changes made by different people
(04:04:55 PM) poolie: undoing mistakes, doing code review and so on

<mohnkern_> QUESTION: Like Subversion?

• yes, like subversion. the biggest difference is that Bazaar allows distributed work, so you can commit when you don't have a network connection to the server. in fact, you don't need to run a server at all, you can just host files on a web or ftp server. other version control systems include cvs, git, monotone, mercurial, darcs, clearcase, etc

<Treenaks> QUESTION: How 'good' is Windows support? Are there plugins that do 'graphical things' like the GTK plugins in Linux? Do the GTK Plugins work in Windows if you can find pygtk + gtk for windows?

• A: there is ver good windows support, there is a windows configuration tool and gtk tools to look at history, diff, commit, etc. they do work on windows. and some people are working on a tortoisebzr program to integrate it into the shell.

  <jam> The current guis are all built on gtk+pygtk, which has implementations on both Mac and Windows. Except the Visual Studio integration which is done in C#, IIRC

(04:10:29 PM) poolie: ok so
(04:10:50 PM) poolie: we're going to quickly go through a demo of how you might contribute a fix to someone else's source tree
(04:11:11 PM) poolie: if you're on ubuntu, do 'sudo apt-get install bzr' to make sure it's there
(04:11:29 PM) poolie: on other platforms look at bazaar-vcs.org
(04:12:07 PM) poolie: this tree is hosted on launchpad - hosting of Bazaar branches is one feature Launchpad offers as well as bug tracking, translations, etc
(04:13:12 PM) poolie: so if you're ready to go let's
(04:13:46 PM) poolie: type
(04:13:51 PM) poolie: bzr branch http://bazaar.launchpad.net/~mbp/+junk/seminar
(04:14:11 PM) poolie: this will download a copy of my sample branch into a directory called 'seminar'
(04:14:34 PM) poolie: you've now made a new independent branch
(04:14:38 PM) poolie: cd into there
(04:14:43 PM) poolie: you'll see one file
(04:14:57 PM) poolie: you can type 'bzr log' to see the history of when it was created
(04:15:31 PM) poolie: there is also a .bzr directory containing control information
(04:15:51 PM) poolie: now edit 'hello' in your text editor
(04:15:58 PM) poolie: add a line or something, save and exit
(04:16:08 PM) poolie: try 'bzr diff' and it will show you what you changed
(04:16:24 PM) poolie: try 'bzr status' and it will tell you just the name of the file you changed
(04:17:11 PM) poolie: 'bzr help' tells you other things you  can do, like adding, deleting and renaming files
(04:17:30 PM) poolie: if you're happy with your change, do 'bzr commit' and it will ask you for a message describing the change
(04:18:35 PM) poolie: this commit has now gone into your branch, which has diverged from mine
(04:19:00 PM) poolie: if you do bzr log, you'll see that your name is in there too
(04:19:20 PM) poolie: this works without you needing to be added to our project, or even to have a launchpad login
(04:19:24 PM) poolie: which is different to cvs
(04:20:08 PM) poolie: if you have a launchpad account, you can push your changes back up, with
(04:20:34 PM) poolie: bzr push sftp://USERNAME@bazaar.launchpad.net/~USERNAME/+junk/seminar
(04:21:43 PM) poolie: the +junk stands in place of a product name - normally they must be associated with a product so we can link them up
(04:21:52 PM) poolie: now i've also committed a change to my branch
(04:22:25 PM) poolie: so if you do 'bzr merge' it will integrate your changes with what i've done
(04:22:37 PM) poolie: this will probably cause a conflict if we both changed the same part of the same file

<Loic> QUESTION: When I do "bzr commit" it opens nano. What am I supposed to do there?

• It is giving you the opportunity to write a commit message. Type some basic information about the change and then save and quit your editor. when you do "bzr log" afterwards, it will show the commit along with the message you associated

(04:25:16 PM) poolie: ok so please say in -chat if you've successfully got a file with conflicts?
(04:26:03 PM) poolie: now you'll want to edit that file, to resolve the conflict - remove the marker lines, and choose one or both new bits that you want to keep
(04:26:10 PM) poolie: then do 'bzr resolved hello'
(04:26:25 PM) poolie: and then you can commit again, this time you can give the message on the command line with
(04:26:33 PM) poolie: bzr commit -m "merge from martin"
(04:27:14 PM) poolie: it's also worth mentioning that in the upcoming 0.16 release, you can also link to bugs when you commit
(04:27:30 PM) poolie: for launchpad, bzr commit --fixes lp:202020
(04:28:05 PM) poolie: ok as some people have noticed
(04:28:12 PM) poolie: after your commit, you can run bzr lgo
(04:28:15 PM) poolie: or even log
(04:28:28 PM) poolie: and it shows you the merged-in revisions indented
(04:30:14 PM) poolie: ok, so this has just got the fix into your branch
(04:30:23 PM) poolie: if you wanted to share it with me you have a few option
(04:30:32 PM) poolie: you could push to launchpad, and tell me about the branch
(04:30:36 PM) poolie: or to another web server
(04:31:08 PM) poolie: or, you can do 'bzr bundle' which gives you an enhanced diff suitable for mailing to a person or a list
(04:31:16 PM) poolie: and they can then do 'bzr merge BUNDLEFILE'
(04:31:31 PM) poolie: ok, so to wrap up, i'll show you how to start a new project
(04:31:56 PM) poolie: we need to introduce the concept here of 'repositories' which is a directory that stores information about a set of related projects
(04:32:37 PM) poolie: to use less disk space, and so that when you push or pull from them, it does it only once

<frosty__> QUESTION: When would I use merge, and when would I use pull?

• pull means 'make this branch a mirror of theirs', merge means 'integrate their work into mine'. so normally you use pull when you have a mirror of a remote branch. you might also use it in a long-running branch when all its changes have been integrated upstream. pull keeps your changes in the working copy

  <rulus> question: so if I get it right, a 'pull' creates a 'branch' that will automatically 'merge'?

  • <jam> Not quite. "pull" will update your working tree with the changes from upstream. in a similar way that "merge" will. But from a user perspective they have a different "feeling". When you use "pull" you mean to say "I want this branch to be a copy of theirs". Which is different from "I want to include their changes in my work" (merge). 'pull' doesn't create the branch. It just updates your branch to be a copy of their branch

<frosty__> QUESTION: So what if there are conflicts when you pull?

• <jam> There are 2 types of "conflicts" that can occur during 'pull'.

  • 1) if you have uncommitted changes, and upstreams changes conflict with yours. these are resolved like any other file-level conflicts by editing and then running 'bzr resolve' 2) If you have made local commits, and they have made commits. In that case, you can't turn your branch into a copy of theirs, because you have committed changes

  So you either need to switch and use "merge" or use "pull --overwrite" which says "Make mine like theirs, and throw out my changes"

(04:38:31 PM) poolie: ok
(04:38:57 PM) poolie: so to wrap up 'starting a new project'
(04:39:32 PM) poolie: to make a new branch, do 'bzr init DIR' - can be either an existing unversioned source tree, or it will create a directory
(04:40:07 PM) poolie: you can tell bazaar about files to ignore - typically build products like *.o or *.pyc
(04:40:20 PM) poolie: using 'bzr ignore', or by editing .bzrignore at the top level
(04:41:02 PM) poolie: then do 'bzr add' to tell bazaar you want to version all the files, or you can add them individually
(04:41:10 PM) poolie: then commit, and you're off and running
(04:41:27 PM) poolie: that concludes my tutorial content -- jam, anything to add?
(04:41:55 PM) jam: poolie: I think that is good, as long as people don't have more questions on the demo
(04:42:10 PM) poolie: let's do some questions then

<ih70> QUESTION: Why do we need yet another source control system. What objectives does bzr achieve that are not possible in say SVN? <frosty__> QUESTION: Why should someone use bazaar, over another distributed system? Say, darcs, git, or mercurial?

• <jam> Well, each of the projects takes a little bit different approach to the world of VCS. To start with: SVN... the juggernaut of centralized version conttrol. SVN has evolved into a very good system for versioning source code where everyone is given access to the same repository. well, at least a 'good' system... What it doesn't handle very well, though, is repeated merging between branches. Or being able to commit "offline". Like on your laptop while on a plane. But the biggest difference is the idea of "decentralized". With bzr, anyone can create a local branch of an existing project and make their changes, committing as they go. And then present their changes to 'upstream' in a fashion that is easy to merge back. With SVN, anyone not priveledged with commit access has to fall back to diff and patch making them a second-class citizen. With bzr, you have full access to version control. It actually follows the Open Source philosophy very well. Now, pretty much all of the DVCS systems support that too. Which is what the "Distributed" is in Distributed Version Control System So why "bzr" versus darcs, git, monotone, hg, ... I could go into a blow-by-blow of how we function differently from each of them, but that is a very long discussion. The short answer is that we have tried (and continue to put a lot of effort) into making bzr a great system that you enjoy using. We support multiple workflows from fully distributed to mostly centralized (like SVN). We are getting better and better integration with Launchpad allowing you to track open bugs and close them from a simple 'bzr commit'. And it is also the system that Ubuntu is switching to for its development, because it wants to make it easy to contribute changes back and forth between Ubuntu and upstream (debian, etc)

  <Admiral_Chicago> can't SVN be set up with anyone having commit rights

  • <jam> SVN can be set up to give everyone access rights, but that is sort of like changing your web page to remove any password protected logins. Anyone can now introduce changes into your core. With bzr, everyone has access to create changes, but you have control over your mainline. And bzr just makes it (much) easier to merge their changes. Also, SVN doesn't handle merging between branches within the same repository very well... we let you do it from anywhere

<Adhemar> QUESTION: (As a non-programmer) Suppose I would like to have a versioned home directory (not just source, most of it text though) (the Video directory excluded) and have the home of my laptop "merged" regularly with the home of my desktop. Would using bzr make sense somehow? (Or are you aware of better alternatives, maybe transparent versioned file systems for Ubuntu?)

• bzr could be good for that; you should also look at Unison, which is just a two-way smart synchronization tool

  <jam> I use bzr for the files I modify, like .vimrc .bashrc, etc, but for most projects. I have a separate bzr branch for them, rather than having everything in one mega-project in my home dir

<ih70> QUESTION: How well does bzr deal with binary files?

• <jam> In general, bzr handles binary files well. The binary delta code is not optimal, but it does produce deltas. The biggest shortcomming is handling of *large* (100MB+) files. We are focused right now on making bzr very good for source control and versioning CD ISO's is a very different project

<rmunn> QUESTION: If I'm using bzr, but upstream isn't, how do I easily create a patch to present to them? Is there a "bzr push --patch" or some such command?

• easiest is. bzr diff -r ancestor:../upstream . if your import of their upstream branch is in ../upstream

<txwikinger> QUESTION: Can you push through web proxies, using dav, and on web servers needing authentication?

• yes, you can

<Loic> QUESTION: Is it possible to use bzr for package creation, and has it been done (pros/cons)?

• <jam> Loic: I know there are a couple of ways to do this. There is a "bzr-buildpackage" plugin to help automate generating debian packages (and possibly rpms as well). In general, with bzr you can have finer grained details about what has been changing, associated with the actual changes to the files versus a "release 1.1" has these changes versus "1.0".

<rulus> question: I'm using bzr for school reports made in Latex. I'm thinking of hosting the branch on my webspace as a backup, and then commit changes to it through bzr. However, I don't want the whole world to read my school reports. Is there some bzr gpg plugin to en/decrypt on the fly?

• <jam> At present, there is not an encrypted layer. however, you can use .htaccess files to control who has access to your files and there is a Google SoC project for having an encrypted repository

(05:00:48 PM) poolie: time to finish...
(05:01:26 PM) jam: I think we need to wrap it up
(05:01:30 PM) jam: Since it is time for the next session
(05:01:39 PM) jam: But I would like to invite everyone to #bzr if they have any more questions
(05:05:19 PM) jam: As always, questions are more than welcome in #bzr
(05:05:25 PM) jam: Thanks to everyone who participated.