Re: Managing Vendor Branches
From: BRM <bm_witness_at_yahoo.com>
Date: Sat, 27 Feb 2010 09:56:53 -0800 (PST)
----- Original Message ----
> From: Jeff Mott <jeff.mott.or_at_gmail.com>
Here's what I do:
In my repository I have a ThirdParty namespace (e.g. /ThirdParty) under which each Third-Party import has their own namespace (e.g. /ThirdParty/<import>/), with each having its own 'trunk', 'branches', and 'tags'.
When I import a new version, it goes into the 'branches'. This then gets merged to 'trunk', and released to 'tags'. My projects then pull against the 'tag' using svn:externals.
In this way, I can track the changes that happen from the vendor and even accept or deny some changes if I need to. For example, Qt has a niced add-on for supporting services/daemons - the Qt Service Class (http://doc.trolltech.com/solutions/qtservice/qtservice.html). However, their releases of it are targeted either at Windows OR Unix/Linux/Mac, but I need to support both; so using this method I merge them both together and use the merged result in my source.
Personally, I think this helps as it is basically treating the vendor as another project in the repository. Of course, each of my projects have their own trunk/branches/tags, so this might not work for you if you're not doing that too...but you could probably find similar way.
HTH,
Ben
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.