From WhyNotWiki

Vendor branch management  edit   (Category  edit)

Contents 1 Is it a "vendor branch" or a "vendor drop" 2 Problem: Need a way to store in the vendor branch/drop information about where it came from 2.1 Vendor branches using vendor drops 2.1.1 Solution? 2.2 Vendor branches using svn export 2.2.1 Solved by: Piston 2.2.2

[edit] Is it a "vendor branch" or a "vendor drop"

Perhaps this would be as good a time as any to clarify what difference, if any, there is between a vendor branch and a vendor drop...

[1]

A vendor branch is a directory tree in your own version control system that contains information provided by a third-party entity, or vendor. Each version of the vendor's data that you decide to absorb into your project is called a vendor drop.

It sounds like the standard way to do this is to have vendor branch (called vendor/) that contain data/source code for one or more third-party vendors or vendor software projects, each of which gets its own subdirectory (vendor/rails, vendor/mediawiki, etc.) (I think it should be okay to call this directory a "vendor branch" as well). Under each per-project subdirectory lives another level of subdirectories. These are what are referred to as the actual vendor drop -- each one represents a specific version of a specific vendor product/project.

Okay, now that that's been cleared up, I need to introduce a distinction. We can either have:

• a vendor branch that does not contains vendor drops, but rather is synchronized/pulled in from a remote repository (either via svn:externals or svn export). This type of vendor branch only contains one version at any given time.
• or: a vendor branch that contains vendor drops. It can contains multiple versions of the data -- each version constitutes a vendor drop.

[edit] Problem: Need a way to store in the vendor branch/drop information about where it came from

This is, we need to store some metadata with each vendor branch/vendor drop:

• If it's from a repository, we need to store, at the very least, the URL of the remote repository (also good to store the revision number, as explained below)
• If it's from a package/official release, need to store release number

[edit] Vendor branches using vendor drops

This is a bit harder for a vendor branch that uses vendor drops (but is repository-source-less), which are often from an official release/zip file (mediawiki-1.8.2.tgz for example) and the revision number (from the vendor's repository) is (or can be if it's not an open-source project) unknown.

However, if you ever decide to submit a patch for official inclusion, you need to (or at least would be helpful if you did) know which revision (in addition to the source repository URL) the patch is against...

[edit] Solution?

...

[edit] Vendor branches using svn export

Why do we need the repository URL?

• So we know how to update the export (and can automate it)

This is easier for svn exported vendor branches than for vendor-drop-type branches.

Previously the only way I knew of to keep track of where I exported a plugin from was to make a note of it in a Readme file and commit that...

But that's a manual process and is problemful:

• easy to forget
• error-prone

How can we do it then?

• We could store it in some custom Subversion properties (in fact, that's exactly how Piston does it)

[edit] Solved by: Piston

Piston

[edit]

Aliases: Vendor branch management, Vendor drops