DE69230452T2

DE69230452T2 - Verfahren und Vorrichtung zur Änderungskontrolle in mehreren Entwicklungsumgebungen

Info

Publication number: DE69230452T2
Application number: DE69230452T
Authority: DE
Inventors: Glenn Skinner
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1991-08-19
Filing date: 1992-08-10
Publication date: 2000-08-24
Anticipated expiration: 2012-08-11
Also published as: KR930004854A; EP0528617A2; EP0528617A3; JPH0744373A; KR0169327B1; DE69230452D1; US5481722A; EP0528617B1

Description

HINTERGRUND DER ERFINDUNG

1. Gebiet der Erfindung:

Diese Erfindung bezieht auf das Gebiet der Quellcodekontrolle bei der Computersoftwareentwickiung. Insbesondere bezieht sich die vorliegende Erfindung auf die Quellcodekontrolle für die Softwareentwicklung in wenigstens zwei zueinander in Beziehung stehenden Softwareentwicklungsumgebungen.

2. Technischer Hintergrund:

Bei einem großen Softwareentwicklungsprojekt 10 (Fig. 1a) arbeiten typischerweise verschiedene Programmierer oder Programmiergruppen 12a-12d miteinander, um eine einzige Software 14 zu entwickeln. Wie es in Fig. 1a veranschaulicht ist, ist die Software logisch in Abschnitte 16a-16d und 18a-18d unterteilt, welche jeweils verschiedene Personen oder Gruppen 12a-12d schreiben, in ihr die Fehler beseitigen und sie aktualisieren.
Es wurden unterschiedliche Quellcodemanagement-Softwareprogramme entwickelt, um ein effizientes Mittel zum Koordinieren und Dokumentieren der Programmieraktivitäten einer Entwicklungsgruppe bereitzustellen, beispielsweise das Source Code Control System (SCCS) und das Revision Control System (RCS). Typischerweise kontrolliert ein Quellcodemanagementsystem 20 (Fig. 1b) die Änderungen an einem Quellmodul 22, indem es zum Wächter des Quellmoduls wird. Um Speicherraum einzusparen, werden typischerweise nur die ursprüngliche Basis 24a und eine Beschreibung jeder nachfolgenden Änderungen (Delta) 24b-24d gespeichert. Darüber hinaus weist das Quellcodemanagementsystem 20 eine Sammlung von (nicht gezeigten) Werkzeugen zum Verwalten der Wiedergewinnung 26b und der Sicherung 26c jeder Edition eines Quellmoduls 28a und 28b auf. Sobald ein Quellmodul 22 in das Managementsystem 20 aufgenommen wurde 26a, kann eine Edition des Quellmoduls 24a-24c wiedergewonnen bzw. gelesen 26b und gesichert 26c werden, indem nur die geeigneten Werkzeuge des Managementsystems verwendet werden.
Wenn beispielsweise unter SCCS ein Quellmodul "program.c" 32 (Fig. 1c) unter dessen Kontrolle gebracht wird 36a, bringt SCCS das Quellmodul 34a in eine Kontrolldatei "s.program.c" 34 und weist eine SCCS-Identifikationsnummer (SID) "1.1,' zu, die sein Editionsniveau anzeigt. Von diesem Punkt an muß ein Entwickler das geeignete SCCS-Werkzeug (nicht gezeigt) verwenden, um die Edition "1.1" des "program.c" 38a zu "holen" 36b, um daran Änderungen vorzunehmen. Nachdem die Änderungen vorgenommen sind, hat der Entwickler in ähnlicher Weise die richtigen SCCS-Werkzeuge zu verwenden, um die Änderungen zu "speichern" 36c. SCCS hält dann die Änderungen als inkremeritales Delta 34b gegenüber dem ursprünglichen Quellmodul 34a fest, ordnet das Delta 34b innerhalb der Kontrolldatei "s.program.c" 34 an und weist dem Delta 34b ein neues SID "1.2" zu, was sein neues Editionsniveau anzeigt. Um eine nachfolgende Anforderung des Editionsniveaus "1.2" des "program.c" zu befriedigen, baut SCCS das Editionsniveau "1.2" auf, indem das ursprüngliche Quellmodul 34a und das inkrementale Delta 34b kombiniert werden.
Für eine nähere Beschreibung von SCCS und RCS siehe Rochkind, M. J., The Source Code Control System, National Conference on Software Engineering, ist Proceeding, Washington D. C., 11.-12. September 1975; Seiten 37-43 (IEEE Computer Society 1975); Thomas, R., "The Source Code Control System, Unixworld, Band 1, Nr. 3, Seiten 69-71 (1984); Tichy, W. F., Design, Implementation and Evaluation of a Revisions Control System, IEEE 6th Conference on Software Engineering, 13.-16. September 1982, Tokyo, Japan, Seiten 58- 67.
In der Praxis gibt es zu jedem Zeitpunkt zusätzlich zu der in der Entwicklung befindlichen Version 42a, 42b oder 42c (Fig. 2a), welche ständig aktualisiert wird, um Fehler zu beseitigen, neue Merkmale hinzuzufügen und vorhandene Möglichkeiten zu optimieren, andere im Test 44a oder 44b befindliche oder in der Praxis 46 unterstützte Versionen, welche ebenfalls aktualisiert werden, um Fehler zu beseitigen und neue Merkmale hinzuzufügen. Somit bieten viele Computersysteme eine Unterstützung für Hierarchien von zueinander in Beziehung stehenden Umgebungen zur Softwareentwicklung, beispielsweise das Network Software Environment (NSE), das auf von Sun Microsystems, Inc. aus Mountain View, Kalifornien, hergestellten Sun-Workstations unterstützt wird (Sun ist eine registrierte Handelsmarke der Sun Microsystems, Inc.).
Eine Umgebung 60 oder 61 ist eine benannte Hülle einer Sammlung von Objekten 64, 66 oder 65, 67 (Fig. 2b). Typischerweise sind die Objekte unter einem Verzeichnis 62, 63 organisiert. Eine Umgebung 60 oder 61 kann auf einer beliebigen Maschine 52, 54, 56 oder 58 in einem Netzwerk von Computern 60 erzeugt werden. Ein Objekt 64, 65, 66, oder 67 ist ein benannter Datenbehälter. Ein Objekt 64, 65, 66 oder 67 kann ein einfaches Objekt 66 oder 67 oder ein Verbundobjekt 64 oder 65 sein. Ein einfaches Objekt 66 oder 67 ist ein Objekt, das keine anderen Objekte enthält, beispielsweise eine Quelldatei. Ein Verbundobjekt 64 oder 65 ist eine Liste anderer Objekte, einschließlich anderer Verbundobjekte, beispielsweise eine Komponente, die eine Liste ihrer Quelldateien enthält. Die Objekte 64, 65, 66 und 67 eines Objekts 60, 61 können physisch auf irgendeiner Maschine 52, 54, 56 oder 58 in dem Netzwerk 50 angeordnet sein.
Typischerweise sind die Umgebungen 71-76 in einer Hierarchie 70 (Fig. 2c) organisiert. Beispielsweise kann ein Software-Entwicklungsprojekt eine Großeltern-Freigabe (Release)-Umgebung 71 zum Halten der letzten Revision des Projekts 80 und früherer Revisionen, die an die Kunden (nicht gezeigt) freigegeben worden sind, eine Mehrzahl von Elternintegrationsumgebungen 72, 73, die jeweils die letzte Revision einer Komponente 81 oder 82 des Projekts und früherer sich im Test befindlicher Revisionen halten, und eine Mehrzahl von Kindentwicklungsumgebungen 74, 75 und 76, die jeweils die letzten Editionen verschiedener Unterkomponenten 83-86, die durch einzelne Entwickler modifiziert worden sind, und (nicht gezeigte) frühere Editionen halten, umfassen. Die logische Beziehung zwischen den Umgebungen kann zu einem beliebigen Zeitpunkt neu definiert werden.
Ein Entwickler, der ein Objekt zu modifizieren wünscht, erwirbt eine neue Edition des Objekts 92 oder 93 in einer der Kindumgebungen aus der letzten Revision des Objekts 91 in der Elternumgebung des Kinds (Fig. 2d). Nach dem Modifizieren der neuen Edition des Objekts 92 oder 93 in der Kindumgebung bringt der Entwickler die Modifikationen in die letzte Revision des Objekts 91 oder 96 in der Elternumgebung ein, indem er die letzte Revision des Objekts 91 oder 96 mit der modifizierten Edition des Objekts 94 oder 95 in der Kindumgebung wieder in Einklang bringt. Sofern die letzte Revision des Objekts 91 in der Elternumgebung die gleiche Revision des Objekts 91 in der Elternumgebung ist, die zuvor für die modifizierte Edition des Objekts 94 in der Kindumgebung erlangt wurde, ist der Wiederabstimmprozeß erfolgreich, was zu einer in der Elternumgebung hergestellten neuen letzten Revision des Objekts 96 führt.
Wenn die letzte Revision des Objekts 96 in der Elternumgebung nicht dieselbe Revision des Objekts 91 in der Elternumgebung ist, die zuvor für die modifizierte Edition des Objekts 95 in der Kindumgebung erworben wurde, so ist der Wiederabstimmprozeß nicht erfolgreich, was zu der Initiierung des Resynchronisationsprozesses führt, um die Modifikationen der letzten Revision des Objekts 96 in die letzte Edition des Objekts 95 in der Kindumgebung einzubringen. Der Resynchronisationsprozeß erwirbt eine neue Edition des Objekts 97 in die Kindumgebung aus der neuen letzten Revision des Objekts 96 in der Elternumgebung. Nach dem Auflösen der Differenzen zwischen der modifizierten Edition des Objekts 95 und der erworbenen Edition des Objekts 97 wird die letzte Revision des Objekts 96 in der Elternumgebung wiederum mit der konsolidierten Edition des Objekts 98 in der Kindumgebung abgestimmt. Da die letzte Revision des Objekts 96 in der Elternumgebung ungeändert blieb, ist der Wiederabstimmprozeß erfolgreich, was dazu führt, daß eine weitere neue letzte Revision des Objekts 99 in der Elternumgebung hergestellt wird.
Für eine nähere Beschreibung der Network Software Environment siehe Network Software Environment, Reprint des Sun Technical Report, FE 197-0 (Copyright 1989, Sun Microsystems, Inc.).
Die herkömmlichen Quellcodemanagementsysteme haben, wenn sie im Kontext einer Hierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebungen verwendet werden, wenigstens einen signifikanten Nachteil, nämlich, daß sie nicht in der Lage sind, die gesamte Vorgeschichte der Änderungen an dem Quellmodul einfangen zu können. Dies ist unter Bezugnahme auf Fig. 2e veranschaulicht. Es sei angenommen, daß eine erste und eine zweite Kindumgebung (C1 und C2) 134, 136 jeweils eine Revision 1.1 eines Quellmoduls 102c und 102d von ihrer Großelternumgebung (GP) 130 über ihre Elternumgebung (P) 132 erworben haben. C1 erzeugt die Editionen 1.2, 1.3 und 1.4, welche als drei Deltas (d. h. Änderungen) 104, 106 und 108 in dieser Umgebung 134 gehalten werden. In ähnlicher Weise erzeugt C2 Editionen 1.2, 1.3, welche ebenfalls als zwei Deltas 110 und 112 in dieser Umgebung 136 gehalten werden.
Wenn C1 die letzte Revision 1.1 in P mit seiner letzten Edition 1.4 in Einklang bringt, wird nur eine einzige Revision 1.2, die als ein einziges Delta 114b gehalten wird, für die Deltastruktur 114a in P erzeugt. Die Details der Deltastruktur 104, 106 und 108 (d. h. die Vorgeschichte, die die ausgeführten Änderungen beschreibt) gehen verloren. Wenn jetzt C2 versucht, die letzte Revision 1.2 in P mit seiner letzten Revision 1.3 wieder in Einklang zu bringen, wird seine letzte Edition 1.3 automatisch mit der letzten Revision 1.2 in P resynchronisiert, was zu einer Kopie der letzten Revision 1.2 in P (nicht gezeigt) führt, die in C2 hergestellt wurde. C2 löst die Differenz auf, indem sie eine neue Edition 1.4 erzeugt, die als Delta 116 in seiner Umgebung 136 gehalten wird. Wenn C2 die letzte Edition 1.2 in P mit seiner letzten Edition 1.4 wieder in Einklang bringt, wird wiederum nur eine einzige Revision 173, die als einziges Delta 118b gehalten wird, für die gesamte Deltastruktur 118a in P erzeugt. Die Details der Deltastruktur 110, 112 und 116 (d. h. die Vorgeschichte, die die in C2 durchgeführten Änderungen beschreibt) gehen verlören.
In ähnlicher Weise wird dann, wenn die letzte Revision 1.1 in GP mit der letzten Edition 1.3 in P wieder in Einklang gebracht wird, eine einzige Edition 1.2, die als ein einziges Delta 120b gehalten wird, für die Deltastruktur 120a in GP erzeugt. Wenn somit eine Onkelumgebung (U) 138 die letzte Revision 1.2 in GP erwirbt, sieht sie nur eine einzige Änderung, die als ein einziges Delta 120c in U gehalten wird. Sie hat keinen Zugriff auf irgendwelche Details, die das einzige Delta 120c bilden (d. h. auf die Vorgeschichte, die die in C1 und C2 durchgeführten Änderungen beschreibt).

