Tracking Third-Party Sources (Vendor Branches)?

[John Arbash Meinel]

Bob Tanner wrote:
> Matthew D. Fuller wrote:

...

>>> The degenerate case would be something like the FreeBSD src CVS tree,
>>> which has a couple dozen different vendor branches in various places
>>> under it.
> 

As near as I can tell, your project tree layout is the same each time,
just that they have a different base directory.

This is exactly what bzr branches are for.

> Something like this:
> 
> samhain-2.0.10a/
> |-- COPYING
> |-- LICENSE
> |-- README
> `-- debian
>     |-- control
>     |-- copyright
>     `-- rules
> 
> That is the upstream source, I'd like to the upstream source an branch to
> create my own hackable copy, like this:

If the above source is already a bzr branch, all you have to do is use:
cd ..
bzr branch samhain-2.0.10a samhain-2.0.10a-my-sid

> 
> samhain-2.0.10a-my-sid/
> |-- COPYING
> |-- LICENSE
> |-- README
> `-- debian
>     |-- control
>     |-- copyright
>     `-- rules
> 
> Make sites specific changes related to the sid release of debian, BUT then
> branch the upstream source again, like this:
> 
> samhain-2.0.10a-my-etch/
> |-- COPYING
> |-- LICENSE
> |-- README
> `-- debian
>     |-- control
>     |-- copyright
>     `-- rules
> Make site specific changes releated to the etch release of debian
> 
> Since 99% of the files in upstream, my-sid, my-etch are the same, the shared
> repo stuff looks like what I want, correct?
> 

Yes, a repository works really well here. If samhain-2.0.10a is already
a bzr branch, you could do this:

$ bzr init-repo --trees samhain
$ cd samhain
$ bzr get http://other/place/samhain-2.0.10a 2.0.10a
$ cd 2.0.10a
$ pwd
.../samhain/2.0.10a
$ cd ..
$ bzr branch 2.0.10a 2.0.10a-sid
$ cd 2.0.10a-sid
$ echo "In SID you don't copy, it copies you" >> COPYING
$ bzr commit -m "SID copies"
$ cd ..
$ bzr branch 2.0.10a 2.0.10a-etch
...

I chose to use the structure:
 samhain/
  2.0.10a/
    |-- COPYING
    ...
  2.0.10a-sid/
    |-- COPYING
    ...
  2.0.10a-etch/
    |-- COPYING
    ...

But there are other ways to do it. You could certainly have something like:

 repo/
   samhain-2.0.10a/
    |-- COPYING
    ...
   samhain-2.0.10a-sid/
    |-- COPYING
    ...
   samhain-2.0.10a-etch/
    |-- COPYING
    ...

If you were publishing the branches, and didn't have working trees, you
could even do:

$ bzr init-repo samhain # no --trees flag
$ cd samhain
$ bzr get http://other/place/samhain-2.0.10a/ 2.0.10a
$ cd 2.0.10a
$ bzr branch 2.0.10a sid
$ bzr branch 2.0.10a etch

That leaves you with the structure:

samhain/ # repository base
  .bzr/ # where the history will be stored
  2.0.10a/ # The upstream branch
    .bzr/ # branch info about 2.0.10a upstream
    sid/ # The sid branch of 2.0.10a
      .bzr/ #branch info for samhain-2.0.10a-sid
    etch/ # the etch branch
      .bzr/

That gives other people urls like:

bzr get http://host/samhain/2.0.10a/sid

versus
bzr get http://host/samhain-2.0.10a-sid

or whatever combination you like.

John
=:->

PS> If the upstream isn't a bzr branch, you follow similar steps, but
replace the 'bzr get' with a 'tar xvzf upstream; cd upstream; bzr init;
bzr add; bzr commit -m "creating branch for upstream"'
And then it *is* a branch. :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060517/0320cdea/attachment.pgp