Implementieren meist atomaren ClearCase commits

Question

Ich habe ein Projekt, wo ich eine Reihe von Operationen auf einer dynamischen Ansicht ausführen müssen. Wenn eine dieser Operationen fehlschlägt oder ein Fehler im Programm auftritt, muss ich die Commits zurücksetzen können.

Der einfache Weg scheint zu sein, einfach die Befehle in eine Warteschlange zu stellen und dann, wenn mein Programm die Verarbeitung beendet, die Warteschlange auszuführen. Ich bin jedoch besorgt über ein außergewöhnliches Ereignis, das die Commits unterbricht und einen inkonsistenten Datensatz auf dem Server verursacht.

Oder mit anderen Worten, ich bin auf der Suche nach einer Möglichkeit zum Erstellen eines Svn-style 'Changeset' in dynamischen Ansichten von Clearcase. Die Skriptsprache, die ich benutze, ist Perl, wenn es darauf ankommt.

Ideen?

Answer 1

Da die Atomizität der Operation in ClearCase auf der Dateiebene liegt, gibt es keine strenge Entsprechung von svn changeset (d. H. Eine "Revision").

Am nächsten an einer Änderung in ClearCase ist der Begriff der Aktivität (in UCM) oder ein Labelsatz für eine Sammlung von Dateien (eine UCM-Baseline ist tatsächlich näher, da sie auf einem Labels darstellt, die Sie nicht verschieben können) vordefinierte Satz von Dateien - UCM Komponente -)

Nun UCM oder nicht, würde ich empfehlen:

• den Zweig Verriegelungs, auf das Sie checkins (auf diese Weise machen, Der VOB ist immer noch zugänglich, und niemand versucht, andere Versi hinzuzufügen ons an diesem Zweig während des „atomaren“ Operation)
• tun, um Ihre checkins
• den Zweig entsperren

Bei Problemen, während der Zweig aufhängt, können Sie ‚ct rmver‘ Versionen hinzugefügt . (Anmerkung: mit Sorgfalt zu verwenden: a rmver kann nicht rückgängig gemacht werden)

• Hinweis 1: wenn Sie nicht in UCM arbeiten, müssen Sie notieren alle eingecheckten Versionen um in der Lage zu sein, sie rmver

• Anmerkung2: Als ich sagte "den Zweig sperren", meinte ich natürlich: "Schloss für alle außer dir" (-nusers yourLogin). Auf diese Weise können nur Sie checkins machen (das auf dem Zweig im AKTUELLEN auf alle Dateien gilt, auf das Sie arbeiten (Haupt- oder eine andere).

---

Das Problem mit diesem Ansatz ist es, was die Kunden (die anderen Benutzer mit ihrem dynamischen Blick auf dem Zweig in AKTUELLEN) werden während Ihrer atomare Transaktion sehen.
Da diese dynamische Ansichten sind, werden sie die eingecheckten Dateien sehen, während diese Dateien checken Eins nach dem anderen, das ist vielleicht nicht gut, besonders wenn es 200 Dateien gibt d wenn der gesamte Prozess mehr als eine Minute dauert.

Eine Lösung wäre, diese Client-Ansichten gesetzt spec ihre Config auf folgendes haben:

element * .../myBranch/FREEZED_LATEST 
element * .../myBranch/LATEST 

Wenn Sie nicht atomar changeset tun begehen, das Etikett FREEZED_LATEST nicht vorhanden ist, und alle Client-Ansichten sind LATEST, wie sie sollten. Jeder Check-in wird sofort von allen gesehen.
Aber während des Atom begehen, könnten Sie:

• zunächst einen Label FREEZED_LATEST auf allen aktuellen Dateien (derzeit in NEUESTE, das ist)
  Das heißt, alle Clients nur die spezifischen Versionen sehen während das Atom begehen
• tun, um Ihren Prozess (den ganzen Weg oder beim Rollback: In beiden Fällen ist der Zweig gesperrt, und die Config-Spezifikation der Kunden zeigt immer noch die gleiche „eingefroren“ content)
• das Label löschen FREEZED_LATEST (Alle Clients sehen das neue LATEST, das sich aus Ihrer atomaren Operation ergibt, und können neue v ersionen mit einigen Kassen ihres eigenen)

Answer 2

Sperren Sie alle anderen Benutzer aus.

Führen Sie eine Sicherung Ihres Servers durch.

Machen Sie Ihre Commits.

Wenn etwas schief geht, Wiederherstellen von Daten aus der Sicherung.

Answer 3

Ich habe nicht in Jahren Clearcase verwendet, also hier sind ein paar streunende und naive Gedanken.

Schauen Sie voraus und bestimmen Sie, ob Dateien nicht synchron sind.

Ich würde alle Dateien sperren, die Sie einchecken, bevor Sie sie einchecken, und wenn Sie einen nicht sperren können, brechen Sie das ganze Chaos mit einer nützlichen Nachricht ab.

Können Sie ein Einchecken "löschen"? Oder rückgängig machen, also schaut HEAD eine vorherige Version an? Definieren Sie Ihr rückgängig gemacht von einem Check-in.

Können Sie eine temporäre Zweigstelle, Check-in, dann merge/Rebase (meine Terminologie ist hier verlieren). Auf diese Weise ist Ihr Rollback, den Zweig zu töten. Obwohl ich mich erinnere, dass Mitarbeiter Clearcase verfluchten, weil es sich verzweigt.

Im Allgemeinen ist das Einreihen in Warteschlangen zwar großartig, aber verwenden Sie die Warteschlange, um potenzielle Probleme zu identifizieren, bevor sie auftreten. Definieren Sie außerdem Ihre Aktionen und ihre UNDO-Kriterien. Wenn Sie also etwas tun wollen, das nicht pseudoatomar ist, können Sie sie warnen: "Dies könnte unordentlich werden".

Answer 4

Mit V7.1.1 unterstützt Clearatom commits.You in der Lage, eine Reihe von Dateien als eine Einheit zu behandeln und überprüfen sie in oder Rollback basierend auf einem gegebenen criteria.For mehr info, für weitere Informationen siehe https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.relnotes.doc/topics/c_cc_relnotes_features.htm