ZUSAMMENFASSENDE DARSTELLUNG DER ERFINDUNG

Es ist folglich eine Aufgabe der vorliegenden Erfindung, ein verbessertes Änderungskontrollsystem für Quellmodule, insbesondere Quellmodule in wenigstens zwei zueinander in Beziehung stehenden Entwicklungsumgebungen, zur Verfügung zu stellen.
Es ist eine Aufgabe der vorliegenden Erfindung, ein verbessertes Änderungskontrollsystem für Quellmodule, insbesondere für Quellmodule in einer Hierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebungen, zur Verfügung zu stellen.
Das Verfahren, die Einrichtung und das System gemäß der vorliegenden Erfindung lösen diese Aufgaben, indem ein Quellmodul und Änderungen an dem Quellmodul in zwei zueinander in Beziehung stehenden Softwareumgebungen als zwei Hierarchien von inkrementalen Deltas dargestellt und die Hierarchien ohne Anhäufung irgendwelcher der inkrementalen Deltas in einer der beiden Hierarchien verschmolzen werden, wenn die letzte Revision (Edition) des Quellmoduls in einer der Umgebungen mit der letzten Edition (Revision) des Quellmoduls in der anderen Umgebung wieder in Einklang gebracht (resynchronisiert) wird.
Das Verfahren, die Einrichtung und das System gemäß der vorliegenden Erfindung führen die Verschmelzung der Hierarchien inkrementaler Deltas aus, indem sie eine Ersetzungs- Struktur kombinierter Deltas aufbaut. Das Verfahren, die Einrichtung und das System gemäß der vorliegenden Erfindung bauen die unterschiedlichen Abschnitte der Ersetzungsstruktur kombinierter Deltas separat auf, einschließlich der detaillierten Liste von Deltas und einer Beziehungstabelle. Verschiedene Schritte und Mittel werden benutzt, um Zwei- Wege-Querbezüge zwischen den Deltas in den alten Hierarchien und den Deltas in der kombinierten Hierarchie zur Verfügung zu stellen, um zu bestimmen, ob ein neuer Zweig für die Ersetzungsstruktur kombinierter Deltas erforderlich ist, um Deltaidentifikationen zuzuweisen, um Vorgänger- und Nachfolgerdeltas zu verknüpfen und um Revision/Edition-Niveauidentifikationen zuzuweisen.

KURZBESCHREIBUNG DER ZEICHNUNGEN

Fig. 1a-1c veranschaulichen ein typisches bekanntes Quellcodemanagementsystem in einer einzigen Softwareentwicklungsumgebung.
Fig. 2a-2e veranschaulichen typische bekannte Quellcodemanagementsysteme in einer Hierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebungen.
Fig. 3 veranschaulicht eine anhand der Hardwareelemente organisierte physische Ansicht eines Netzwerks von Computersystemen, das durch die vorliegende Erfindung benutzt werden kann.
Fig. 4 veranschaulicht eine anhand der Systemsoftware organisierte logische Ansicht eines typischen Computersystems, wie es durch die vorliegende Erfindung benutzt wird.
Fig. 5 veranschaulicht eine logische Ansicht des bevorzugten Ausführungsbeispiels der Einrichtung gemäß der vorliegenden Erfindung im Kontext einer beispielhaften Hierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebungen.
Fig. 6 veranschaulicht eine logische Teilansicht der Deltastrukturdatei, die durch das Verfahren und die Einrichtung gemäß der vorliegenden Erfindung verwendet wird.
Fig. 7a-7d veranschaulichen den Betriebsablauf des Verfahrens und der Einrichtung gemäß der vorliegenden Erfindung in dem Kontext einer beispielhaften Hierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebungen.
Fig. 8 veranschaulicht die Anwendung des Verfahrens und der Einrichtung gemäß der vorliegenden Erfindung auf ein beispielhaftes Szenarium.

BEZEICHNUNGEN UND TERMINOLOGIE

Die folgende detaillierte Beschreibung wird weitgehend anhand von Programmprozeduren präsentiert, die auf einem Netzwerk von Computern ausgeführt werden. Diese prozeduralen Beschreibungen und Darstellungen sind diejenigen Mittel, die von Fachleuten verwendet, werden, um auf effektivste Weise das Wesen ihrer Arbeit anderen Fachleuten zu übermitteln.
Unter einer Prozedur wird hier und im allgemeinen eine in sich konsistente Sequenz von Schritten verstanden, die zu einem gewünschten Ergebnis führen. Diese Schritte sind solche, die physikalische Bearbeitungen physikalischer Grö ßen erfordern. Üblicherweise, jedoch nicht notwendigerweise, nehmen diese Größen die Form elektrischer oder magnetischer Signale an, die gespeichert, übertragen, kombiniert, verglichen und auf andere Weise bearbeitet werden können. Hauptsächlich aus Gründen der allgemeinen Verwendung hat es sich gelegentlich als geeignet erwiesen, auf diese Signale als Bits, Werte, Elemente, Symbole, Objekte, Zeichen, Terma, Nummern oder dergleichen Bezug zu nehmen. Es sei jedoch daran erinnert, daß all diese und ähnliche Begriffe den richtigen physikalischen Größen zugeordnet sein sollen und bloß geeignete Bezeichnungen sind, die auf diese Größen angewendet werden.
Darüber hinaus werden die ausgeführten Bearbeitungen oftmals mit Begriffen wie Addieren oder Vergleichen bezeichnet, welche üblicherweise den durch einen menschlichen Bediener ausgeführten geistigen Operationen zugeordnet sind. Keine derartige Fähigkeit eines menschlichen Bedieners ist bei irgendeiner der hier beschriebenen Operationen, welche Teil der vorliegenden Erfindung bilden, erforderlich und in den meisten Fällen auch nicht erwünscht; die Operationen sind Maschinenoperationen. Nützliche Maschinen zum Durchführen der Operationen gemäß der vorliegenden Erfindung umfassen digitale Mehrzweckcomputer oder andere ähnliche Einrichtungen. In sämtlichen Fällen sei an den Unterschied zwischen den Verfahrensoperationen beim Betreiben eines Computers und dem Verfahren der Berechnung selbst erinnert. Die vorliegende Erfindung bezieht sich auf Verfahrensschritte zum Betreiben eines Computers bei der Verarbeitung elektrischer oder anderer physikalischer Signale, um weitere gewünschte physikalische Signale zu erzeugen. Die vorliegende Erfindung bezieht sich darüber hinaus auf Einrichtungen zum Durchführen dieser Operationen. Diese Einrichtungen können speziell für die erforderlichen Zwecke konstruiert sein oder können einen Mehrzweckcomputer umfassen, der selektiv durch ein in dem Computer gespeichertes Computerprogramm aktiviert oder umkonfiguriert wird. Die hier angegebenen Prozeduren beziehen sich nicht vollständig auf einen speziellen Computer oder eine andere spezielle Einrichtung. Insbesondere können zahlreiche Mehrzweckmaschinen mit den gemäß den hier angegebenen Lehren geschriebenen Prozeduren verwendet werden, oder es kann sich als geeigneter erweisen, spezialisiertere Einrichtungen zum Ausführen der erforderlichen Verfahrensschritte zu konstruieren. Die erforderliche Struktur für eine Vielzahl dieser Maschinen wird aus der unten angegebenen Beschreibung klar.

DETAILLIERTE BESCHREIBUNG DER ERFINDUNG

