On Wed, Aug 29, 2012 at 04:16:59PM -0400, Ryan Lange wrote:
> Hello again,
>
> As I mentioned in my previous message, I've been thinking about a
> repository structure for some personal projects I'll be working on.
> Another issue that occurred to me---also related to vendors
> releases, but different from the issue in my other message---is what
> to do when you decide that you want to test against a version of
> VendorA's code that is older than the oldest version in your vendor
> branch.
>
> For example, your vendor branch currently looks like this:
>
> - vendors/
> - VendorA/
> - 2.0.0/
> - 2.1.0/
> - current/
>
> This is probably a sign of poor planning, but what if you decide
> that you also want to test against v1.0.x of VendorA's code? Does
> anyone have any thoughts on how to handle, or experience with
> handling, such a situation?
>
>
> Thanks again,
> Ryan
A "vendor branch" usually means that you pick a certain vendor
code base version A as a baseline for your own product, and make
modifications relative to version A. In this model you're usually
only interested in future vendor releases, since they might have
fixed bugs that still affect your own product.
What you describe now sounds more like code developed by the vendor
is used in your product, but doesn't form a baseline for your product.
In which case it is more like an external dependency. You'd usually treat
the vendor code as a library that you depend on, which might reside in some
subdirectory of your own source tree (e.g. it could be an external, see
http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html).
Then you could swap the content of the directory which the vendor code
resides in with the appropriate version you want to test against.
Or you install the vendor code as a library on your system and compile
different builds of your own product linked against different versions
of the vendor library, and run tests on each build.
Received on 2012-08-29 23:56:56 CEST