Eine Changelist fasst in Perforce P4 Änderungen zusammen, die zu einer bestimmten Aufgabe gehören. Änderst du beispielsweise mehrere Dateien, um eine neue Spielfunktion einzubauen oder einen Fehler zu korrigieren, kannst du sie gemeinsam einreichen. Dadurch bleibt später nachvollziehbar, welche Änderungen zusammengehörten.
Was ist eine Changelist?
Bei der Spieleentwicklung betrifft eine Aufgabe häufig mehr als eine Datei. Eine neue Türmechanik benötigt beispielsweise Änderungen am Programmcode, an einer Konfigurationsdatei und möglicherweise an weiteren Bestandteilen des Projekts.
In Perforce P4 lassen sich solche zusammengehörenden Änderungen in einer Changelist organisieren. Sie bildet damit eine logische Einheit innerhalb der Versionsverwaltung.
Statt später nur einzelne veränderte Dateien zu sehen, erkennst du den Zusammenhang zwischen ihnen. Eine Beschreibung kann zusätzlich festhalten, weshalb die Änderungen vorgenommen wurden.
Pending und Submitted Changelists
Eine Changelist kann sich in unterschiedlichen Zuständen befinden. Solange du deine Änderungen noch nicht endgültig an den Server übermittelt hast, handelt es sich um eine Pending Changelist. „Pending“ bedeutet in diesem Zusammenhang, dass die Änderung noch aussteht.
Du kannst darin Dateien sammeln, weiterbearbeiten und die Zusammenstellung verändern. Dadurch eignet sich die Liste gleichzeitig zur Organisation deiner aktuellen Arbeit.
Übermittelst du die Änderungen schließlich an P4, entsteht eine Submitted Changelist. Sie gehört anschließend zur dokumentierten Versionsgeschichte des Projekts und erhält eine eindeutige Changelist-Nummer.
Was enthält eine Changelist?
Zu einer eingereichten Changelist gehören Informationen über die vorgenommenen Änderungen. Dazu zählen unter anderem die betroffenen Dateien, eine eindeutige Nummer und die Beschreibung der Änderung. Außerdem lässt sich nachvollziehen, wer die Changelist eingereicht hat.
Eine aussagekräftige Beschreibung erleichtert die spätere Suche. „Türinteraktion korrigiert“ erklärt den Zweck wesentlich besser als eine allgemeine Angabe wie „Änderungen“.
Ein Beispiel aus einem Spieleprojekt
Angenommen, du korrigierst eine Tür, die sich trotz vorhandenem Schlüssel nicht öffnen lässt. Für die Fehlerbehebung veränderst du drei Dateien:
- die Logik der Tür,
- die Abfrage des Inventars,
- eine Konfigurationsdatei für die Interaktion.
Alle drei Änderungen gehören zur selben Fehlerkorrektur. Du kannst sie deshalb in einer Changelist mit einer Beschreibung wie „Schlüsselprüfung bei verschlossenen Türen korrigiert“ zusammenfassen.
Monate später musst du nicht mehr einzeln rekonstruieren, weshalb diese drei Dateien am selben Tag verändert wurden. Das Dokument hält ihren Zusammenhang fest.
Warum sind Changelists für Teams wichtig?
In größeren Spieleprojekten arbeiten Programmierer, Artists, Designer und weitere Teammitglieder gleichzeitig an zahlreichen Aufgaben. Ohne eine sinnvolle Gruppierung entstünde schnell eine lange Folge einzelner Dateiänderungen, deren Zusammenhang nur schwer erkennbar wäre.
Changelists strukturieren diese Arbeit nach Änderungen beziehungsweise Aufgaben. Ein Teammitglied kann dadurch nachvollziehen, welche Dateien gemeinsam eingereicht wurden und welche Beschreibung der ursprüngliche Bearbeiter hinterlegt hat.
Changelists und Versionsverwaltung
Die Liste ist kein Ersatz für die Versionsverwaltung. Sie ist vielmehr ein Organisationsprinzip innerhalb von Perforce P4.
Die Versionsverwaltung dokumentiert die Entwicklung des Projekts über längere Zeit. Die Listen helfen dabei, einzelne zusammengehörige Änderungen innerhalb dieser Entwicklung zu erkennen.
Warum hilft eine Changelist beim Debugging?
Besonders nützlich wird die Liste bei der Fehlersuche. Angenommen, Build 120 deines Spiels funktioniert, während Build 121 beim Öffnen einer Tür abstürzt. Dann interessiert dich, welche Änderungen zwischen diesen beiden Entwicklungsständen vorgenommen wurden.
Eine Changelist kann zeigen, dass kurz zuvor die Türlogik und die Inventarprüfung gemeinsam verändert wurden. Damit hast du einen konkreten Bereich, den du beim Debugging genauer untersuchen kannst.
Die Liste beweist allerdings nicht, dass eine darin enthaltene Änderung tatsächlich den Fehler verursacht hat. Sie liefert zunächst einen Anhaltspunkt. Erst die weitere Untersuchung zeigt, ob zwischen der Änderung und dem Fehler ein Zusammenhang besteht.
Changelist, Log und Stack Trace ergänzen sich
Bei einem Absturz können mehrere Informationsquellen zusammenhelfen. Log-Dateien zeigen, welche Ereignisse vor dem Fehler auftraten. Ein Stack Trace dokumentiert die Folge aufgerufener Funktionen zum Zeitpunkt eines Fehlers.
Führt dich der Stack Trace beispielsweise zur Türlogik, kannst du anschließend in der Versionsgeschichte prüfen, wann dieser Bereich zuletzt verändert wurde. Die dazugehörige Changelist zeigt dir weitere Dateien, die gemeinsam mit dieser Änderung eingereicht wurden.
So entsteht eine Untersuchungskette: Der Fehler führt dich zu einem Codebereich, die Versionsverwaltung zeigt dessen Änderungsgeschichte und die Liste stellt den Zusammenhang zu weiteren Änderungen her.
Was ist eine Suspect Changelist?
Bei der Fehlersuche kann eine bestimmte Liste als möglicher Verursacher auffallen. Sie ist dann zunächst lediglich verdächtig. Der zeitliche Zusammenhang zwischen einer Änderung und einem Fehler reicht nicht aus, um die Ursache sicher festzustellen.
Deshalb prüfst du die enthaltenen Änderungen genauer. Dabei können Tests, Logs, Stack Traces und ein Vergleich mit früheren Versionen helfen. Erst danach lässt sich beurteilen, welche Änderung tatsächlich korrigiert werden muss.
Changelists und Code Reviews
Zusammengehörende Änderungen lassen sich außerdem gemeinsam überprüfen. Bei einem P4 Code Review können andere Teammitglieder Änderungen betrachten und kommentieren.
Dadurch verbindet sich die Versionsgeschichte mit dem Review-Prozess. Die Changelist dokumentiert, welche Dateien zu einer Änderung gehören, während der Code Review die gemeinsame Prüfung dieser Änderungen unterstützt.
Von der Änderung zum neuen Build
Nach einer Fehlerkorrektur entsteht häufig ein neuer Build. Dadurch kann das Team testen, ob die korrigierte Fassung funktioniert und ob die Änderung unbeabsichtigte Auswirkungen auf andere Bereiche des Spiels verursacht.
Die Listen bilden damit einen Teil einer größeren Entwicklungskette: Du veränderst Dateien, fasst zusammengehörende Arbeit zusammen, reichst sie ein, lässt sie gegebenenfalls überprüfen und testest anschließend einen neuen Entwicklungsstand.
Weitere Artikel auf Games und Lyrik
Wenn du dich neben der technischen Spieleentwicklung auch für klassische Adventures interessierst, findest du auf Games und Lyrik weitere Beiträge. In Runaway 3: A Twist of Fate begleitest du Brian und Gina durch ein Point-and-Click-Adventure mit Rätseln, ungewöhnlichen Situationen und einer Geschichte voller Wendungen.
Weitere Informationen zu den Listen und ihrer Verwendung findest du in der offiziellen Dokumentation zu Perforce P4.
