Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!unido!tub!coma!andy
From: andy@coma.UUCP (Andreas Lampen)
Newsgroups: comp.software-eng
Subject: Re^2: Source Code Control
Message-ID: <415@coma.UUCP>
Date: 29 Jun 89 14:12:03 GMT
References: <370@umigw.MIAMI.EDU>
Organization: Technical University of Berlin, Germany (West)
Lines: 82

>steve@umigw.MIAMI.EDU (steve emmerson) writes:
>...
>The situation is this: version 2.0 of "foo.c" has been released with version 
>1.0 of The Product.  It has since been modified and is currently at version
>3.1 of version 1.7 of The Product.  A bug report on the 2.0 "foo.c" comes in.
>What to do?

>The originator of this example (sorry, I've forgotten the name) solved the
>problem by creating a (soon to be a dead-end) branch off of the 2.0 version
>of "foo.c" and shipping that off to the user.  Shape(1), on the other hand, 
>disallows branches.  I assume other configuration/revision management systems 
>also disallow branching.

>How, then, can this situation be handled by such non-branching systems?

Before answering the question I want to write a few general remarks
on the term "branching".

Normally when people speak of "branching" in the context of source
code control, they basically mean the possibility to retrieve an old
version of a file, modify it, and save the newly created version.  No
Problem - every version control system (at least every system I know)
provides this functionality.

In this context, a version control system has two different tasks:
- Storage (physical level) and
- Identification (logical level)
of versions.

The storage of multiple versions of a file is normally done by building
deltas for sake of space efficiency. This implies, that updates to
old versions lead to a physical derivation *tree* of deltas.
(BTW: On the physical level, SHAPE uses a technique quite similar to RCS.
 It stores a version derivation tree (!!) with backward deltas and
 - different to RCS - the last version of each branch stored completely.)

The more important matter of concern in respect to "branching" is the
identification of versions. RCS and SCCS use version numbers (like
1.3.2.1 or 1.3.1.1.1.1) that illustrate the physical derivation tree,
while SHAPE provides a more problem oriented version numbering
scheme that abstracts from the physical level. SHAPE's version
identification scheme differs between:
   - subsequent "revisions"
	with version numbers consisting of a *generation* and a
	*revision* number (eg. 2.0),
   - alternative "variants"
	with (possibly multiple) variant *names* additionally
	to generation and revision,
   - "patches" to older versions
	these might be bug fixes or customer specific modifications.
	Patches are also *named* (more details later in this article).

It is no problem to have variant or patch names like "2.1" or "1.1.1.1"
in order to emulate RCS' or SCCS' numbering scheme !


Now back to the original question: 
	How can bug fixes be managed with SHAPE ?
As I wrote in my previous posting, the SHAPE toolkit does not contain
a proper release management system yet. But it provides a means to
tag any number of attributes (of arbitrary length) to each version
which is much more than it seems to be at the first glance.

So this is how *we* manage patches to old versions with SHAPE:
- create a patch file with "diff -c"
- use the command
	"vadm -setuda patch1=@patchfile foo.c\[2.0\]"
  to attach the contents of "patchfile" (the @ indicates that a
  filename follows rather than an attribute value) as value of the
  attribute "patch1" to version 2.0 of foo.c.
- For identification of patched versions, we use either the patch
  names (in this case "patch1") or an additional attribute "patchlevel".
  The appropriate command is eg. "vl -U patch1".

Unfortunately, the recreation of patched versions is quite clumsy
(you have to do it by hand) up to now.

Andy

-- 
Andreas Lampen, TU Berlin
UUCP:   andy@coma (unido!coma!andy)
BITNET: andy@db0tui62