LabVIEW and Subversion - Organization suggestions?

[Lars915]

My company has a large number of software testers in several departments. We all use Subversion for version control, but we don't all use the same version of LabVIEW. Almost all testing we do uses TestStand for test flow control and we use several libraries of LabVIEW drivers to interface with the test hardware.

My problem is figuring out how to organize subversion to accomodate using several versions of LabVIEW libraries. We don't necessarily try to keep all libraries up to date. As new products come into our department, we try to take advantage of new technology, and of course new drivers may be needed as required functionality grows.

So, I understand trunks and tags. I suspect the answer is to use branches, but I'd like to hear some experienced opinions before I dive in to fix this and end up redoing it a dozen times. The current layout we use is to use a trunk to hold all the libraries in the user.lib and instr.lib directories. We use tags to capture snapshots specific to individual projects so we can rebuild a test setup. The next thing I need to figure out is how to continue development in LV8.5 without overwriting our 8.2 and code.

[LuI]

QUOTE(Lars915 @ Oct 5 2007, 07:49 AM)

My company has a large number of software testers in several departments. We all use Subversion for version control, but we don't all use the same version of LabVIEW. Almost all testing we do uses TestStand for test flow control and we use several libraries of LabVIEW drivers to interface with the test hardware.

My problem is figuring out how to organize subversion to accomodate using several versions of LabVIEW libraries. We don't necessarily try to keep all libraries up to date. As new products come into our department, we try to take advantage of new technology, and of course new drivers may be needed as required functionality grows.

So, I understand trunks and tags. I suspect the answer is to use branches, but I'd like to hear some experienced opinions before I dive in to fix this and end up redoing it a dozen times. The current layout we use is to use a trunk to hold all the libraries in the user.lib and instr.lib directories. We use tags to capture snapshots specific to individual projects so we can rebuild a test setup. The next thing I need to figure out is how to continue development in LV8.5 without overwriting our 8.2 and code.

Lars,

I'm a kind of a lonesome LabVIEW-fighter here, so my knowledge of Subversion-related LabVIEW usage is limited. But I use LabVIEW since v3.x and combine it with SVN for about a year now.

What I do is to prefer single projects, even if a 'new' project heavily relates and is in fact derived (read 'copied') from an older one.

I use tags to mark important keystones in a development process, for example when a proptotype has reached a functional status, when a new operation mode was introduced/replaced etc. or when a new version as a complete replacement of an old one is created. A branch instead is used when a new version is needed in parallel with an old one.

And coming back to your multi-LV-versions setup, I'd probably prefer different versions of your libraries and drivers for each LV version. Takes a lot of extra space, on your hard disc as well as in SVN, but keeps independency between those versions. In my projects I had tried a kind of library tree (think of common sub-libraries), but this quickly turned into a whole mess during devellopment, as new relations and functions and modes turned up that did not really fit into the first library partition, so to say.

This is probably a good case to start LOOP, but there is always too much to do _now_ as to try to switch ;-(

As I said, thats just my limited view, but at this time it is the first reply to your posting ;-))

Greetings from Germany!

--

Uwe

[Lars915]

Uwe,

Thanks for the reply!! After some brainstorming among my developers, we came up with pretty much the same idea. It will be a bit cumbersome to maintain parallel development paths during the brief time my group is using different versions of LabVIEW, but we try to keep that time to a minimum so it shouldn't be too bad.

[Jim Kring]

Subversion 1.5, which is coming out soon will have native support for merge tracking between branches. This is a critical feature if you are planning on doing branched development over any sustained period.

Cheers,