Bazaar equivalent for some foreign concepts

[James Westby]

On Thu, 2009-03-05 at 09:42 +1100, Ben Finney wrote:
> This all sounds great, except of course the author is overly enamoured
> of Git :-) and the ‘commit’ discusses concepts that are foreign to me
> as a Bazaar user. The only “treeish object” I'm aware of that can be
> relied upon in Bazaar is a working tree, for which there is exactly
> one per branch.
> 
> Nevertheless, I would like to use this with Bazaar, perhaps modifying
> it if necessary to do so. What is the Bazaar equivalent of “specify
> in which tag (or branch or other treeish object) [the commit is]
> stored”

This is done for git by making use of the fact that you clone 
repositories, not branches. It then creates a new, unrelated branch
in which to store the deltas, and then every keeps this.

We don't really have somewhere to use for that purpose in bzr, except
for the working tree.

I have just implemented support for pristine-tar in bzr-builddeb. It
should be transparent in the latest version which is waiting for
sponsorship in to experimental.

What it does is the following:

  You run "bzr merge-upstream" to indicate that you want to merge
  a new upstream release. Lets consider the case where you just have
  a tarball of that release.

  It first unpacks that tarball and unpacks it over the last revision in
  the "pristine upstream branch" (I'll explain what this is in more
  detail later).

  It then gives the tarball and this tree to pristine-tar and asks it
  to generate the delta.

  It then commits the unpacked tarball to the "pristine upstream     
  branch", storing the delta as a revision property in this revision,
  and tagging it with a known name.

Now, when it needs the tarball for a specific upstream version it looks
up the revision using the tag. If it has the revision property then it
extracts the delta, and passes the exported revision tree and delta
to pristine-tar and gets back a tarball.

It may be possible to implement this directly in pristine-tar, I'm not
sure, given that it needs to access bzrlib to do some things, (like set
revision properties), I'd be glad to help you try.

Doing it the way I did meant that we could get the benefits of 
pristine-tar without anyone really having to know what it is (I think
the same is true of git-buildpackage though).

I said I would explain what the "pristine upstream branch" was. It's the
line of development which tracks the upstream part of the packages. It's
not a branch as such, unless you extract it yourself, it is maintained 
for you by bzr-builddeb.

There is at least a revision for every upstream release of the software.
If you are just using tarballs then this is obvious. However, it does
the same if you are packaging snapshots of a bzr branch. This is for
two reasons. Firstly it gives us somewhere to put the pristine tar 
delta, so it is pretty useful. Secondly, it also represents reality
better in most cases. It is rare that the .orig.tar.gz exactly matches
the tree in a particular revision, for instance many projects will run
autoreconf on the export before tarring it up.

Keeping the separation means that if you compare the real upstream 
branch with the pristine one then you see the addition of these
non version controlled bits, and if you compare this with the packaging
branch you see the addition of the packaging. It then also allows you
to view this history of the pristine branch and examine e.g. how the
configure script changed. Use "merge-upstream" against a tarball and
a branch to see this.

If you are just packaging snapshots from bzr, and there are no tarballs
as such, then bzr-builddeb will now create them for you if you use
"merge-upstream" against a branch. I plan to add a hook in here
so that e.g. autotools can be run as needed.

Oh, and a couple more cool things while I'm at it. Thanks to Jelmer
you can use bzr-builddeb to package an upstream that is SVN with no
problem, and if you have something maintained with svn-buildpackage
bzr-builddeb should pick up it's configuration from the SVN repository
and do the right thing, so replacing "svn-buildpackage" with "bzr
builddeb" should work. Also thanks to Jelmer bzr-builddeb works against
remote branches, so running 

   bzr builddeb -S lp:~james-w/bzr-builddeb/2.1

should drop you a source package in your current directory.

Lastly, you asked why it is called "bzr-builddeb", it is because there
is only one namespace for bzr commands, and so I didn't want
"bzr buildpackage" to exclude anyone from a .rpm distribution from
creating a similar plugin, or at least one that could be installed
in parallel.

Thanks,

James