Bazaar gedit integration
Javier Derderian is working on , the GNOME standard text editor, so that you can very easily record changes, push them to a server, and so on. Bazaar's model that a branch is just a directory with extra metadata fits pretty well here. He just made another exciting release (or should that be "excited"? :-)
posted Thu 8 May 2008 in /software/vc/bzr | link
Bundle Buggy, for list-based code review
My favourite thing about Bazaar is actually a tool built on top of it, Bundle Buggy, a tool for managing contributions and reviews.
When you send a patch or a Bazaar bundle to the developer mailing list, Bundle Buggy gets a copy of it, sees the proposed merge, creates a web page about it, linked back to the mail thread and to a bug number if there is one.
By catching all patches to the list it makes sure that things are not accidentally dropped. The important thing though is the getting-things-done workflow and the integration with Bazaar. Seeing a long list of mails can make it hard to decide where to begin, which is an invitation to procrastinate. BB tries to sort out patches which are ready to merge, which have been reviewed by others, which you ought to review yourself, which need other work and other states. It knows about our quasi-voting process, where we try to get at least one core contributor to review all patches, and you can do the reviews entirely over mail.
BundleBuggy is (just about?) all Aaron Bentley's work, and credits Jeremy Kerr's Patchwork tool for inspiration.
We could do a lot more here, I'm sure: a nicer review interface than just showing the diff, perhaps automatically firing off a merge if the patch is approved, telling the bug and its subscribers if we believe a fix has been merged.
posted Wed 23 Apr 2008 in /software/vc/bzr | link
Version control that doesn't make your eyes bleed
Nice positive comments on the benefits of Bazaar's simple and usable interface from the Java-GNOME maintainer.
posted Mon 23 Jul 2007 in /software/vc/bzr | link
Loggerhead: new bzr branch browser
Robey wrote a new and better web bzr branch browser, Loggerhead.
posted Tue 19 Dec 2006 in /software/vc/bzr | link
Launchpad as a directory for bzr
Launchpad is the Ubuntu bug tracker, and more than that. It handles bugs, translations, support requests and so on, and can relate them to the Ubuntu packages and the original upstream source. jamesh writes of his recent work to use Launchpad as a directory for Bazaar branches.
Also, the Jokosher audio editor is switching to the Launchpad bug tracker, and they have some interesting comments.
posted Wed 6 Dec 2006 in /software/vc/bzr | link
Introduction to dvcs and Bazaar for students
Presentation by Matthieu Moy for an introduction to version control for students, using Bazaar.
posted Tue 10 Oct 2006 in /software/vc/bzr | link
Commit from bzr into Subversion
Jelmer Vernoiij has been hacking on Bazaar-Subversion integration and produced some sexy results.
Basically what this is getting to is being able to make a checkout from Subversion using Bazaar, use all Bazaar's distributed features (make branches, commit, diff, etc, all offline) and then eventually merge back into Subversion. And do it all over again, remembering what was already merged, and without requiring any particular setup on the svn server.
posted Mon 3 Jul 2006 in /software/vc/bzr | link
bazaar-ng 0.0.7; into Mandriva Cooker; plans for next release
We released bzr 0.0.7, which has several nice improvements, particularly to merge handling.
Michael Sherer put builds of bazaar-ng into Mandriva Cooker, their unstable development system.
Aaron started on a tool to display bazaar-ng branch histories as graphs, using dot. Still early days but could be fun.
A few more people have come across from working on the Arch-based Bazaar code. Robert Collins has a great intuitive grasp of OOP patterns and test-driven development and I'm very happy to have his help. James Blackwell, who was previously the GNU Arch release manager, is working on the wiki.
In our next release we plan to change to weave-based storage, which will be much more compact and also allow smarter merges. We've had code for this for a while but not turned it on because of working on the UI and framework, but the time has come.
posted Fri 2 Sep 2005 in /software/vc/bzr | link
bzr in brazil
I haven't posted here for a long time, which is bad. It's funny how many people got through phases of just not wanting or getting around to blogging.
bzr (aka bazaar-ng) is coming along pretty well. We just passed 1000 commits onto the mainline since it started self-hosting in March of this year, and we're regularly pulling in changes from contributors branches using bzr.
The emphasis has changed a lot since I started. At the time it was meant to be a research prototype to explore ideas to move back into systems based on GNU Arch. Since then, bitkeeper has exploded, and many people have started picking up the pieces, and the original schedule looks rather leisurely in retrospect.
One important consequence is that we're trying to get bzr to a finished state in its own right.
The core versioning/branching functionality is there and working: branch, push, pull, merge, status, diff, add, commit etc. Some are rather nicely polished; some less so.
I'm trying to define some specific goals for the next few months, and focus on getting them done. Near the top of the list are more compact storage and smarter mesh merging.
One outcome of the research side is modules to do the fundamental vc algorithms of 3-way merge and weave in pure Python. A few people have suggested that merge3 in particular might usefully be contributed back into the Python standard library; after a bit more maturation I'll look into that. These have practical use in allowing it to be installed and run without any extra dependencies like GNU diff; this is moderately important on windows.
I've been in Brazil for the last couple of weeks with other folks from Canonical.com, mostly doing architecture-ish work on Launchpad, our application set for building and supporting a free software distribution. Not so much bzr hacking for now.
Perhaps the most immediately interesting of these is Rosetta, a web-based software translation system that already used by a thousand translators. (If you consider the pool of people who are fluent in at least two languages and work on translating free numbers then a thousand is a pretty large number.)
There are some other good concepts in there — a bug tracker that really deeply understands the way code (and bugs) spread across different free software distributions and packages. They're going to need some UI love before it's easy to understand what's happening inside, but I think that will happen.
The other very cool thing is getting to spend time with Mark and other bright people here.
posted Wed 3 Aug 2005 in /software/vc/bzr | link
Bugzilla and Bazaar-NG
I was talking to Luis Villa at LCA and had an idea of an interesting application for the kind of distributed version control enabled by bzr.
Essentially every Bugzilla installation is a fork of the project: people install it once, tend to customize it to fit their own use, and only intermittently install updates from the maintainers. In a previous job, I was assigned the task of removing all references to "bugs" from the installation, on the grounds that our product only had "issues", not "bugs". I understand Bugzilla is now getting to be more parameterized but there is still some customization and in any case the customization needs to be merged with the new upstream defaults.
If bugzilla was distributed with a small amount of bzr metadata it might be much easier for people to either integrate their changes into new releases, or to submit improvements for upstream integration.
I stepped in to do a talk on bzr when another speaker dropped out. It was received pretty well, and sparked a lot of interesting conversations.
posted Fri 22 Apr 2005 in /software/vc/bzr | link
Patch queues in bzr
The response to bazaar-ng so far has been very positive. Many people are contributing bugs to fix platform problems or to add features they urgently want. It's a very pleasant experience.
One consequence is that, as for many other projects, there are patches submitted that I haven't tested and merged yet. One thing to do would be to put them in an issue tracking system of some kind, but not every project wants that. So I was thinking about what bzr can do to help within this source management problem.
Very shortly we plan to allow submission of changesets by email, as regular diffs with extra annotations. When those come in, they can be stored in a directory on my laptop or on the webserver. Because the changesets have universally unique IDs and descriptive metadata we can then ask interesting questions about the patches:
- Which ones have now been merged into the mainline, and can be deleted from the "pending" queue?
- Which ones still apply to the head of the mainline? Which of those pass all the regression tests? These might be the easiest ones to merge -- though I still have the option of merging one that isn't a perfect fit and fixing it up myself.
- What is the dependency graph between them? Maybe one patch supersedes or updates another, or depends on some infrastructure work.
This queue could be filled by a robot that looks for patches on a mailing list, or in the public trees of past contributors. Although I call it a queue it's not necessarily a FIFO queue; the integrator (me) can pull things out in whatever order. As well as the branches that are normally captured by scm systems, bazaar-ng also helps you manage a bag of patches that don't necessarily fit together yet.
In general: human integrators have a valuable role but a tool can help make them more productive.
You can imagine extending this towards something like Rusty's trivial patch monkey, or perhaps towards filtering out security critical patches as candidates for merging into a stable series.
posted Fri 15 Apr 2005 in /software/vc/bzr | link
file renames in bazaar-ng
Renames are completely(?) working in bzr now, after the last couple of days work. There are two commands: move moves one or more files into a different directory, and rename renames a file (and optionally also moves it.)
(I think this is one case where the unix unification of both these things into mv really causes much more trouble than it's worth.)
There is also a renames command that shows which files have moved relative to the last revision.
Demo:
demo% ls -a ./ ../ demo% bzr init demo% echo hello > one demo% bzr rename one two bzr: error: can't rename: old name 'one' is not versioned demo% bzr add one demo% bzr rename oen two bzr: error: can't rename: old working file 'oen' does not exist demo% bzr rename one two one => two demo% bzr status A two demo% bzr commit -m 'add file' demo% bzr rename two three two => three demo% bzr status R two => three demo% bzr renames two => three demo% bzr commit -m 'renamed' demo% mkdir subdir subdir/d2 demo% bzr add subdir subdir/d2 demo% bzr status A subdir/ A subdir/d2/ demo% bzr move three subdir/d2/ three => subdir/d2/three demo% cd subdir/d2 d2% bzr rename three ../four subdir/d2/three => subdir/four d2% bzr renames three => subdir/four d2% bzr status A subdir/ A subdir/d2/ R three => subdir/four d2% cd ../../ demo% bzr status A subdir/ A subdir/d2/ R three => subdir/four
The code is not published yet; it'll be up later this week.
posted Wed 6 Apr 2005 in /software/vc/bzr | link
bzr tutorial in Japanese
Tez Kamihara translated the bzr tutorial/mockup into Japanese
posted Mon 4 Apr 2005 in /software/vc/bzr | link
Tasteful and attractive composites
Havoc wrote something that describes very well how I am trying to run bazaar-ng:
One of the more annoying properties of the Internet is that no matter what you post to your blog (or mailing list, or chat) people add comments like: "that isn't new, the Amiga had it in 1987" or "that isn't new, we did that with punch cards in 1953" or "Longhorn has that already" or whatever. These comments are especially popular in places like osnews and slashdot.
I usually add a disclaimer to my posts specifically to head this off, but it never helps. (Shocking!)
Why post ideas? It's not to get credit for originality. It's because in this specific context, at this specific time, we should discuss and possibly implement those ideas.
Side point: there's much to be gained by simply doing something better than it's been done in the past. Apple's new Pages app, maps.google.com, there are countless examples. They aren't really "new ideas" per se, they are well-done and tasteful composites of many old ideas. And they were finished, and made available. Not a trivial thing in the modern software industry.
Some people say there is nothing really new in bzr but they like it anyhow; to me that counts as success.
posted Sat 2 Apr 2005 in /software/vc/bzr | link
Rocking the Bazaar
bzr is really coming along very well.
I have stepped up to give a seminar about it at linux.conf.au in place of a speaker who had to pull out. I didn't originally submit an abstract because I thought it wouldn't be sufficiently ready to talk about, but as it turns out it is.
If I can get remote operation working before the conference I'd like to put these commands in the abstract in the online program:
bzr get http://bazaar-ng.org/bzr/sandbox cd sandbox vi hello.txt bzr send
One really important use case for a version control system is that of being told how to do basic operations by someone else. This is the first encounter most people have: wanting to try something out in the development head of some project kept in CVS. It's very important that this be as simple as possible, and that it work reliably. Doubly so because the person will typically not get their instructions from the program's manual, but rather second hand from whatever person or web page is helping them get started on that particular project.
Development has gone well in the last week or so: there is now a rudimentary mv command, a nice ignored that shows what is ignored and why.
Daylight saving finished in Australia, which correctly tested that bzr records dates as GMT + timezone, somewhat like email:
.... ---------------------------------------- revno: 100 committer: mbp@sourcefrog.net timestamp: Sun 2005-03-27 00:41:53 +1100 message: - add test case for ignore files ---------------------------------------- revno: 101 committer: mbp@sourcefrog.net timestamp: Sun 2005-03-27 19:14:45 +1000 message: change default ignore list
jdub loves the info command, saying he'd run it all the time to see the numbers ticking over.
mbp@hope% bzr info
branch format: Bazaar-NG branch, format 0.0.4
in the working tree:
101 unchanged
0 modified
0 added
0 removed
0 renamed
2 unknown
262 ignored
4 versioned subdirectories
branch history:
161 revisions
2 committers
23 days old
first revision: Wed 2005-03-09 04:08:15 +0000
latest revision: Fri 2005-04-01 18:27:01 +1000
text store:
330 file texts
2392 kB
revision store:
161 revisions
55 kB
inventory store:
161 inventories
3219 kB
posted Fri 1 Apr 2005 in /software/vc/bzr | link
Progress on bazaar-ng
(I should write more, but I've been busy.)
Bazaar-NG has been announced, and gained a cautiously positive reaction from the community, including in a slashdot thread about Bitkeeper. There have been some good suggestions but I think we're mostly on the right track.
The most contentious points seem to be:
- Choice of Python as a development language, and specifically whether the performance will be OK.
- Fused branches and directories: two specific points, one is that separate repositories are good for backups, and that shared branches are good for many development methods.
I've been using it every day for managing its own development, and it's coming along well, though there is still much to do.
I have a couple of busy weeks in April with linux.conf.au and Ubuntu Down Under. Before that starts I'd like to put in simple branch and merge commands and fix some other small things.
And there is a first snapshot release!
posted Tue 22 Mar 2005 in /software/vc/bzr | link
The next-generation Bazaar
We have a web site, bazaar-ng.org, for Canonical's prototype version-control tool. There are lots of docs, though I do have to warn that everything is still subject to change. There is not much point at the moment in trying out the code (though you are welcome to), but comments on the documents would be warmly welcomed.
My current code is in Python, and is written from scratch but takes many ideas from many other systems. So far it can do these commands to some extent: add, remove, commit, status, diff, log, help, export. I don't know if there will end up being any truly novel ideas, but perhaps the combination and presentation will appeal.
posted Sun 20 Feb 2005 in /software/vc/bzr | link
An amalgam of distributed version control
I've been hanging out with some of the GNU Arch hackers. I had started out trying to describe what GNU Arch ought to take from other systems — primarily simplicity in both model and interface. There are some good ideas in Arch, but also a lot of what is technically known as "crack". [*This somewhat offensive term seems to have acquired the meaning in GNOME of "unnecessary user-hostile complexity".] I have ended up thinking that Arch is not the right foundation for this.
A huge amount of good thinking has gone into various distributed systems over the last few years. I don't personally find any of them totally satisfying, but I think trying to pick the best ideas from each into a new codebase may work well.
There may be some code in a while.
The high points:
- Simple things should be simple (remember this single file locally); complex things should be possible. At the low end I would like to be as simple as RCS; at the high end as powerful (or nearly as powerful) as the existing systems.
- Version control systems have several purposes: collaboration, branching, undo of mistakes, backup, tracking down bugs by looking at history, distribution, etc. Experimental systems (e.g. Darcs) may choose to ignore some, but I think a "serious" system cannot.
- The history by which a patch arrives at its eventual destination is interesting; this history includes who merged the patch, what they did, and what trees it passed through. Only Arch, as far as I know, keeps track of this.
- The Arch interface is too complex. This complexity is not merely in the user interface but rather saturates the model. It is not desirable to use wrappers to hide underlying complexity. It must be removed by radical surgery; fortunately I think no one will miss it.
- Allowing anonymous read-only access by just putting files on a web site is very nice for both usability and security.
- Cryptographically signing revisions/changesets is also good, and falls fairly naturally out of deciding that history should be append-only. Signing should be done by GPG (unlike Monotone) — open source developers have already built up signed keys and we should use them.
- Unless there is a good reason to do otherwise, the interface should be familiar to users of CVS and Subversion: add, diff, commit, ignore, etc should work as expected.
- There are two basic complex merge problems:
cherry-picking
changes, and history-sensitive merging within an arbitrary graph. I don't think any single existing system (open or closed) can do both correctly, but I think it is possible. - History should be strictly and reliably recorded. I want confidence the system can reproduce my tree's state at any point in the past. At the same time people want exemptions when for example accidentally committing confidential information.
More later. I have a lot more documentation and the start of some code. I have shown a mockup to both Arch developers and Arch haters and both sets liked it.
Havoc has posted a list of desired features. I think my design can address most or all of them, some in quite entertaining ways. Some of the more workflow-related requirements I think I would keep out of the core tool.
Other comments from Tom and Colin.
posted Thu 2 Dec 2004 in /software/vc/bzr | link
Archives 2008: May Apr Feb 2007: Jul May Feb Jan 2006: Dec Nov Oct Sep Aug Jul Jun Jan 2005: Sep Aug Jul Jun May Apr Mar Feb Jan 2004: Dec Nov Oct Sep Aug Jul Jun May Apr Mar Feb Jan 2003: Dec Nov Oct Sep Aug Jul Jun May
Copyright (C) 1999-2007 Martin Pool.