Tracking Third-Party Sources (Vendor Branches)?

Aaron Bentley aaron.bentley at utoronto.ca
Wed May 17 20:58:40 BST 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEa4Bw0F+nu1YWqI0RArZGAJ9/FfH53F8kjAIIkEpOKKnsjt98YQCfaGsi
S4MTRjmiXIXOu2KItvJjnpQ=
=sWtK
-----END PGP SIGNATURE-----




More information about the bazaar mailing list