andy@coma.UUCP (Andreas Lampen) (06/29/89)
>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
runyan@hpirs.HP.COM (Mark Runyan) (07/05/89)
>/ pcg@aber-cs.UUCP (Piercarlo Grandi) / 7:38 am Jun 30, 1989 / >But IMNHO this whole discussion is obviously vitiated by the usual >unfamiliarity of sw eng types with other fields of compsci. The discussion is still valid if a workable solution does not yet exist. If others in different "fields of compsci" can describe a solution that can be implemented, I hope they add to the discussion! >In particular sw >eng requires a lot of database technology, and database research also >embodies a lot of sw eng (e.g. data dictionaries, etc...), but I have seen >very few sw eng people realize that they ought to know about database >research. So, what is it we need to know and where can we look? Since a few of the people in the discussion use UNIX (or something similar), is there a tool or tool set which will do what we need? >Case in point: temporal databases. I always had this feeling that versioning >has been studied a lot by temporal database researchers, and it does not >apply just to databases of sw components. I would be interested in any research on versioning and merging of versions that might be available. If you can recommend any, please do. Perhaps you should also recommend a few "beginners" texts since I am apparently not familiar with database research, as I'm only an sw eng type... Mark Runyan