Es werden ein Verfahren und Einrichtungen zum Kontrollieren von Änderungen eines Quellmoduls offenbart, welche insbesondere Anwendung auf eine Softwareentwicklung in wenigstens zwei zueinander in Beziehung stehenden Entwicklungsumgebungen finden. In der folgenden Beschreibung werden aus Gründen der Erläuterung spezielle Anzahlen, Materialien und Konfigurationen angegeben, um ein besseres Verständnis der vorliegenden Erfindung zu erreichen. Für einen Fachmann ist es jedoch klar, daß die vorliegende Erfindung auch ohne die speziellen Details ausgeführt werden kann. An anderen Stellen werden gut bekannte Systeme in schematischer oder Blockdarstellungsform gezeigt, um die vorliegende Erfindung nicht unnötigerweise zu verdunkeln.
Es wird jetzt auf Fig. 3 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die eine nach der Hardware organisierte physische Ansicht eines Netzwerks von Computersystemen veranschaulicht, die von der vorliegenden Erfindung verwendet werden. Das Netzwerk von Computersystemen 140 umfaßt wenigstens ein Computersystem 141a. Wenn mehr als ein Computersystem 141a und 141b benutzt werden, sind die Computersysteme 141a und 141b miteinander über ein Netzwerk 142 gekoppelt. Jedes Computersystem 141a oder 141b weist eine zentrale Verarbeitungseinheit (CPU) 143a oder 143b, eine Speichereinheit 145a oder 145b, eine Massenspeichereinheit 147a oder 147b und eine Eingabe/Ausgabe(I/O)- Einrichtung 149a oder 149b auf. Die Eigenschaften dieser Hardwareelemente jedes der Computersysteme 141a oder 141b, wie beispielsweise die Geschwindigkeit oder Größe, können voneinander abweichen. Diese Hardwareelemente sind diejenigen, die typischerweise in den meisten Mehrzweckcomputersystemen und in nahezu allen speziellen Computersystemen zu finden sind. Tatsächlich sind die verschiedenen Hardwareelemente, die in jedem der Computersysteme 141a und 141b enthalten sind, vorgesehen, diese breite Kategorie von Datenverarbeitungssystemen zu repräsentieren. Spezielle Beispiele geeigneter Datenverarbeitungssysteme, die die Rolle dieser Computersysteme 141a und 141b ausfüllen können, umfassen die von Sun Microsystems, Inc., Mountain View, Kalifornien, hergestellten Computersysteme. Andere Computersysteme, die ähnliche Fähigkeiten aufweisen, können selbstverständlich auf einfache Weise angepaßt werden, um die unten beschriebenen Funktionen durchzuführen.
Es wird auf Fig. 4 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die eine durch ihre Systemsoftware organisierte logische Ansicht eines typischen Computersystems veranschaulicht, das von der vorliegenden Erfindung verwendet wird. Die Systemsoftware 150 umfaßt ein Betriebssystem 151, ein Dateisystem 152 und wenigstens einen Sprachcompiler 153. Die Anwendungen 154, die auf den Computersystemen 150 ausgeführt werden, verwenden die darunter liegenden Systemdienste 151-153, die von der Systemsoftware angeboten werden. Die auf jedem der Computersysteme verwendete Systemsoftware kann unterschiedlich sein, vorausgesetzt, sie bietet äquivalente Funktionen und ist in der Lage, mit den anderen zu kommunizieren. Diese Softwareelemente sind diejenigen, die üblicherweise bei den meisten Mehrzweckcomputersystemen und nahezu sämtlichen speziellen Computersystemen zu finden sind. Tatsächlich stehen die verschiedenen Softwareelemente, die in jedem der Computersysteme enthalten sind, stellvertretend für diese breite Kategorie von Systemsoftware. Spezielle Beispiele einer ge eigneten Systemsoftware, die die Rolle dieser Systemsoftware 150 der von der vorliegenden Erfindung verwendeten Computersysteme ausfüllen können, umfassen das UNIX-Betriebssystem, sein Dateisystem und seine Shell-Kommandosprache (UNIX ist ein registriertes Warenzeichen von AT & T). Andere Systemsoftware, die ähnliche Fähigkeiten aufweist, kann selbstverständlich auf einfache Weise angepaßt werden, um die unten beschriebenen Funktionen durchzuführen.
Es wird jetzt auf Fig. 5 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die eine logische Ansicht des bevorzugten Ausführungsbeispiels der Einrichtung gemäß der vorliegenden Erfindung im Kontext einer beispielhaften Hierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebungen veranschaulicht. Das bevorzugte Ausführungsbeispiel der Einrichtung gemäß der vorliegenden Erfindung umfaßt auf dem Netzwerk von Computersystemen, die die oben beschriebene Systemsoftware aufweisen, eine Mehrzahl von ausgeführten Prozeduren 181-186 und eine Mehrzahl von Deltastrukturdateien 164, 194, 204 und 214 und eine Mehrzahl von Arbeitsdateien (working files) 170-177, die gespeichert werden. Die Prozeduren 181-186 gestatten in Verbindung mit den Deltastrukturdateien 164, 194 und 204, 214 und den Arbeitsdateien 170-177, daß die Änderungen an einem Quellmodul in der Beispielhierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebunden 160 ohne Verlust irgendwelcher Details der Änderungsvorgeschichte kontrolliert werden. Obwohl das Verfahren und die Einrichtungen gemäß der vorliegenden Erfindung im Kontext der Kontrolle von Änderungen eines Quellmoduls in einer Beispielhierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebungen beschrieben werden, sei angemerkt, daß die vorliegende Erfindung nicht auf ein einziges Quellmodul und auch nicht auf hierarchische Softwareentwicklungsumgebungen beschränkt ist. Die vorliegende Erfindung ist anwendbar auf die Kontrolle von Änderungen einer beliebigen Anzahl von Quellmodulen in zwei beliebigen zueinander in Beziehung stehenden Softwareentwicklungsumgebungen. Die zueinander in Beziehung stehenden Softwareentwicklungsumgebungen können in einer beliebigen Topologie organisiert sein.
Die Prozeduren umfassen eine Aufrechterhaltungsprozedur 181, eine Replikationsprozedur 182, eine Verschmelzungsprozedur 183, eine Tabellenaufbauprozedur 184, eine Listenaufbauprozedur 185 und eine Ebenenidentifikationszuweisungsprozedur 186. Die (als in der Großeltern(GP)-Umgebung 161 ausgeführt gezeigten) Prozeduren 181-186 können in irgendeiner der Entwicklungsumgebungen 161, 191, 201 oder 211 oder in einer beliebigen Kombination der Entwicklungsumgebungen 161, 191, 201 und 211 ausgeführt werden. Darüber hinaus können die gleichen Kopien dieser Prozeduren 181-186 zwischen den Entwicklungsumgebungen 161, 291, 201 und 211 auf vielfältige Weise unter Verwendung der von der obenbeschriebenen Systemsoftware zur Verfügung gestellten Systemdienste geteilt und zugegriffen werden.
Die Deltastrukturdateien weisen wenigstens eine Deltastrukturdatei 164, 194, 204 oder 214, jeweils eine für jede Umgebung 161, 191, 201 oder 211, auf. Wie oben beschrieben, kann auf die Deltastrukturdateien 164, 194, 104 und 214 durch die Prozedur 181-186 auf vielfältige Weise unter Verwendung der Systemdienste der oben beschriebenen Systemsoftware zugegriffen werden. Die Arbeitsdateien 170-177 umfassen Eingabetabellen A und B, 170 und 171, eine Ausgabetabelle 172, Zwei-Wege-Assoziativ-Arrays A und B, 173 und 174, Arbeitslisten A und B, 175 und 176, und eine kombinierte Deltastruktur 177. In ähnlicher Weise können die (als in der Großeltern(GP)-Umgebung 161 gespeichert gezeigten) Arbeitsdateien 170-177 in irgendeiner der Entwicklungsumgebungen 161, 191, 201 oder 211 oder in einer beliebigen Kombination der Entwicklungsumgebungen 161, 191, 201 und 211 gespeichert werden. In gleicher Weise können dieselben Kopien dieser Arbeitsdateien 170-177 unter den Entwicklungsumgebungen 161, 191, 201 und 211 auf vielfältige Weise unter Verwendung der von der oben beschriebenen Systemsoftware zur Verfügung gestellten Systemdienste geteilt und zugegriffen werden.
Es wird jetzt auf Fig. 6 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die eine partielle logische Ansicht der von der vorliegenden Erfindung verwendeten Deltastrukturdatei veranschaulicht. Jede Deltastrukturdatei dient dem Speichern eines Quellmoduls und seiner nachfolgenden Änderungen als Hierarchie von inkrementalen Deltas. Die ursprüngliche Form des Quellmoduls ist als Wurzeldelta (root delta) gespeichert. Änderungen an dem Quellmodul und seine Revisionen/Editionen werden als inkrementale Deltas gespeichert. Die Deltastrukturdatei kann mit einer Vielzahl logischer Organisationen implementiert werden. Das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung benutzt eine logische Organisation, die durch SCCS unterstützt wird. Eine SCCS-kompatible Deltastrukturdatei 220 weist eine Tabelle von Deltabeziehungen 224 und eine Liste von Änderungsdeltas 234 auf.
Die Tabelle von Deltabeziehungen 224 umfaßt wenigstens einen zeitlich geordneten Quelleneintrag 226, der eine bestimmte Deltabeziehung zwischen zwei Deltas beschreibt. Jeder zeitlich geordnete Tabelleneintrag 226 umfaßt eine Eintragsstartsteuerzeile 228, der eine Deltabeziehungszeile 230 und null oder mehr Kommentarzeilen 231 folgen, und endet mit einer Eintragsendesteuerzeile 232. Jede Deltabeziehungszeile 230 umfaßt einen Eintragsbeziehungszeilencode, der das Wesen der Zeile bezeichnet, einen Änderungsidentifizierer, der die Revisions/Editionsebene des dem Eintrag entsprechenden Delta anzeigt, eine Deltaseriennummer, die das zugehörige Delta des Eintrags identifiziert, und eine Vorgängerseriennummer, die den Vorgänger des zugehörigen Deltas des Eintrags identifiziert. Jede Eintragsstartsteuerzeile 228 umfaßt einen Eintragssteuerzeilencode, der den Beginn eines Tabelleneintrags anzeigt, und die Anzahl der Zeilen, die in dem zugehörigen Delta des Eintrags einge fügt, gelöscht und ungeändert sind. Die Anzahl der eingefügten oder gelöschten Zeilen kann gleich Null sein. Jede Kommentarzeile 231 umfaßt einen Eintragskommentarzeilencode, der das Wesen der Zeile bezeichnet, gefolgt von einer Zeile beschreibender Kommentare. Jede Eintragsendesteuerzeile 232 umfaßt einen Eintragssteuerzeilencode, der das Ende eines Tabelleneintrags anzeigt.
Die Liste von Änderungsdeltas 234 umfaßt wenigstens ein Delta 236, das bei wenigstens einer Änderung eingefangen wurde. Jedes Delta 236 umfaßt eine Deltastartsteuerzeile 238, die von null oder mehr Deltatextzeilen 240 gefolgt wird, und endet mit einer Deltaendesteuerzeile 244. Jede Gruppe von Deltatextzeilen 240 reflektiert eine spezielle Änderung. Jede Deltastartsteuerzeile 238 umfaßt einen Deltasteuerzeilencode, der den Beginn eines Deltas anzeigt, einen Deltaaktionscode, der anzeigt, ob die Deltatextzeilen eingefügt oder gelöscht werden sollen, und eine Deltaseriennummer, die das Delta eindeutig identifiziert. Jede Deltaendesteuerzeile 244 umfaßt einen Deltasteuerzeilencode, der das Ende eines Deltas anzeigt.
Es wird jetzt wieder auf Fig. 5 Bezug genommen; die Eingabetabellen A und B, 170 und 171, die Ausgabetabelle 172, die Zwei-Wege-Arrays A und B, 173 und 174, die Arbeitslisten A und B, 175 und 176, die Ausgabeliste 177 und die kombinierte Deltastruktur 178 dienen dem Aufbau einer kombinierten Deltastrukturdatei auf der Grundlage einer Eltern- und einer Kinddeltastrukturdatei. Die Eingabetabellen A und B, 170 und 171, dienen dem Speichern der Eltern- und Kind-Deltabeziehungstabellen. Die Ausgabetabelle 172 dient dem Speichern der kombinierten Deltabeziehungstabelle. Folglich weisen die Eingabetabellen A und B, 170 und 171, und die Ausgabetabelle 172 das gleiche Format wie die früher beschriebenen Eltern- und Kind-Deltabeziehungstabellen auf. Die Zwei-Wege-Arrays A und B, 173 und 174, dienen zur Herstellung von Querbezügen der Deltas in den Eingabetabellen A und B, 170 und 171, und der kombinierten Deltas in der Ausgabetabelle 1'72 zueinander. Jedes der Zwei-Wege-Arrays A oder B umfaßt eine Mehrzahl von Zwei-Wege-Querbezügen (die nicht gezeigt sind). Jeder Zwei-Wege-Querbezug stellt einen Querbezug zwischen einem Delta in der Eingabetabelle A oder B zu einem Delta in der Ausgabetabelle oder umgekehrt her. Die Querbezüge werden unter Verwendung der zugehörigen Deltaseriennummern in jeder Tabelle aufrechterhalten. Die Arbeitslisten A und B, 125 und 176, dienen dem Speichern der Eltern- und Kindlisten der Deltas. Die Ausgabeliste 177 dient dem Speichern der kombinierten Liste von Deltas. Die kombinierte Deltastruktur 178 dient dem Speichern der kombinierten Deltastruktur. Das Aufbauen einer kombinierten Deltastruktur auf der Grundlage einer Eltern- und einer Kind-Deltastrukturdatei wird unten detaillierter erörtert.
Es wird weiterhin auf Fig. 5 Bezug genommen; die Aufrechterhaltungsprozedur 181 dient dem Aufrechterhalten des Quellmoduls als Wurzeldelta (root delta) und seiner nachfolgenden Änderungen als Zweigdeltas in einer Deltastrukturdatei in jeder der Entwicklungsumgebungen. Die Aufrechterhaltungsprozedur 181 wird durch die Benutzer der Entwicklungsumgebungen aufgerufen. Die Aufrechterhaltungsprozedur kann mit Hilfe von Werkzeugen einer Vielzahl von Standardquellcodemanagementsystemen implementiert werden, vorausgesetzt, daß diese mit der für die Deltastrukturdateien verwendeten logischen Organisation kompatibel sind. Die Aufrechterhaltungsprozedur 181 des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung umfaßt eine Mehrzahl von SCCS-Werkzeugen zum Wiedergewinnen einer bestimmten Revision/Edition des Quellmoduls und zum Speichern von Änderungen einer bestimmten Revision/Edition des Quellmoduls zurück als Änderungsdelta in das Basisquellmodul.
Die Replikationsprozedur 182 dient zum Replizieren der Deltastrukturdatei einer Elternumgebung in eine ihrer Kindumgebungen, wenn die letzte Revision des Quellmoduls in der Elternumgebung in einer der Kindumgebungen erworben wird.
Die Replikationsprozedur 182 wird indirekt durch den Benutzer der erwerbenden Kindumgebung aufgerufen, wenn er die Erwerbung anfordert. Die Replikationsprozedur 182 kann mit irgendeinem gut bekannten Dateikopierwerkzeug implementiert werden. Die Replikationsprozedur 182 des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung ist das Standardbetriebssystem-Dateikopierwerkzeug.
Die Verschmelzungsprozedur 183 dient dem Verschmelzen einer Elterndeltastrukturdatei mit einer Kinddeltastrukturdatei, wenn die letzte Edition des Quellmoduls in der Kindumgebung mit der letzten Revision des Quellmoduls in der Elternumgebung resynchronisiert wird, und umgekehrt, wenn die letzte Revision des Quellmoduls in der Elternumgebung wieder mit der letzten Edition des Quellmoduls in der Kindumgebung in Einklang gebracht wird. Die Verschmelzungsprozedur 183 wird indirekt durch die Benutzer in den Kindumgebungen aufgerufen, wenn sie eine Resynchronisation oder Wiederabstimmung anfordern. Die Verschmelzungsprozedur 183 kann in einer beliebigen Programmiersprache implementiert sein. Der Betriebsablauf der Verschmelzungsprozedur 183 wird unten im Detail erörtert.
Die Tabellenaufbauprozedur 184 und die Listenaufbauprozedur 185 dienen dem Aufbauen einer kombinierten Deltabeziehungstabelle und einer kombinierten Liste von Deltas auf der Grundlage der Eltern- und Kindtabellen der Deltabeziehungen und der Eltern- und Kindlisten der Deltas einer Eltern- und einer Kinddeltastrukturdatei. Diese Aufbauprozeduren, 184 und 185, werden von der Verschmelzungsprozedur 183 aufgerufen. Diese Aufbauprozeduren, 184 und 185, können in einer beliebigen Programmiersprache implementiert sein. Der Operationsablauf dieser Aufbauprozeduren, 184 und 185, wird unten detaillierter erörtert.
Die Ebenenidentifikations(ID)-Zuweisungsprozedur 186 dient dem Zuweisen einer Änderungsidentifikation zu einem Delta. Die Ebenen-ID-Zuweisungsprozedur 185 muß in der Lage sein, in Betracht zu ziehen, ob ein neuer Zweig zu einer Deltastruktur hinzugefügt wird, wenn sie die Änderungsidentifikation zuweist. Die Ebenen-ID-Zuweisungsprozedur 186 wird durch die Aufrechterhaltungsprozedur 181 und die Verschmelzungsprozedur 183 aufgerufen. Die Ebenen-ID-Zuweisungsprozedur 186 kann mit den Werkzeugen einer Vielzahl von Standardquellcodekontrollsystemen implementiert werden, vorausgesetzt, daß diese mit der für die Deltastrukturdateien verwendeten logischen Organisation kompatibel sind. Die Ebenen-ID-Zuweisungsprozedur 186 des bevorzugten Ausführungsbeispiels der vorliegenden Erfindung umfaßt eine Mehrzahl von SCCS-Prozeduren zum Zuweisen von Änderungsidentifikationen zu Änderungsdeltas, die zu vorhandenen Zweigen oder neuen Zweigen hinzugefügt werden.
Es wird jetzt auf die Fig. 7a und 7b Bezug genommen, in denen Blockdarstellungen gezeigt sind, die den Betriebsablauf des Verfahrens und der Einrichtungen gemäß der vorliegenden Erfindung im Kontext einer Beispielhierarchie von zueinander in Beziehung stehenden Softwareentwicklungsumgebungen veranschaulichen. Es wird zunächst auf Fig. 7a Bezug genommen. Anfänglich wird das Quellmodul als Wurzeldelta in einer Wurzelhierarchie inkrementaler Deltas in einer Wurzelumgebung gehalten, Block 255, wobei die Aufrechterhaltungsprozedur in Verbindung mit der Ebenen-ID-Zuweisungsprozedur verwendet wird. Nachfolgende Änderungen an dem Quellmodul und an seinen Revisionen in der Wurzelumgebung werden als inkrementale Deltas in der Wurzelhierarchie inkrementaler Deltas gehalten, Block 254, wobei die Aufrechterhaltungsprozedur in Verbindung mit der Ebenen-ID-Zuweisungsprozedur verwendet wird. Die gesamte Wurzelhierarchie inkrementaler Deltas wird repliziert, um eine erste Generation einer Nachkommenshierarchie der Wurzelhierarchie inkrementaler Deltas in einer ersten Generation einer Nachkommensumgebung zu reproduzieren, wenn die letzte Revision des Quellmoduls in der Wurzelumgebung durch eine erste Generation einer Nachkommensumgebung unter Verwendung der Replikationsprozedur erworben wird, Block 256. Dann werden nachfolgende Änderungen an dem Quellmodul und seiner Editionen in der ersten Generation einer Nachkommensumgebung als Zweigdeltas in der ersten Generation einer Nachkommenshierarchie der Wurzelhierarchie inkrementaler Deltas gehalten, Block 258, wobei die Aufrechterhaltungsprozedur in Verbindung mit der Ebenen-ID-Zuweisungsprozedur verwendet wird.
Die Wurzelhierarchie inkrementaler Deltas wird mit der ersten Generation der Nachkommenshierarchie der Wurzelhierarchie inkrementaler Deltas verschmolzen, um die letzte Edition des Quellmoduls in der Nachkommensumgebung der ersten Generation mit der letzten Revision des Quellmoduls in der Wurzelumgebung zu resynchronisieren, Block 260, wobei die Verschmelzungsprozedur in Verbindung mit den Aufbauprozeduren und der Ebenen-ID-Zuweisungsprozedur verwendet wird. In ähnlicher Weise wird die Nachkommenshierarchie der ersten Generation der Wurzelhierarchie inkrementaler Deltas mit der Wurzelhierarchie inkrementaler Deltas verschmolzen, um wieder die letzte Revision des Quellmoduls in der Wurzelumgebung mit der letzten Edition des Quellmoduls in der Nachkommensumgebung der ersten Generation in Einklang zu bringen, Block 262, wobei die Verschmelzungsprozedur in Verbindung mit den Aufbauprozeduren und der Ebenen-ID-Zuweisungsprozedur verwendet wird.
Zusätzlich wird dann, wenn die Hierarchie von Softwareentwicklungsumgebungen mehr als eine Nachkommensgeneration von Umgebungen aufweist, eine Nachkommenshierarchie der nten Generation der Wurzelhierarchie inkrementaler Deltas in einer Nachkommensumgebung der n-ten Generation repliziert, um eine Nachkommenshierarchie der n + 1-ten Generation der Wurzelhierarchie inkrementaler Deltas in einer Nachkommensumgebung der n - i-1--ten Generation, einer direkten Nachkommensumgebung der n-ten Generation von Nachkommensumgebungen, zu reproduzieren, um die letzte Revision des Quellmoduls in der Nachkommensumgebung der n-ten Generation für die Nachkommensumgebung der n + 1-ten Generation unter Ver wendung der Replikationsprozedur zu erwerben, Block 266. In ähnlicher Weise werden nachfolgende Änderungen des Quellmoduls und seiner Editionen in der Nachkommensumgebung der n + 1-ten Generation als Zweigdeltas der Nachkommenshierarchie der n + 1-ten Generation der Wurzelhierarchie inkrementaler Deltas unter Verwendung der Aufrechterhaltungsprozedur in Verbindung mit der Ebenen-ID-Zuweisungsprozedur aufrechterhalten, Block 268.
In gleicher Weise wird die Nachkommenshierarchie der nten Generation der Wurzelhierarchie inkrementaler Deltas mit der Nachkommenshierarchie der n + 1-ten Generation der Wurzelhierarchie inkrementaler Deltas verschmolzen, um die letzte Edition des Quellmoduls in der Nachkommensumgebung der n + 1-ten Generation mit der letzten Revision des Quellmoduls in der Nachkommensumgebung der n-ten Generation unter Verwendung der Verschmelzungsprozedur in Verbindung mit den Aufbauprozeduren und der Ebenen-ID-Zuweisungsprozedur zu resynchronisieren, Block 270. Die Nachkommenshierarchie der n + 1-ten Generation der Wurzelhierarchie inkrementaler Deltas wird mit der Nachkommenshierarchie der n-ten Generation der Wurzelhierarchie inkrementaler Deltas verschmolzen, um wieder die letzte Revision des Quellmoduls in der Nachkommensumgebung der n-ten Generation mit der letzten Edition des Quellmoduls in der Nachkommensumgebung der n + 1- ten Generation unter Verwendung der Aufrechterhaltungsprozedur in Verbindung mit den Aufbauprozeduren und der Ebenen-ID-Zuweisungsprozedur in Einklang zu bringen.
Es wird jetzt auf Fig. 7 Bezug genommen. Die Verschmelzungsprozedur verschmilzt eine Hierarchie inkrementaler Deltas mit einer anderen Hierarchie inkrementaler Deltas, Blöcke 260, 262, 270 oder 272, indem sie die Tabellenaufbauprozedur und die Listenaufbauprozedur aufruft, um eine kombinierte Tabelle von Deltabeziehungen und eine kombinierte Liste von Deltas auf der Grundlage der zwei Tabellen von Deltabeziehungen und der zwei Listen von Deltas der Deltastrukturdateien der zwei Hierarchien inkrementaler Deltas aufzubauen, Blöcke 280-294. In ihrer gegenwärtig bevorzugten Form bauen die Tabellenaufbau- und Listenaufbauprozeduren die kombinierte Tabelle von Deltabeziehungen und die kombinierte Liste von Deltas gleichzeitig auf. Dann baut die Verschmelzungsprozedur eine Ersetzungsdeltastrukturdatei auf der Grundlage der kombinierten Tabelle von Deltabeziehungen und kombinierten Listen von Deltas auf und ersetzt die Deltastrukturdatei der Zielhierarchie inkrementaler Deltas durch die Ersetzungsdeltastruktur, Block 296. Wenn die Eingabetabellen in absteigender chronologischer Reihenfolge gehalten werden, kehrt die Verschmelzungsprozedur die Reihenfolge der Tabelleneinträge in der kombinierten Tabelle von Deltabeziehungen um, wenn sie die Ersetzungsdeltastruktur aufbaut.
Es wird weiterhin auf Fig. 7b Bezug genommen. Anfänglich initialisiert die Tabellenaufbauprozedur die Eingabetabellen A und B derart, daß sie jeweils gleich den beiden Tabellen der Deltabeziehungen sind, Block 280, sowie die Ausgabetabelle derart, daß sie leer ist, Block 282. Die Tabellenaufbauprozedur initialisiert darüber hinaus die Zwei- Wege-Assoziativarrays A und B derart, daß sie leer sind, Block 284. In ähnlicher Weise initialisiert die Listenaufbauprozedur die Arbeitslisten A und B derart, daß sie jeweils gleich den beiden Listen von Deltas sind, Block 280, und die Ausgabeliste derart, daß sie leer ist, Block 282. Dann entfernt die Aufbauprozedur einen Tabelleneintrag aus einer der beiden Eingabetabellen A und B selektiv, Block 286. Nach dem Entfernen eines Tabelleneintrags aktualisiert die Aufbauprozedur eines der Arrays auf der Grundlage des entfernten Tabelleneintrags, Block 288. Dann modifiziert die Tabellenaufbauprozedur den entfernten Tabelleneintrag in bedingter Weise und gibt den modifizierten Tabelleneintrag in die Ausgabetabelle aus, Blöcke 290 und 299. In ähnlicher Weise entfernt die Listenaufbauprozedur das zugehörige Delta aus einer der beiden Arbeitslisten A und B, Block 286, nachdem die Tabellenaufbauprozedur das Aktuali sieren eines der beiden Arrays beendet, den entfernten Tabelleneintrag bedingt modifiziert und den entfernten Tabelleneintrag in die Ausgabetabelle ausgegeben hat. Die Listenaufbauprozedur ersetzt in bedingter Weise die Deltaseriennummer des zugehörigen Deltas. Die Tabellenaufbau- und Listenaufbauprozeduren wiederholen das selektive Entfernen, Block 286, das Aktualisieren des Arrays, Block 288, das bedingte Modifizieren, Block 290, und das bedingte Ausgeben, Block 292, bis beide Eingabetabellen A und B leer geworden sind, Zweig 294a.
Die Tabellenaufbauprozedur entfernt Tabelleneinträge aus den Eingabetabellen A und B, Black 286, auf folgende Weise. Wenn die Eingabetabelle A leer ist, entfernt die Tabellenaufbauprozedur den ältesten Eintrag der Eingabetabelle B. Wenn die Eingabetabelle B leer ist, entfernt die Tabellenaufbauprozedur den ältesten Eintrag der Eingabetabelle A. Wenn beide Eingabetabellen A und B nicht leer sind und die ältesten Einträge der Eingabetabellen A und B Duplikate voneinander sind, entfernt die Tabellenaufbauprozedur den ältesten Eintrag aus der Eingabetabelle B. Wenn beide Eingabetabellen A und B nicht leer sind und die ältesten Einträge der Eingabetabellen A und B keine Duplikate voneinander sind, entfernt die Tabellenaufbauprozedur den ältesten Eintrag der Eingabetabellen A und B.
Die Tabellenaufbauprozedur aktualisiert die Arrays A und B, Block 288, auf folgende Weise. Sofern der entfernte Tabelleneintrag der älteste Eintrag der Eingabetabelle A ist, aktualisiert die Tabellenaufbauprozedur das Array A derart, daß es einen Querverweis zwischen dem aus der Eingabetabelle A entfernten Tabelleneintrag und dem nächsten Tabelleneintrag der Ausgabetabelle gibt. Sofern der entfernte Tabelleneintrag der älteste Eintrag der Eingabetabelle B ist, aktualisiert die Tabellenaufbauprozedur das Array B derart, daß es einen Querverweis zwischen dem aus der Eingabetabelle B entfernten Tabelleneintrag und dem nächsten Tabelleneintrag der Ausgabetabelle aufweist.
Die Tabellenaufbauprozedur modifiziert bedingungsabhängig den entfernten Tabelleneintrag, Block 290, auf folgende Weise. Der entfernte Tabelleneintrag wird modifiziert, wenn er kein Duplikat des Tabelleneintrags ist, der aus der Eingabetabelle B entfernt wurde, anderenfalls wird er verworfen. Für einen entfernten Tabelleneintrag, der modifiziert werden soll, bestimmt die Tabellenaufbauprozedur zunächst, ob ein neuer Zweig erforderlich ist. Ein neuer Zweig ist erforderlich, wenn der entfernte Tabelleneintrag aus der Eingabetabelle B entfernt wurde, der entfernte Tabelleneintrag kein Duplikat irgendeines Tabelleneintrags in der Eingabetabelle A ist und der Vorgängertabelleneintrag des entfernten Tabelleneintrags keinen Querverweis zu einem Tabelleneintrag in der Ausgabetabelle enthält, welcher wiederum einen Querverweis zu einem Tabelleneintrag in der Eingabetabelle A enthält, wobei darüber hinaus der Tabelleneintrag in der Eingabetabelle A, auf den querverwiesen wird, ein Vorgängertabelleneintrag eines weiteren Tabelleneintrags der Eingabetabelle A ist, welcher sich auf dem gleichen Zweig wie der entfernte Tabelleneintrag befindet.
Dann ruft die Tabellenaufbauprozedur die Ebenen-ID-Zuweisungsprozedur auf, um einen neuen Änderungsidentifizierer für das Delta auf der Grundlage des Ergebnisses der Bestimmung des neuen Zweiges zu erzeugen. Die Tabellenaufbauprozedur ersetzt den Änderungsidentifizierer in dem entfernten Tabelleneintrag durch den erzeugten Änderungsidentifizierer. Darüber hinaus ersetzt die Tabellenaufbauprozedur die Deltaseriennummer des dem entfernten Tabelleneintrag entsprechenden Deltas durch eine neue Deltaseriennummer. Die neue Deltaseriennummer wird gleich der um 1 erhöhten Anzahl der Tabelleneinträge gesetzt, die bis dahin in die Ausgabetabelle ausgegeben wurden. Die Tabellenaufbauprozedur ersetzt ferner die Vorgängerdeltaseriennummer des dem entfernten Tabelleneintrag entsprechenden Deltas durch eine neue Vorgängerdeltaseriennummer, die aus einem der beiden Arrays gewonnen wird. Die gewonnene Vorgängerdelta seriennummer ist gleich der Deltaseriennummer in der Ausgabetabelle, auf die durch eine Deltaseriennummer in ihrer Eingabetabelle querverwiesen wird, die gleich der Deltaseriennummer des Vorgängers ist.
Die Listenaufbauprozedur entfernt bedingungsabhängig das zugehörige Delta, Block 290, auf folgende Weise. Das zugehörige Delta wird modifiziert, wenn es kein Duplikatdelta ist, das aus der Arbeitsliste B entfernt wurde, anderenfalls wird es verworfen. Wenn das zugehörige Delta nicht verworfen wird, ersetzt die Listenaufbauprozedur die Deltaseriennummer durch eine neue Deltaseriennummer, die aus den Arrays A oder B gewonnen wird. Die gewonnene neue Deltaseriennummer ist gleich der Deltaseriennummer in der Ausgabetabelle, auf die querverwiesen wird.
Schließlich geben nach dem Modifizieren des entfernten Tabelleneintrags und des zugehörigen Deltas in der oben beschriebenen Weise die Tabellenaufbau- und Listenaufbauprozeduren den modifizierten Tabelleneintrag und das modifizierte Delta aus, Block 292, wobei dieser an das Ende der Ausgabetabelle bzw. an das Ende der Ausgabenliste angehängt werden.
Es wird jetzt auf Fig. 8 Bezug genommen, in der eine Blockdarstellung gezeigt ist, die die Anwendung der vorliegenden Erfindung auf ein Beispielszenarium veranschaulicht. Es sei angenommen, daß eine erste und eine zweite Kindumgebung (C1 und C2), 324 und 326, jeweils eine Revision 1.1 eines Quellmoduls, 302c und 302d, aus ihrer Großelternumgebung (GP) 320 über ihre Elternumgebung (P) 322 erlangt haben. C1 erzeugt Editionen 1.2, 1.3 und 1.4, welche als drei inkrementale Deltas (d. h. Änderungen) 304a, 306a und 308a in ihrer Umgebung 324 gehalten werden. In ähnlicher Weise erzeugt C2 Editionen 1.2, 1.3, welche ebenfalls als zwei inkrementale Deltas 310a und 312a in ihrer Umgebung 326 gehalten werden.
Wenn C1 die letzte Revision 1.1 in P mit seiner letzten Edition 1.4 unter Verwendung der vorliegenden Erfindung in Einklang bringt, werden drei Revisionen, 1.2, 1.3 und 1.4, die als drei separate inkrementale Deltas 304b, 306b und 308b gehalten werden, für die Deltastruktur 309a in P erzeugt. Im Unterschied zum Stand der Technik gehen die Details der Deltastruktur 304a, 306a und 308a (d. h. die Vorgeschichte, die die in C1 ausgeführten Änderungen beschreibt) nicht verloren. Wenn jetzt. C2 versucht, die letzte Revision 1.4 in P mit seiner letzten Revision 1.3 unter Verwendung der vorliegenden Erfindung in Einklang zu bringen, wird seine letzte Edition 1.3 automatisch mit der letzten Revision 1.4 in P resynchronisiert, was zu drei neuen Editionen 1.2, 1.3 und 1.4 führt, die als drei inkrementale Deltas 304c, 306c und 308c gehalten werden, und zu zwei umnumerierten Editionen 1.1.1 und 1.1.2, die als Zweigdeltas 310a und 312a in ihrer Umgebung 326 gehalten werden. C2 löst die Differenz auf, wobei sie eine neue Edition 1.5 erzeugt, die als inkrementales Delta 314a in ihrer Umgebung 326 gehalten wird. Wenn C2 die letzte Revision 1.4 in P mit ihrer letzten Edition 1.5 unter Verwendung der vorliegenden Erfindung wieder in Einklang bringt, werden drei weitere Revisionen I.1.I., 1.1.2 und 1.5, die als zwei separate Zweigdeltas 310b, 312b und ein inkrementales Delta 314b gehalten werden, für die Gesamtdeltastruktur 315a in P erzeugt. Im Unterschied zum Stand der Technik gehen die zusätzlichen Details der Deltastruktur 310a und 312a (d. h. die Vorgeschichte, die die in C2 ausgeführten Änderungen beschreibt) nicht verloren.
In ähnlicher Weise werden dann, wenn die letzte Revision 1.1 in GP mit der letzten Edition 1.5 in P wieder in Einklang gebracht wird, sechs neue Editionen 1.2, 1.3, 1.4, 1.5, 1.1.1 und 1.1.2, die als vier separate inkrementale Deltas 304d, 306d, 308d und 314c und zwei Zweigdeltas 310c und 312c gehalten werden, für die Deltastruktur 315b in GP erzeugt. Wenn somit eine Onkelumgebung (U) 328 nachfolgend die letzte Revision 1.5 in GP erwirbt, sieht sie sämtliche der Änderungen, die als separate inkrementale oder Zweig deltas 315d gehalten werden, in U. Sie hat Zugriff auf die gesamte Änderungsvorgeschichte, die die in C1 und C2 ausgeführten Änderungen beschreibt.
Während die Erfindung im wesentlichen anhand eines bevorzugten Ausführungsbeispiels im Kontext der Kontrolle von Änderungen an einem Quellmodul bei der Softwareentwicklung beschrieben wurde, werden Fachleute erkennen, daß die Erfindung nicht auf den hier beschriebenen Kontext oder die beschriebenen Ausführungsbeispiele beschränkt ist. Insbesondere kann die vorliegende Erfindung auf eine beliebige Anzahl von Quellmodulen und auf zueinander in Beziehung stehende Softwareumgebungen anderer Topologien angewendet werden. Die vorliegende Erfindung kann auf eine Dokument- oder Objektänderungskontrolle angewendet werden, vorausgesetzt, daß die Änderungen an einem Dokument oder an einem Objekt in Deltastrukturen gehalten und bearbeitet werden können, wie bei dem hier beschriebenen Quellmodul. Das Verfahren, die Einrichtungen und das System gemäß der vorliegenden Erfindung können mit Modifikationen und Änderungen innerhalb des Umfangs der anhängigen Ansprüche ausgeführt werden.

