CASA Repository and Build

Mon Jan 5 07:44:16 MST 2009

We host source code on the CASA repository.

We should also host build methodology (the RPMs and the MacPorts for CASA itself)

We depend upon a number of other projects (3rd-party).

We host the 3rd-party projects in various ways.

At the least, we host the build methodology. We should also host the source code of 3rd-party things.

Most 3rd-party things are of interest (need) to NRAO in general, not just CASA.

There are [at least] two ways to host a project: mirror and clone.

SVN External branches (mirror)

If we don’t want to make any changes to the source code, we can add 3rd-party source to an NRAO subversion tree via the svn:externals property:

"An externals definition is a mapping of a local directory to the URLâ and possibly a particular revisionâof a versioned resource."

When someone checks out the parent from NRAO, they will also check out the sub-directory code from the 3rd-party repository.

The value of this is that we let the 3rd-party manage their code. We get exactly the code that they provision.

BUT: If their server is offline or unreachable somehow, we can’t get their code.

If we need to make (local) changes to the code, then we should consider the other method: vendor branch

SVN Vendor branches (clone)

We usually want to use a 3rd-party project’s work, but we often need to tweak it for CASA’s needs. The best thing to do is to pull in the 3rd-party project source code via a vendor branch:

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.

Vendor branches provide two key benefits. First, by storing the currently supported vendor drop in your own version control system, the members of your project never need to question whether they have the right version of the vendor's data. They simply receive that correct version as part of their regular working copy updates. Secondly, because the data lives in your own Subversion repository, you can store your custom changes to it in-placeâ you have no more need of an automated (or worse, manual) method for swapping in your customizations.

In general, we make vendor branches of 3rd-party projects.

For some projects, we submit patches back up to the 3rd-party maintainers for incorporation into their mainline repository (e.g. bug fixes). Most of the time, though, we simply maintain a local collection of patches.