Tracking Third-Party Sources (Vendor Branches)?

John Arbash Meinel john at arbash-meinel.com
Wed May 17 23:39:08 BST 2006


Aaron Bentley wrote:
> Matthew D. Fuller wrote:
>>>> Yes you could run into problems if you miss a new file.
>>>
>>> Well, there's also trouble in that I'd rarely be brining a new vendor
>>> branch into a pristine tree; the project will be going a while before
>>> I need to bring something in and adjust it.  By that time, I'll
>>> already have a README and a LICENSE and a Makefile, and a src/ and a
>>> doc/ and an examples/, so when I try to merge over from a vendor
>>> branch of a project with its own version of all of them...   ick.
> 
> Okay, I'm not understanding the problem.  AIUI, the way to handle the
> issue is to maintain an upstream branch, that only gets updates from
> upstream.  (Whether it comes from CVS or tarballs or whatever.)
> 
> So when the upstream relases a new revision, you put that into your
> upstream branch, by deleting all the files in the upstream branch, then
> putting the new version in (e.g. untarring).
> 
> Then rename any renamed files, "bzr add" any new files, and commit.
> None of that should involve any nasty conflicts with existing doc,
> README, etc files.
> 
> Now to update your local branch, you do "bzr merge ../upstream".  And
> that should work the same as it always does.
> 
> What am I missing?
> 
> Aaron

He wants them both in the same project. So that he can have:

myproject/
  library-1-upstream
  library-2-upstream

And have them all managed.

You can easily do the above with multiple branches, but I believe he
wants them all to be one branch.

John
=:->

-------------- 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/b7e1ab8a/attachment.pgp 


More information about the bazaar mailing list