Claims

1. In einem Computersystem mit einer Eltern- und einer Kind- Entwicklungsumgebung,

wobei die Eltern- und die Kind-Entwicklungsumgebung eine erste und eine zweite Delta-Hierarchie aufweisen, die ein Quellmodul bzw. der Eltern- bzw. der Kind-Umgebung im einzelnen bekannte Änderungen an dem Quellmodul repräsentieren, ein Verfahren zum Verschmelzen der ersten und zweiten Delta- Hierarchien miteinander, wobei das Verfahren sämtliche Delta-Beziehungen der der Eltern- bzw. der Kind-Umgebung im einzelnen bekannten Änderungen ohne das Erfordernis einer computerunterstützten Verfolgung bewahrt, wobei das Verfahren gekennzeichnet ist durch die Schritte:

(a) Speichern der Deltas in einer ersten und einer zweiten Liste von Deltas und Speichern von den Deltas entsprechenden deskriptiven Einträgen in einer ersten und zweiten Tabelle von deskriptiven Einträgen der ersten und zweiten Delta-Hierarchien (252);

(b) Initialisieren einer ersten und einer zweiten Arbeitsliste und einer ersten und einer zweiten Arbeitstabelle derart, daß sie der ersten und zweiten Liste von Deltas und der ersten und der zweiten Tabelle deskriptiver Einträge der ersten bzw. zweiten Delta-Hierarchien gleichen, wobei die erste und zweite Liste von Deltas in einer ersten und zweiten Entwicklungsumgebung in identischer Weise chronologisch identifiziert sind, und wobei die erste und zweite Tabelle deskriptiver Einträge zeitlich geordnet sind und die erste bzw. zweite Liste von Deltas entsprechend beschreiben (280);

