Adopting Subversion : Managing multiple streams

Hi

I am the Configuration administrator for my company and I am looking to migrate our configuration management from PVCS to Subversion.

Question: How do you manage multiple versions (streams) of a products ?

In reading Subversion documentation I can see how it works great on the Current Stream of a product but I don't see how people manage different streams of the same application other than first looking at the history and manually checking which is the current version for a specific file as a support release on a stream may have moved , making it tedious and error prone. I am sure this is not the case, but it is just my impression.

Background :

The issues I have is around Product release Stream versioning. We use PVCS to manage multiple streams of our product. To put it in perspective we have a medium term system that has around 5 main streams (Version6, Version7 .. ) , these tends created as the result of technology changes, but we have some 30 streams ( Verson 6.5.1, Version 8.0.1.) for various functionality changes, on each stream we provide then support releases 8.0.1.n. We use this the same configuration management system and policy on Source code, database, docs and tests results. Some 10 products with some 200 projects and holding about 10000 files/archives. We are able to extract all the relevant current versions of code, database, documents for any stream in a single extract.

We use PVCS , but its performance over the WAN makes it unusable , especially now as we move to contiguous integration. Whilst version numbers and labelling of those versions is important we make use PVCS feature called promotion groups. Most use it to track status of files through being in Development , Testing and Release. We use it for that, though have found that using it to manage streams makes it invaluable.

A promotion group is hierarchical so for a stream we have a promotion group like this Rel_8.2.0,Test_8.2.0 and Dev_8.2.0.

Basically when we create a new stream we baseline the artifacts (code,docs etc..) , by assigning a new release promotion group. A developer ( or any PVCS user ) has to select a promotion group the file gets assigned the promotion group Dev_8.2.0, if they check out the same file again then the Dev promotion group moves to new version.

This might not sound very important but forgetting all the other benefits that come with a promotion groups what it means is that the developer when working on a Release only has to remember the stream he is working on and he is guaranteed to always to pull out the correct version from PVCS of a file. When he checks in then it may branch and warning is duely dispalayed.

We actually create temporary projects for streams that are just views onto a master PVCS projects , sharing the same archives across all temporary projects, these temporary project just have the one promotion group for that stream. A developer then changes his default project in his IDE to point from one stream to another by changing the temporary project he is using.

Our build process then labels all the files and Shared files ( including common files , data base scripts) with the same build label which starts with the promotion group name, if a new version of a binary is created this build number is stored in the help about box for the product, making it a doodle on a support calls. Anyway.

In reading Subversion documentation I can see how it works great on the Current Stream of a product but I don't see how people manage different streams of the same application other than first looking at the history and manually checking which is the current version for a specific file as a support release on a stream may have moved
Received on 2008-08-16 17:12:08 CEST