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