Mal wieder Git, aber diesmal ein Thema, was Git nicht kann: Keyword Substitution. Wer RSC, CVS oder SVN kennt, ist früher oder später über die praktischen kleinen Helferchen gestolpert, die in jede Datei die Versionsnummer fest einbrennen, und auch ältere SCM-Fossile verfügen über diese Fähigkeit. Ich selbst habe in meiner Zeit als CVS-Anwender in jeden Dateiheader sklavisch ein $Id$ gehackt und das gleich zur persönlichen Best Practice erklärt, denn schließlich ist es ja wichtig, jederzeit zu wissen, in welcher Dateiversion man unterwegs ist. Daher hat es mich etwas verstört, daß Git nicht nur keine Keyword Substitution kennt, sondern die Git-Entwickler sich auch noch strikt weigern, eine solche einzubauen. Was denken die sich dabei?
Wie sich herausstellt, haben sie gute Gründe -- am einfachsten von Linus Torvalds in einer ausreichend undiplomatischen eMail zusammengefaßt. Die Argumente im einzelnen:
Zunächst einmal ist klar, daß externe Tools von $Id$-Strings verwirrt werden, schließlich haben die keine Möglichkeit, die zu vergleichenden Texte ohne die Substitution zu vergleichen. Aber das ist vielleicht nicht so schlimm, denn erstens kann man ja alle zu vergleichenden Texte vorher durch einen Filter schicken, der die Strings entfernt -- genau so wie es CVS und SVN beim Einchecken tun.
Der zweite Punkt leuchtet auch sofort ein: Ein SCM, welches eine Keyword Substitution vornimmt, muß genau wissen, was man gerade eincheckt. Warum ist das ein Problem? Wir wissen ja schließlich auch, daß man Binärdateien nicht mergen kann, und schrecken trotzdem nicht vor dem Mergen zurück! Der Grund liegt in der Art, wie ein SCM Dateien mit Keywords speichern muss: Nämlich erstaunlicherweise ohne Keywords! Die Keywords werden tatsächlich während des Auscheckens ersetzt, da ansonsten zwei Versionen eines Textes garantiert unterschiedlich wären, selbst wenn sich inhaltlich nichts geändert hat. Irrt sich jetzt das SCM beim Einchecken, so zerstört es die zu sichernde Datei und speichert einen großen Haufen Müll, was im schlimmsten Falle erstmal niemanden auffällt (unbedingt mal ausprobieren: Ein PDF in VSS einchecken -- wird als 7-Bit-EBCDIC-Text erkannt und rettungslos verstümmelt). Dem Nutzer wird das erst bewußt, wenn er mal Dateien aus dem SCM abrufen will. Aber dann sind seine vorherigen Bemühungen bereits zerstört.
Der dritte Punkt klingt erstmal etwas altklug: Natürlich weiß das SCM viel besser, welche Version ich gerade ausgecheckt habe, aber ich will das doch auch sehen! Nun, tatsächlich kann ich das ja auch sehen, aber die Frage ist: Wann muß ich es wissen? Nicht beim Schreiben von Code, denn da arbeitet man ohnehin auf dem HEAD. Interessant wird die Version einer Datei bei der Analyse von Code, und hier spielt die Version einer einzelnen Datei eine verblüffend geringe Rolle. Wichtiger ist hier der Kontext: Welche Dateien gehören zusammen, welche Änderungen bilden einen inhaltlich zusammengehörigen Change Set? An dieser Stelle klickt wieder ein Puzzleteil an die richtige Stelle: Git hat ohnehin keine handlichen Versionsnummern, nur SHA1-Identifier für Change Sets, und die vermißt wirklich niemand im Quelltextheader.
Nun, vielleicht nicht im Quelltextheader, aber wie ist es mit der "About this Application"-Box? Ah, richtig, die ausgelieferten Versionen müssen natürlich irgendwie kenntlich gemacht werden. Aber hier kommt ein anderes Prinzip zum Tragen: Die Produktversion hat nichts mit der technischen Version des SCM zu tun. Wirklich nicht. Und wenn die Produktversion nicht von der SCM-Version abhängt, muß die SCM-Version auch nicht im Produkt stehen. Hier bieten sich Build-Nummern an, die ihrerseits Tags im SCM steuern (das SCM ist also nicht das führende System).
Zuletzt aber noch ein Argument, für das ich im Moment kein Zitat finde (auch das ist von Torvalds, nur beweisen kann ich's nicht): Ein SCM muß Dateien immer unverändert speichern, und wenn sich zwei Versionen einer Datei nur in der Versionsnummer unterscheiden, hat das SCM einen fundamentalen Fehler. Warum? Weil ein SCM schließlich Inhalte speichern muß und nicht einfach nur Nummern hochzählt (das können Taschenrechner besser). Folglich muß ein funktionierendes SCM zwei Dateien, die sich nicht unterscheiden, immer die selbe Versionsnummer zuweisen.
An dieser Stelle muß man erstmal kurz anhalten und ausführlich nachdenken. Es stimmt, natürlich, und es hat Konsequenzen: Demnach sind nicht nur die Keyword Substitutions schlecht, sondern auch alle automatischen Umkodierungen (Unix/DOS, ASCII/UTF-8, ...). Und wer schon ein Weilchen mit verschiedenen Plattformen und SCMs zu tun hatte, weiß, wie viele Probleme sich mit dieser Regel in Luft auflösen.
P.S.: Ich bin sehr froh, recht schnell eingesehen zu haben, daß Torvalds Recht hat. Ich wäre nicht gerne Anhänger einer furchtbaren Idee, noch dazu idiotisch, welche seit Dekaden fundamental fehlgeleitete SCM-Designs bestimmte. Denn ich habe das Licht gesehen. Leider muß ich jetzt zurück in den Keller zu SVN.
Keine Kommentare:
Kommentar veröffentlichen