(c) Initalisieren einer Ausgabetabelle, einer Ausgabeliste (282), eines ersten und eines zweiten der ersten bzw. zweiten Arbeitstabelle entsprechenden Zwei-Wege- Assoziativ-Arrays derart, daß sie leer sind, zum sequentiellen Empfangen modifizierter nicht-duplizierter deskriptiver Einträge der ersten und zweiten Arbeitstabelle, modifizierter nicht-duplizierter Deltas der ersten und zweiten Liste von Deltas, und wobei das Zwei- Wege-Assoziativ-Array Querverweis-Einträge speichert, die Querverweise zwischen den deskriptiven Einträgen der ersten und zweiten Arbeitstabelle und der Ausgabetabelle darstellen (284);

(d) Wiedergewinnen von deskriptiven Einträgen und ihrer zugehörigen Deltas aus der ersten und der zweiten Arbeitstabelle und der ersten und der zweiten Arbeitsliste, Ausgeben eines Zwei-Wege-Querverweis-Eintrags zu dem zugehörigen Array des ersten und des zweiten Zwei- Wege-Assoziativ-Arrays für jeden wiedergewonnenen deskriptiven Eintrag, sobald der deskriptive Eintrag und sein zugehöriges Delta wiedergewonnen sind, Herstellen eines Querverweises des wiedergewonnenen deskriptiven Eintrags auf den nächsten deskriptiven Eintrag der Ausgabetabelle, wobei der Schritt des Wiedergewinnens jeweils an einem deskriptiven Eintrag und seinem zugehörigen Delta auf eine vorgegebene Ältester-Eintrag-Weise durchgeführt wird, bis sämtliche deskriptiven Einträge und ihre zugehörigen Deltas aus der ersten und zweiten Arbeitstabelle und den ersten und zweiten Arbeits-Deltas wiedergewonnen sind (288);

