SPUG: Version control white paper

[Peter Darley]

Friends,
	The info on RCS seems to be paying off, as I can find explanations on how
it works on the web.  I'm really interested in the theory behind how things
are stored, rather than the specific file formats.
	The application I'm working on is for storing and reporting consumer
research.  It needs to know that there are different versions of the
questionnaire used, and be able to produce correct reports based on the
version of the questionnaire that the respondent actually answered, so it
needs to be able to reproduce any version of the questionnaire at any time
(so just being able to roll the database back to a previous version isn't
going to work).
	I am currently considering having a fairly simple change tracking system
that records deletes and additions to a questions list for the
questionnaire, then build any version of the questionnaire from that.  So,
if you want version 3 of a questionnaire the system would build version 1
from 'add' statements, then apply any 'add' and 'remove' questions for
version 2, and the same for version 3, which will end up with a full version
3 questionnaire.
	Thanks to everyone for their help and input!
Peter Darley

-----Original Message-----
From: Andrew Sweger [mailto:andrew at sweger.net]
Sent: Thursday, October 25, 2001 9:28 AM
To: Peter Darley
Cc: SPUG
Subject: Re: SPUG: Version control white paper


I'm not sure if the inner workings of CVS would apply as well to versioned
database objects. The traditional inner workings of CVS are based on rcs
(co, ci), diff, and ed. Those man pages give some information on the
revision file format (all those *,v files in the repository). There is a
project working on building a replacement of CVS called subversion that
may change some of these internal semantics (maybe).

  http://subversion.tigris.org/

It goes way beyond CVS and trys to answer those, "Why can't CVS do this?,"
questions.

The method of database object versioning that I have seen involved using a
pair of columns (fields) to bracket the period for which a row (record) is
valid. Usually these are date/time fields. There are several strategies
depending on an applications needs. I can try to explain more separately
if your interested.

At one time PostgreSQL had built in support for record versioning that
permitted rolling back the state of the database with respect to time. I
think this may have been dropped in recent versions in lieu of
performance.

On Thu, 25 Oct 2001, Peter Darley wrote:

> 	I'm putting together a system with perl/postgresql that will need to have
a
> good mechanism for maintaining multiple versions of database objects,
which
> is something that is quite new to me.  I have been searching the net to
find
> a white paper explaining the inner workings of CVS, without describing the
> actual code implementation, and have drawn a blank.  I was hoping that
> someone on this list could point me to such a thing, or to any white
> paper/algorithm discussion of other version control systems.

--
Andrew B. Sweger -- The great thing about multitasking is that several
                                things can go wrong at once.



 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/