Tracking Third-Party Sources (Vendor Branches)?

[Wayne Davison]

On Tue, May 16, 2006 at 10:16:05AM -0500, Bob Tanner wrote:
> Maybe my years of cvs usage has caused my brain to rot, but I cannot seem to
> figure out how to use bzr to track 3rd part sources like I do in cvs.
> 
> http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_13.html#SEC103

Here's one method.  I like to use a shared repository so that the vendor
branch and my custom branch used shared storage (this isn't strictly
required, but if you do this, you'll need at least bzr 0.8).  If you
don't already have such a repository, do this:

  bzr init-repo ~/bzr-repo

Then, you can create a branch inside this repository for your project
and then check it out somewhere.  Taking wdiff from the above tutorial:

  bzr init ~/bzr-repo/wdiff
  bzr checkout --lightweight ~/bzr-repo/wdiff ~/src/wdiff

(The alternative to this is to just run "bzr init ~/src/wdiff".)

You now have an checkout of the empty wdiff project in "~/src/wdiff".
Now, we want to untar a wdiff release, make special use of the .bzr dir
in the empty wdiff checkout, and commit this source:

  cd ~/src
  tar xvzf ~/downloads/wdiff-0.04.tar.gz
  mv wdiff/.bzr* wdiff-0.04
  cd wdiff-0.04
  bzr add
  bzr ci -m 'Release 0.04'
  cd ..
  mv wdiff-0.04/.bzr* wdiff
  rm -rf wdiff-0.04

At this point you can create a branch of the wdiff release for your own
personal modifications and check it out:

  cd ~/src
  bzr branch ~/bzr-repo/wdiff ~/bzr-repo/wdiff-local
  bzr co --lightweight ~/bzr-repo/wdiff-local
  cd wdiff-local
  [... Change whatever you like and commit your changes when ready. ...]

To update the main wdiff branch with a new release, do something very
similar to the original import -- we use the saved .bzr dir from the
still otherwise empty wdiff dir (if it's not still around, just redo
the above checkout command to get it back):

  cd ~/src
  tar xvzf ~/downloads/wdiff-0.05.tar.gz
  mv wdiff/.bzr* wdiff-0.05
  cd wdiff-0.05
  bzr status
  [... Check the list of removed files against the unknown files to
       look for files that should really be renamed; if any exist,
       move each one to its old name and then "bzr rename" it back
       to the new name. (*) ...]
  bzr add
  bzr ci -m 'Release 0.05'
  cd ..
  mv wdiff-0.05/.bzr* wdiff
  rm -rf wdiff-0.05

You can then merge the updated vendor version into your modified code:

  cd wdiff-local
  bzr merge
  [... Fix any conflicts and commit the changes. ...]


(*) I created a simple script to handle renamed files, which I named
bzr-fix-rename:

#!/bin/sh
mv "$2" "$1" && bzr mv "$1" "$2" && bzr diff "$2" | less

... which you would call with:

  bzr-fix-rename OLDNAME NEWNAME

(The " && bzr diff ..." part is just my own preference to ensure that
the NEWNAME file was really based on the OLDNAME version.)

So, it would be nice if there was some method to tell bzr that a
directory needs a lightweight checkout (really some kind of bound init?)
without affecting the working tree in any way, which would eliminate the
need to play games with the .bzr dir in this situation.

..wayne..