(e) Verwerfen jedes wiedergewonnenen deskriptiven Eintrags und seines zugehörigen Deltas, sobald sein Zwei- Wege-Querverweis-Eintrag ausgegeben worden ist, sofern der wiedergewonnene deskriptive Eintrag ein Duplikat eines zweiten deskriptiven Eintrags ist, welcher aus der anderen Arbeitstabelle wiedergewonnen worden ist (290);

(f) bedingtes Modifizieren jedes wiedergewonnenen deskriptiven Eintrags und seines zugehörigen Deltas, sofern sie nicht verworfen wurden, nachdem die Entscheidung über das Verwerfen getroffen wurde, Ausgeben jedes der wiedergewonnenen und modifizierten deskriptiven Einträge und seines zugehörigen modifizierten Deltas in die Ausgabetabelle bzw. die Ausgabeliste, sobald die Modifikationen durchgeführt sind, wobei der Schritt des Modifizierens in Abhängigkeit davon durchgeführt wird, ob ein neuer Zweig in der verschmolzenen Hierarchie für das zugehörige Delta des wiedergewonnenen und nicht verworfenen dekriptiven Eintrags erzeugt werden soll, und in Abhängigkeit von der Anzahl der wiedergewonnenen deskriptiven Einträge, die bis dahin zu der Ausgabetabelle ausgegeben wurden, und darüber hinaus unter Verwendung der Querverweis-Einträge (290).

2. Das Verfahren nach Anspruch 1, wobei der Schritt (d) die Schritte umfaßt:

(d.1) Wiedergewinnen des ältesten deskriptiven Eintrags der zweiten Arbeitstabelle und seines zugehörigen Deltas aus der zweiten Arbeitstabelle und der zweiten Arbeitsliste, sofern die erste Arbeitstabelle leer ist;

(d.2) Wiedergewinnen des ältesten deskriptiven Eintrags der ersten Arbeitstabelle und seines zugehörigen Deltas aus der ersten Arbeitstabelle und der ersten Arbeitsliste, sofern die zweite Arbeitstabelle leer ist;

(d.3) Wiedergewinnen des ältesten deskriptiven Eintrags der zweiten Arbeitstabelle und seines zugehörigen Deltas aus der zweiten Arbeitstabelle und der zweiten Arbeitsliste, wenn sowohl die erste als auch die zweite Arbeitstabelle nicht leer sind und die ältesten des kriptiven Einträge der ersten und der zweiten Arbeitstabelle Duplikate sind; und

(d.4) Wiedergewinnen des ältesten deskriptiven Eintrags der ersten oder der zweiten Arbeitstabelle und des zugehörigen Deltas aus der ersten Arbeitstabelle und der ersten Arbeitsliste, wenn sowohl die erste als auch die zweite Arbeitstabelle nicht leer sind und die ältesten deskriptiven Einträge der ersten und der zweiten Arbeitstabelle keine Duplikate sind.

3. Das Verfahren nach Anspruch 2, wobei der Schritt (f) ferner den Schritt des Erzeugens eines neuen Zweiges für das zugehörige Delta des entfernten und nicht im Schritt (e) verworfenen deskriptiven Eintrags umfaßt, sofern der wiedergewonnene und nicht verworfene deskriptive Eintrag aus der zweiten Arbeitstabelle wiedergewonnen wurde, und sofern der wiedergewonnene und nicht verworfene deskriptive Eintrag einen deskriptiven Vorgänger-Eintrag in der zweiten Arbeitstabelle aufweist, der auf einen deskriptiven Eintrag in der Ausgabetabelle querverweist, welcher wiederum auf einen deskriptiven Eintrag in der ersten Arbeitstabelle querverweist, und sofern der querverwiesene deskriptive Eintrag in der ersten Arbeitstabelle ein deskriptiver Vorgänger-Eintrag für einen weiteren deskriptiven Eintrag in der ersten Arbeitstabelle ist, welcher sich auf dem gleichen Zweig wie der entfernte und nicht verworfene deskriptive Eintrag befindet.

4. Das Verfähren nach Anspruch 3, wobei der Schritt (f) die Schritte umfaßt:

((f).1) Ersetzen eines vorhandenen Änderungs-Identifizierers in dem nicht verworfenen deskriptiven Eintrag durch einen neuen Änderungs-Identifizierer, wobei der vorhandene und der neue Änderungs-Identifizierer Revisions-/Editions-Stufen des Quellmoduls in der vor-ver schmolzenen bzw. verschmolzenen Hierarchie anzeigen, wobei der neue Änderungs-Identifizierer in Abhängigkeit davon erzeugt wird, ob ein neuer Zweig für das zugehörige Delta des deskriptiven Eintrags in der verschmolzenen Hierarchie erzeugt werden soll;

((f).2) Ersetzen einer ersten vorhandenen Delta-Seriennummer in dem nicht verworfenen deskriptiven Eintrag durch eine erste neue einzigartige Delta-Seriennummer, wobei die erste vorhandene und die erste neue Delta-Seriennummer das zugehörige Delta in der vor-verschmolzenen bzw. der verschmolzenen Hierarchie identifizieren, wobei die erste neue einzigartige Delta-Seriennummer in Abhängigkeit von der Anzahl der deskriptiven Einträge, die bis dahin an die Ausgabetabelle ausgegeben worden sind, erzeugt wird;

((f).3) Ersetzen einer zweiten vorhandenen Delta-Seriennummer in dem nicht verworfenen deskriptiven Eintrag durch eine zweite neue einzigartige Delta-Seriennummer, wobei die zweite vorhandene und die zweite neue Delta- Seriennummer das zugehörige Vorgänger-Delta des Deltas in der vor-verschmolzenen bzw. der verschmolzenen Hierarchie identifizieren, wobei die zweite einzigartige Delta-Seriennummer aus dem jeweils zugehörigen Array des ersten und des zweiten Zwei-Wege-Querverweis-Arrays wiedergewonnen worden ist, wobei die zweite neue einzigartige Delta-Seriennummer gleich der ersten neuen einzigartigen Delta-Nummer des durch Querverweis angezeigten deskriptiven Eintrags der Ausgabetabelle ist, dessen erste vorhandene Delta-Seriennummer des querverweisenden deskriptiven Eintrags der ersten und zweiten Arbeitstabelle gleich der zweiten vorhandenen Delta-Seriennummer ist.

5. Das Verfahren nach Anspruch 4, ferner umfassend die Schritte:

Verschmelzen der zweiten Delta-Hierarchie mit der ersten Delta-Hierarchie, um die letzte Revision des Quellmoduls in der Eltern-Umgebung mit der letzten Edition des Quellmoduls in der Kind-Umgebung in Einklang zu bringen (292); und

Ersetzen der ersten Delta-Hierarchie in der Eltern-Umgebung durch die Ausgabetabelle (296).

6. Das Verfahren nach Anspruch 5, ferner umfassend die Schritte:

Verschmelzen der ersten Delta-Hierarchie mit der zweiten Delta-Hierarchie, um die letzte Edition des Quellmoduls in der Kind-Umgebung mit der letzten Revision des Quellmoduls in der Eltern-Umgebung zu resynchronisieren (292); und

Ersetzen der zweiten Delta-Hierarchie in der Kind-Umgebung durch die Ausgabetabelle (296).

