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

Re: Best Practices: Related but parallel versions

From: Jan Hendrik <list.jan.hendrik_at_gmail.com>
Date: Tue, 2 Sep 2008 11:27:01 +0200

Concerning Best Practices: Related but paralle
Marshall Feldman wrote on 1 Sep 2008, 16:56, at least in part:

> 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?


I have not used them so far, but have you checked if Externals can
do for you? Of course, if e.g. the core text is the same in both
spring and fall, with the exception that - within the very same text,
not in a separate file - in spring folks buy icecream and in fall a
Christmas tree, I doubt that externals will do that.

Jan hendrik

Freedom quote:

     In the long run, we shape our lives, and we shape ourselves.
     The process never ends until we die.
     And the choices we make are ultimately our own responsibility.
               -- Eleanor Roosevelt

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 11:25:28 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.