[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Models for multi-version promotion

From: Peter Howe <Peter.Howe_at_uk.linedata.com>
Date: 2005-03-04 11:26:31 CET


We currently use an old but powerful version control system based on VMS
hardware but we are planning to migrate to Subversion. We support and
maintain about 7 versions of our product at any one time (let's say 1.0,
2.0, 3.0 ... 7.0) and any changes that we decide to "back fit" to
earlier releases are automatically merged forward to all later releases
(and into the production stream - which is the latest [unreleased]
development stream.)

For each release, we use a pretty standard "promotion model" - i.e. code
is unit tested in a developer's working directory, then it's put into
"WIP" in order to bring it together with other developer's changes and
ensure it doesn't break our overnight builds. It is then promoted to
"TEST" for system testing and then "CAND" for integration testing. Once
everything has passed testing in a candidate (CAND) build, we may choose
to make that candidate build a RELEASE.

So to summarise, for each version, we have WIP, TEST, CAND (and RELEASE
which is just a tag of CAND.)

Finally, we organise our work in small functional units (each of which
we call a CR and which has number for tracking purposes.) Generally a
CR is unlikely to change more than about 10 files in a repository of
about 5000 files. Note that CRs may be tested (and hence promoted) in a
different order to the order in which they were developed.

Do any of you have experience of similar models and if so, how do you
manage your branching and merging?

I have been thinking I need a 1.0-WIP line, with a 1.0-TEST branch and a
1.0-CAND branch off that (which can be copied to mark a RELEASE.) Then
I need to branch 2.0-WIP from 1.0-WIP and then 2.0-TEST from 2.0-WIP and
2.0-CAND from 2.0-TEST, etc, etc...

When people want to start working on a CR (work unit), they'll create a
copy of the appropriate WIP line, tag the start of that line, make their
changes, mark the end of that line and merge back into the WIP stream.

But there's something about this which doesn't quite seem right. One
thing is that if a CR takes a long time to complete, it doesn't seem
easy to merge the changes which have gone into WIP during that time into
the CR branch (in order to stay up to date.) Also, the whole 1.0-WIP,
1.0-TEST etc. model described above doesn't really identify a clear
"main line" (trunk) which just seems wrong somehow.

Any advice, comments (or indeed criticism) will be very welcome!
Many thanks,

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 4 11:29:27 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.