7. Das Verfahren nach Anspruch 6, ferner umfassend den Schritt des automatischen Auslösens der Durchführung der Schritte (a) bis (f) zum Verschmelzen der ersten Delta-Hierarchie mit der zweiten Delta-Hierarchie zum Resynchronisieren der letzten Edition des Quellmoduls in der Kind-Umgebung mit der letzten Revision des Quellmoduls in der Eltern-Umgebung in Erwiderung eines Versuchs zum Durchführen der Schritte (a) bis (f) zum Verschmelzen der zweiten Delta- Hierarchie mit der ersten Delta-Hierarchie, um die letzte Revision des Quellmoduls in der Eltern-Umgebung mit der letzten Edition des Quellmoduls in der Kind-Umgebung in Einklang zu bringen, wobei die zweite Delta-Hierarchie ursprünglich unter Verwendung der ersten Delta-Hierarchie, welche sich nachfolgend geändert hat, erzeugt wurde.

8. In einem Computersystem mit einer Eltern- und einer Kind- Entwicklungsumgebung, wobei die Eltern- und Kind-Entwicklungsumgebung eine erste und eine zweite Delta-Hierarchie aufweisen, die ein Quellmodul und der Eltern- bzw. der Kind- Umgebung im einzelnen bekannte Änderungen an dem Quellmodul repräsentieren, eine Einrichtung zum Verschmelzen der ersten und der zweiten Delta-Hierarchie miteinander, die sämtliche Delta-Beziehungen der der Eltern- und der Kind-Umgebung im einzelnen bekannten Änderungen ohne das Erfordernis einer computerunterstützten Verfolgung bewahrt, wobei die Einrichtung gekennzeichnet ist durch:

(a) Speichermittel (170, 171) zum Speichern von Deltas in einer ersten und einer zweiten Liste von Deltas und zum Speichern von den Deltas entsprechenden deskriptiven Einträgen in einer ersten und einer zweiten Tabelle von deskriptiven Einträgen der ersten und zweiten Delta-Hierarchie;

(b) mit der Eltern- und der Kind-Umgebung gekoppelte erste Initialisierungsmittel (184) zum Initialisieren einer ersten und einer zweiten Arbeitsliste und einer ersten und einer zweiten Arbeitstabelle derart, daß sie gleich einer ersten und einer zweiten Liste von Deltas bzw. einer ersten und einer zweiten Tabelle von deskriptiven Einträgen der ersten und zweiten Delta-Hierarchien sind, wobei die erste und zweite Liste von Deltas in einer ersten und einer zweiten Entwickungsumgebung in identischer Weise chronologisch identifiziert sind, und wobei die erste und die zweite Tabelle deskriptiver Einträge zeitlich geordnet sind und entsprechend die erste bzw. die zweite Liste von Deltas beschreiben;

(c) zweite Initialisierungsmittel (185) zum Initialisieren einer Ausgabetabelle, einer Ausgabeliste, eines ersten und eines zweiten der ersten und zweiten Arbeitstabelle entsprechenden Zwei-Wege-Assoziativ-Arrays derart, daß sie leer sind, zum sequentiellen Empfangen modifizierter nicht-duplizierter deskriptiver Einträge der ersten und der zweiten Arbeitstabelle, modifizierter nicht-duplizierter Deltas der ersten und der zweiten Liste von Deltas, und wobei das Zwei-Wege-Assoziativ-Array Querverweis-Einträge speichert, die Querverweise zwischen den deskriptiven Einträgen der ersten und der zweiten Arbeitstabelle und der Ausgabetabelle darstellen;

(d) mit den ersten Initialisierungsmitteln gekoppelte Wiedergewinnungsmittel (184) zum Wiedergewinnen deskriptiver Einträge und ihrer zugehörigen Deltas aus der ersten und der zweiten Arbeitstabelle und der ersten und der zweiten Arbeitsliste und mit den Entfernungsmitteln und den zweiten Initialisierungsmitteln gekoppelte erste Ausgabemittel zum Ausgeben eines Zwei-Wege- Querverweis-Eintrags auf das zugehörige Array des ersten und des zweiten Zwei-Wege-Assoziativ-Arrays für jeden wiedergewonnenen deskriptiven Eintrag, wenn der deskriptive Eintrag und sein zugehöriges Delta wiedergewonnen werden, wobei der deskriptive Eintrag, welcher wiedergewonnen worden ist, auf den nächsten deskriptiven Eintrag der Ausgabetabelle querverweist, wobei der Schritt des Wiedergewinnens jeweils an einem deskriptiven Eintrag und seinem zugehörigen Delta auf eine vorgegebene Ältester-Eintrag-Weise durchgeführt wird, bis sämtliche deskriptiven Einträge und ihre zugehörigen Deltas aus der ersten und der zweiten Arbeitstabelle und den ersten und den zweiten Arbeits-Deltas wiedergewonnen worden sind;

(e) mit den ersten Ausgabemitteln gekoppelte Verwerfungsmittel (185) zum Verwerfen jedes wiedergewonnenen deskriptiven Eintrags und seines zugehörigen Deltas, wenn ein Zwei-Wege-Querverweis-Eintrag ausgegeben ist, sofern der wiedergewonnene deskriptive Eintrag ein Duplikat eines zweiten wiedergewonnenen deskriptiven Eintrags in der anderen Arbeitstabelle ist;

(f) mit den Verwerfungsmitteln gekoppelte Modizifierungsmittel (185) zum bedingten Modifizieren jedes wiedergewonnenen deskriptiven Eintrags und seines zugehörigen Deltas, die nicht verworfen wurden, nachdem die Entscheidung über das Verwerfen getroffen worden ist, zum Ausgeben jedes der wiedergewonnenen und modifizierten deskriptiven Einträge und seines zugehörigen modifizierten Deltas in die Ausgabetabelle bzw. die Ausgabeliste, wenn die Modifikationen durchgeführt sind, wobei der Schritt des Modifizierens in Abhängigkeit davon durchgeführt wird, ob ein neuer Zweig in der verschmolzenen Hierarchie für das zugehörige Delta des wiedergewonnenen und nicht verworfenen deskriptiven Eintrags erzeugt werden soll, und in Abhängigkeit von der Anzahl von wiedergewonnenen deskriptiven Einträgen, die bis dahin zu der Ausgabetabelle ausgegeben worden sind, und darüber hinaus unter Verwendung der Querverweis-Einträge.

9. Die Einrichtung nach Anspruch 8, wobei die Wiedergewinnungsmittel (184) wiedergewinnen:

(d.1) den ältesten deskriptiven Eintrag der zweiten Arbeitstabelle und sein zugehöriges Delta aus der zweiten Arbeitstabelle und der zweiten Arbeitsliste, wenn die erste Arbeitstabelle leer ist;

(d.2) den ältesten deskriptiven Eintrag der ersten Arbeitstabelle und sein zugehöriges Delta aus der ersten Arbeitstabelle und der ersten Arbeitsliste, wenn die zweite Arbeitstabelle leer ist;

(d.3) den ältesten deskriptiven Eintrag der zweiten Arbeitstabelle und sein zugehöriges Delta aus der zweiten Arbeitstabelle und der zweiten Arbeitsliste, wenn sowohl die erste als auch die zweite Arbeitstabelle nicht leer sind und die ältesten deskriptiven Einträge der ersten und der zweiten Arbeitstabelle Duplikate sind; und

(d.4) des ältesten deskriptiven Eintrags der ersten oder der zweiten Arbeitstabelle und sein zugehöriges Delta aus der ersten Arbeitstabelle und der ersten Arbeitsliste, wenn sowohl die erste als auch die zweite Arbeitstabelle nicht leer sind und die ältesten deskriptiven Einträge der ersten und zweiten Arbeitstabelle keine Duplikate sind.

10. Die Einrichtung nach Anspruch 9, wobei die Modifikationsmittel (185) ferner Mittel aufweisen zum Bestimmen, daß ein neuer Zweig erzeugt werden soll für das zugehörige Delta des deskriptiven Eintrags, welcher wiedergewonnen und nicht verworfen worden ist, sofern der wiedergewonnene und nicht verworfene deskriptive Eintrag aus der zweiten Arbeitstabelle entfernt wurde, und sofern der wiedergewonnene und nicht verworfene deskriptive Eintrag einen deskriptiven Vorgänger- Eintrag in der zweiten Arbeitstabelle aufweist, der auf einen deskriptiven Eintrag in der Ausgabetabelle querverweist, welcher wiederum auf einen deskriptiven Eintrag in der ersten Arbeitstabelle querverweist, wobei darüber hinaus der querverwiesene deskriptive Eintrag in der ersten Arbeitstabelle ein deskriptiver Vorgänger-Eintrag für einen weiteren deskriptiven Eintrag in der ersten Arbeitstabelle ist, wel cher sich auf dem gleichen Zweig wie der nicht verworfene deskriptive Eintrag befindet.

11. Die Einrichtung nach Anspruch 10, wobei die Modifikationsmittel (185) ersetzen:

(h.1) einen vorhandenen Änderungsidentifizierer in dem nicht verworfenen deskriptiven Eintrag durch einen neuen Änderungsidentifizierer, wobei der vorhandene und der neue Änderungsidentifizierer Revisions/Editions- Stufen des Quellmoduls in der vor-verschmolzenen bzw. der verschmolzenen Hierarchie anzeigen, wobei der neue Änderungsidentifizierer in Abhängigkeit davon erzeugt wird, ob ein neuer Zweig für das zugehörige Delta des nicht verworfenen deskriptiven Eintrags in der verschmolzenen Hierarchie erzeugt werden soll;

(h.2) eine erste vorhandene Delta-Seriennummer in dem deskriptiven Eintrag durch eine erste neue einzigartige Delta-Seriennummer, wobei die erste vorhandene und die neue Delta-Seriennummer die zugehörigen Deltas in der vor-verschmolzenen bzw. der verschmolzenen Hierarchie identifizieren, wobei die erste einzigartige Delta-Seriennummer in Abhängigkeit von der Anzahl der deskriptiven Einträge erzeugt wird, die bis dahin an die Ausgabetabelle ausgegeben worden sind;

(h.3) eine zweite vorhandene Delta-Seriennummer in dem deskriptiven Eintrag durch eine zweite neue einzigartige Delta-Seriennummer, wobei die zweite vorhandene und die neue Delta-Seriennummer die zugehörigen Vorgänger-Deltas des Deltas in der vor-verschmolzenen bzw. der verschmolzenen Hierarchie identifizieren, wobei die zweite neue einzigartige Delta-Seriennummer aus dem zugehörigen Array des ersten und des zweiten Zwei-Wege- Querverweis-Arräys wiedergewonnen werden, wobei die zweite neue einzigartige Delta-Seriennummer gleich der ersten neuen einzigartigen Delta-Seriennummer des durch Querverweis angezeigten deskriptiven Eintrags der Ausgabetabelle ist, dessen, erste vorhandene Delta-Seriennummer des querverweisenden deskriptiven Eintrags der ersten und der zweiten Arbeitstabelle gleich der zweiten vorhandenen Delta-Seriennummer ist.

12. Die Einrichtung nach Anspruch 11, ferner aufweisend:

Verschmelzungsmittel (183) zum Verschmelzen der zweiten Delta-Hierarchie in die erste Delta-Hierarchie, um die letzte Revision des Quellmoduls in der Eltern-Umgebung mit der letzten Edition des Quellmoduls in der Kind-Umgebung in Einklang zu bringen; und

mit der Eltern-Umgebung und den zweiten Ausgabemitteln gekoppelte Ersetzungsmittel (185) zum Ersetze oder ersten Delta-Hierarchie in der Eltern-Umgebung durch die Ausgabetabelle.

13. Die Einrichtung nach Anspruch 12, ferner aufweisend:

