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

Best Practices: Related but parallel versions

From: Marshall Feldman <marsh_at_uri.edu>
Date: Mon, 1 Sep 2008 16:56:36 -0400

Hi,

I'm new to Subversion and have been studying various documents. All the
examples dealing with parallel versions that I have encountered deal with
situations in which the versions eventually merge back into a single track.
For instance, the SVN Book gives two scenarios for branching -- release
branches and feature branches - in which development continues on, with
either later releases surpassing earlier ones or features added to the core
(trunk) project. In contrast, I am interested in situations such as the
following:

* A software product family having different versions of the product (e.g.,
Home, Professional, Server, Enterprise)
* A complex document, such as a manual or textbook, having different
versions targeted at different users (e.g., a Student Version, Instructor's
Version, etc.) and including associated files such as data files, test
questions, test answers, etc.
* Documents having the same basic content and structure with variations for
specific contexts. For instance, a syllabus for a course will vary not only
from year to year but also from semester to semester; the Spring Semester
may have Spring Break and 14 weeks, whereas the Fall Semester has only 13
weeks.
* A Web Site that varies for specific contexts. Continuing the syllabus
example, a web site for an online course will vary depending on if the
course is offered in the Fall or Spring Semesters.
* Any software product, document, web site, etc. that has different versions
for different locales, such as the USA and Great Britain.

In all these examples, the different versions will typically share a common
core of content, but each version will also have its own unique content. The
latter may be in addition to content in the core or replace content in the
core. Furthermore, development is ongoing. For example, next year's syllabus
will be different from this year's, and these differences should appear in
both the Fall and Spring versions of the syllabus; nonetheless, the Fall and
Spring versions will also differ from each other. They will never merge back
into a single trunk. Instead, they are permanently parallel versions.

What are the best practices for handling this class of projects?

Thanks.

        Marsh Feldman

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-02 05:54:06 CEST

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.