Verschmelzungsmittel (183) zum Verschmelzen der ersten Delta-Hierarchie in die zweite Delta-Hierarchie zum Resynchronisieren der letzten Edition des Quellmoduls in der Kind-Umgebung mit der letzten Revision des Quellmoduls in der Eltern-Umgebung, und

wobei die ferner mit der Kind-Umgebung gekoppelten Ersetzungsmittel (185) die zweite Hierarchie in der Kind-Umgebung durch die Ausgabetabelle ersetzen, wobei die Verwendung der Einrichtung zum Verschmelzen der ersten Delta-Hierarchie in die zweite Delta-Hierarchie zum Resynchronisieren der letzten Edition des Quellmoduls in der Kind-Umgebung mit der letzten Revision des Quellmoduls in der Eltern-Umgebung automatisch ausgelöst wird in Erwiderung eines Versuchs zum Benutzen der Einrichtung zum Verschmelzen der zweiten Delta- Hierarchie in die erste Delta-Hierarchie, um die letzte Revision des Quellmoduls in der Eltern-Umgebung mit der letz ten Edition des Quell-Moduls in der Kind-Umgebung iri Einklang zubringen, wobei die zweite Delta-Hierarchie ursprünglich unter Verwendung der ersten Delta-Hierarchie, welche nachfolgend geändert worden ist, erzeugt wurde.

14. Ein Computersystem, gekennzeichnet durch:

(a) eine Eltern-Entwicklungsumgebung mit einem ersten Ausführungsmittel (143a) zum Ausführen von Mitteln und mit einer ersten Delta-Hierarchie, die ein Quellmodul und der Eltern-Umgebung bekannte Änderungen des Quellmoduls repräsentiert;

(b) eine Kind-Entwicklungsumgebung mit einem zweiten Ausführungsmittel (143b) zum Ausführen von Mitteln und mit einer zweiten Delta-Hierarchie, die das Quellmodul und der Kind-Umgebung bekannte Änderungen an dem Quellmodul repräsentiert;

(c) durch entweder das erste oder das zweite Ausführungsmittel auszuführende Verschmelzungsmittel (183) zum Verschmelzen der ersten und der zweiten Delta-Hierarchie miteinander derart, daß sämtliche Delta-Beziehungen der Änderungen, die der Eltern- und der Kind-Umgebung einzeln bekannt sind, bewahrt werden, wobei die Verschmelzungsmittel enthalten:

(c.1) durch entweder das erste oder das zweite Ausführungsmittel auszuführende erste Initialisierungsmittel (184) zum Initialisieren einer ersten und einer zweiten Arbeitsliste und einer ersten und einer zweiten Arbeitstabelle derart, daß sie gleich einer ersten und einer zweiten Liste von Deltas bzw. einer ersten und einer zweiten Tabelle von deskriptiven Einträgen der ersten und zweiten Delta-Hierarchien sind, wobei die erste und die zweite Liste von Deltas chronologisch innerhalb einer ersten und einer zweiten Entwicklungsumgebung in identischer Weise identifiziert sind, und wobei die erste und die zweite Tabelle von deskriptiven Einträgen zeitlich geordnet sind und entsprechend die erste bzw. zweite Liste von Deltas beschreiben;

(c.2) durch entweder das erste oder das zweite Ausführungsmittel auszuführende zweite Initialisierungsmittel (185) zum Initialisieren einer Ausgabetabelle, einer Ausgabeliste und eines ersten und eines zweiten der ersten und zweiten Arbeitstabelle entsprechenden Zwei-Wege-Assoziativ-Arrays derart, daß sie leer sind, zum sequentiellen Empfangen modifizierter nicht-duplizierter deskriptiver Einträge der ersten und zweiten Arbeitstabelle, modifizierter nicht-duplizierter Deltas der ersten und zweiten Liste von Deltas und wobei das Zwei-Wege- Assoziativ-Array Querverweis-Einträge speichert, die Querverweise zwischen den deskriptiven Einträgen der ersten und der zweiten Arbeitstabelle und der Ausgabetabelle darstellen;

(c.3) durch entweder das erste oder das zweite Ausführungsmittel auszuführende Wiedergewinnungsmittel (184) zum Wiedergewinnen deskriptiver Einträge und ihrer zugehörigen Deltas aus der ersten und der zweiten Arbeitstabelle und der ersten und der zweiten Arbeitsliste, und zum Ausgeben eines Zwei-Wege-Querverweis-Eintrags an das zugehörige Array des ersten und zweiten Zwei-Wege-Assoziativ- Arrays für jeden wiedergewonnenen deskriptiven Eintrag, wenn der deskriptive Eintrag und sein zugehöriges Delta wiedergewonnen sind, und zum Herstellen eines Querverweises des deskriptiven Eintrags, welcher wiedergewonnen worden ist, auf den nächsten deskriptiven Eintrag der Ausgabetabelle, wobei der Schritt des Wiedergewinnens an jeweils einem deskriptiven Eintrag und seinem zugehörigen Delta auf eine vorgegebene Ältester-Eintrag-Weise durchgeführt wird, bis sämtliche deskriptiven Einträge und ihre zugehörigen Deltas aus der ersten und der zweiten Arbeitstabelle und den ersten und den zweiten Arbeitsdeltas wiedergewonnen worden sind;

(c.4) von entweder den ersten oder den zweiten Ausführungsmitteln auszuführende Verwerfungsmittel (185) zum Verwerfen jedes wiedergewonnenen deskriptiven Eintrags und seines zugehörigen Deltas, sobald sein Zwei-Wege-Querverweis-Eintrag ausgegeben ist, sofern der wiedergewonnene deskriptive Eintrag ein Duplikat eines zweiten wiedergewonnenen deskriptiven Eintrags in der anderen Arbeitstabelle ist;

(c.5) durch entweder das erste oder das zweite Ausführungsmittel auszuführende Modifikationsmittel (185) zum bedingten Modifizieren jedes nichtverworfenen wiedergewonnenen deskriptiven Eintrags und seines zugehörigen Deltas, nachdem die Entscheidung über das Verwerfen getroffen worden ist, und zum Ausgeben jedes wiedergewonnenen und modifizierten deskriptiven Eintrags und seines zugehörigen modifizierten Deltas in die Ausgabetabelle bzw. die Ausgabeliste, sobald die Modifikationen vorgenommen sind, wobei der Schritt des Modifizierens in Abhängigkeit davon durchgeführt wird, ob ein neuer Zweig in der verschmolzenen Hierarchie für das zugehörige Delta des wiedergewonnenen und nicht verworfenen deskriptiven Eintrags erzeugt werden soll, und in Abhängigkeit von der Anzahl der wiedergewonnenen deskriptiven Einträge, welche bis dahin zu der Aus gabetabelle ausgegeben worden sind, und darüberhinaus unter Verwendung der Querverweis-Einträge, und

ein mit dem Speicher gekoppelter Prozessor, wobei der Prozessor dem Abarbeiten der Verschmelzungsmittel (183) dient.

15. Das Computersystem nach Anspruch 14, wobei die Wiedergewinnungsmittel (184) wiedergewinnen:

(c.3.1) den ältesten deskriptiven Eintrag der zweiten Arbeitstabelle und sein zugehöriges Delta aus der zweiten Arbeitstabelle und der zweiten Arbeitsliste, sofern die erste Arbeitstabelle leer ist;

(c.3.2) den ältesten deskriptiven Eintrag der ersten Arbeitstabelle und sein zugehöriges Delta aus der ersten Arbeitstabelle und der ersten Arbeitsliste, sofern die zweite Arbeitstabelle leer ist;

(c. 3.3) den ältesten deskriptiven Eintrag der zweiten Arbeitstabelle und sein zugehöriges Delta aus der zweiten Arbeitstabelle und der zweiten Arbeitsliste, wenn sowohl die erste als auch die zweite Arbeitstabelle nicht leer sind und die ältesten deskriptiven Einträge der ersten und der zweiten Arbeitstabelle Duplikate sind; und

(c.3.4) den ältesten deskriptiven Eintrag der ersten oder der zweiten Arbeitstabelle und sein zugehöriges Delta aus der ersten Arbeitstabelle und der ersten Arbeitsliste, wenn sowohl die erste als auch die zweite Arbeitstabelle nicht leer sind und die ältesten deskriptiven Einträge der ersten und der zweiten Arbeitstabelle keine Duplikate sind.

16. Das Computersystem nach Anspruch 15, wobei die Modifikationsmittel (185) ferner Mittel aufweisen zum Bestimmen, daß ein neuer Zweig für das zugehörige Delta des wiedergewonnenen und nicht verworfenen deskriptiven Eintrags erzeugt werden soll, sofern der wiedergewonnene und nicht verworfene deskriptive Eintrag aus der zweiten Arbeitstabelle entfernt wurde, und sofern der wiedergewonnene und nicht verworfene deskriptive Eintrag einen deskriptiven Vorgänger-Eintrag in der zweiten Arbeitstabelle aufweist, der auf einen deskriptiven Eintrag in der Ausgabetabelle querverweist, welcher wiederum auf einen deskriptiven Eintrag in der ersten Arbeitstabelle querverweist, wobei darüber hinaus der querverwiesene deskriptive Eintrag in der ersten Arbeitstabelle ein deskriptiver Vorgänger-Eintrag für einen weiteren deskriptiven Eintrag in der ersten Arbeitstabelle ist, welcher sich auf dem gleichen Zweig wie der deskriptive Eintrag befindet, welcher wiedergewonnen und nicht verworfen wurde.

17. Das Computersystem nach Anspruch 16, wobei die Modifikationsmittel (185) ersetzen:

(c.5.1) einen vorhandenen Änderungsidentifizierer in dem nicht verworfenen deskriptiven Eintrag durch einen neuen Änderungsidentifizierer, wobei der vorhandene und der neue Identifizierer Revisions/Editions-Stufen des Quellmoduls in der vor-verschmolzenen bzw. der verschmolzenen Hierarchie anzeigen, wobei der neue Änderungsidentifizierer in Abhängigkeit davon erzeugt wird, ob ein neuer Zweig für das zugehörige Delta des nicht verworfenen deskriptiven Eintrags in der verschmolzenen Hierarchie erzeugt werden soll;

(c.5.2) eine erste vorhandene Delta-Seriennummer in dem nicht verworfenen deskriptiven Eintrag durch eine erste neue einzigartige Delta-Seriennummer, wobei die erste vorhandene und die neue Delta-Seriennummer das zugehörige Delta in der vor-verschmolzenen bzw. der verschmolzenen Hierarchie identifizieren, wobei die erste neue einzigartige Delta-Seriennummer in Abhängigkeit von der Anzahl der deskriptiven Einträge erzeugt wird, die bis dahin zu der Ausgabetabelle ausgegeben worden sind;

(c.5.3) eine zweite vorhandene Delta-Seriennummer in dem deskriptiven Eintrag durch eine zweite neue einzigartige Delta-Seriennummer, wobei die zweite vorhandene und die neue Delta-Seriennummer das zugehörige Vorgänger-Delta des Deltas in der vor-verschmolzenen bzw. der verschmolzenen Hierarchie identifizieren, wobei die zweite neue einzigartige Delta-Seriennummer aus dem zugehörigen Array des ersten und des zweiten Zwei-Wege- Querverweis-Arrays wiedergewonnen werden, wobei die zweite neue einzigartige Delta-Seriennummer gleich der ersten neuen einzigartigen Delta-Nummer des querverwiesenen deskriptiven Eintrags der Ausgabetabelle ist, dessen erste vorhandene Delta-Seriennummer des querverweisenden deskriptiven Eintrags der ersten und zweiten Arbeitstabelle gleich der zweiten vorhandenen Delta-Seriennummer ist.