[Allegro] svn.allegro-c.de

Di Jan 8 12:13:10 CET 2008

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg, liebe Mitleser,

Versionskontrollsysteme versuchen, *Aenderungen* an Dateien zu
identifizieren und speichern diese Aenderungen intern nur inkrementell.
U.a. deshalb - s.u. - ist bei SVN anders als in einem "normalen"
Dateisystem ein "copy" eine unglaublich schnelle und auch sehr wenig
Speicherplatz verbrauchende Aktion: Es wird ja nur vermerkt, welche
Dateien wo nun auch gespeichert sind und was die zugehoerige
Versionsnummer ist, denn an den Dateien geaendert wird durch das
Kopieren ja nichts.

Versionskontrollsysteme kommen am besten mit "Quelltext" zurecht,
also Textdateien, die in (kurzen) Zeilen organisiert sind. Bei
Aenderungen an der Datei werden geaenderte Zeilen identifiziert und
diese vermerkt. RTF-Dateien sind auch Textdateien ("Zeilen" im ASCII-
Datei-Sinne sind hier meist ganze Absaetze), die ueblichen Werkzeuge
numerieren allerdings jedoch bereits beim leeren Abspeichern einer
RTF-Datei alle Fonts und Formate komplett um, so dass sich
typischerweise jede einzelne Zeile aendert, auch wenn inhaltlich
nichts passiert ist.

Versionskontrollsysteme ermoeglichen verteilte Bearbeitung, erfahrungs-
gemaess aendern mehrere Bearbeiter selten gleichzeitig dieselbe Datei,
und wenn, dann selten gleichzeitig dieselbe Stelle. Falls es doch
einmal passiert, gibt es technische Mechanismen, die sicherstellen,
dass der als zweiter "eincheckende" Bearbeiter die entstehenden
Konflikte zunaechst bereinigen muss. Bei RTF-Dateien wegen der oben
beschriebenen Umstaende und bei Binaerdateien (etwa Graphiken) betrifft
der Konflikt stets die gesamte Datei (entweder weil automatisch alle
Zeilen betroffen sind oder weil es keine "Zeilen" gibt), daher gibt
es in dieser Situation optional die Moeglichkeit, diese Dateien durch
"Locking" nur dann bearbeitbar zu machen, wenn der Benutzer vorher
*exklusiven* Aenderungszugriff angefordert hat.

Allegro als ueber die nackte Datenbank hinausgehende Anwendung ist da
nicht viel anders: PRESTO gab jedem Bearbeiter exklusive Rechte auf
den einen, jeweils zu bearbeitenden Datensatz, andere Benutzer sahen
"Satz gesperrt". Damit liess sich gut leben, denn weil ja immer nur
ein Satz bearbeitbar war, waren alle Benutzer gezwungen, sehr haeufig zu
speichern. Im Hinblick auf globale Ersetzungen und Manipulationen bzw.
auch auf Undo-Funktionalitaet ist das in manchen Situationen allerdings
eher zu haeufig gewesen. a99 ermoeglicht es, viele bearbeitete Saetze
lokal zwischenzuspeichern, anhand der Datumsstempel gibt es eine
primitive Form der Konflikterkennung, allerdings nur auf Datensatz-
nicht auf Kategorie- oder Unterfeldebene. Konfliktloesung besteht auch
hier darin, dass der Bearbeiter, der als zweiter Speichert, handeln
muss. Hat man Bearbeiter, die von Montag morgen bis Freitag mittag immer
nur "Ergebnisse aufbewahren" und nie speichern, gibt es Freitag
Nachmittag ziemlichen Frust, a99 hindert einen nicht daran, "zu selten"
zu speichern.

|> Mit "svn copy" haben Sie seinerzeit den Schnappschuss (Tag / Branch)
|> http://svn.allegro-c.de/allegro/V27.6 erzeugt ;-)
|>
| Dann sagen Sie das doch gleich, statt obskure Metaphern zu benutzen,
| die einem bei der Suche nach der richtigen Methode nicht helfen.

"copy" ist der Name des Kopierbefehls. Jeder kann staendig Kopien fuer
irgendwelche Zwecke anlegen und mit den Kopien anschliessend machen
was er will, der copy-Befehl ist immer derselbe.
Der Zielname "V27.6" in Ihrem Repository gab mir den Eindruck, dass in
diesem Fall der Zweck der Kopie war, den Auslieferungszustand von
Version 27.6 festzuhalten (und insbesondere an dieser Kopie in Zukunft
keine Veraenderungen mehr vornehmen zu wollen).

| svn log -v --stop-on-copy http://svn.allegro-c.de/allegro/V27.6
| ------------------------------------------------------------------------
| r748 | ev | 2007-10-05 11:05:30 +0200 (Fri, 05 Oct 2007) | 1 line
| Changed paths:
|    A /allegro/V27.6 (from /allegro/standard:714)
|    R /allegro/V27.6/demo2 (from /allegro/standard/demo2:720)
|    R /allegro/V27.6/demo2/cat.adx (from
/allegro/standard/demo2/cat.adx:747)
|    R /allegro/V27.6/demo2/cat.api (from
/allegro/standard/demo2/cat.api:747)
| ...
|    R /allegro/V27.6/software/update.exe (from
/allegro/standard/software/update.
| exe:743)
|
| made a copy
| ------------------------------------------------------------------------

Zugegebenermassen ist es moeglicherweise ein verwegener Schluss von mir
gewesen, aus dem Kommentar "made a copy" im Zusammenhang mit dem
Zielnamen "V27.6" Schluesse auf den Zweck der Kopie zu ziehen.

| Dieses ganze Zeug *kann* nicht jeder ständig zusätzlich zu allem
| anderen, um was man sich kümmern muß, präsent haben. Da braucht's klipp
| und klar genau die Begriffe, die unmittelbar weiterhelfen. Wir müssen
| das auch ständig beachten bei allen Hinweisen usw., die wir zur
| allegro-Nutzung geben. Diese Liste besteht nicht aus Freaks, und
| hinsichtlich SVN sind auch wir keine.

Ich moechte jetzt nicht umstaettern, aber Ihre "Begriffe" sind nur
"Terme" und was Sie "Zeug" nennen, sind die Begrifflichkeiten und
Konzepte dahinter. Auch in der allegro-Liste bestehen Antworten auf
Fragen ja nicht in einem lapidaren 'druecken Sie die Tasten "h", "e",
"l", "p", und "enter"', sondern sind eher im Stil 'in dieser Situation
ist es so und so, daher wollen Sie als naechstes vermutlich dies und
das, daher sollten Sie "help" eingeben'. D.h. reines Knoepfchendruecken
ist eher nicht erwuenscht, sondern bewusste Interaktion mit dem
System auf Grundlage eines allen Anwendern gemeinsamen Minimums von
konzeptuellen Hintergrundwissen.

| Sofort eine Kopie von dem ganzen Zweig zu machen, wenn alles genauso
| im Installationspaket drin ist, ist ja wohl übertrieben. Genauso
| wie "ständig überall ändern".

Besonders Subversion mit seiner Nutzerbasis, die mit diversen anderen
Versionskontrollsystemen sozialisiert worden ist, bemueht sich, keine
Vorgaben zu machen, die denkbare Strategien unmoeglich machen wuerden:
svn ist ein Werkzeug, im Handbuch werden Strategien zum Umgang mit
Repositories vorgestellt und diskutiert, die - innerhalb der jeweiligen
Rahmenbedingungen - erfolgreich sein koennen.

Ich moechte hier nur zu bedenken geben, dass es nach einigen Jahren
sehr laestig sein kann, herauszufinden, *was* in einem Installations-
paket drin gewesen ist: Man muss es ggfls. erst einmal irgendwo hin
installieren, um das Datum der neuesten enthaltenen Datei herauszufinden
und dann im Repository die zugehoerige Revison Number zu diesem
Zeitstempel ermitteln (und wenn das Einchecken ins Repository auch noch
deutlich *nach* dem Erstellen des Installationspakets erfolgt ist, wird
erstens die Ermittlung schwieriger und zweitens steigt das Risiko, dass
man zu einigen Dateien andere Versionen erwischt, als im Installer
enthalten waren).

Zwei Dinge sollten Sie daher dringend beherzigen:

1. Erst einchecken, und dann erst (moeglichst auf Grundlage dieser
~   Dateien mit ihren durch das Einchecken geaenderten Datumsstempeln)
~   inst-all.exe schnueren

2. Bei wichtigen Versionen (wie etwa zweifellos V27.6 es war, eine zu
~   erwarten kurzlebige Vx.0 es jedoch moeglicherweise nicht ist) zeitnah
~   (bzw. unter Rueckgriff auf die bei 1. zugeordnete Revision Number) im
~   Repository eine Kopie erstellen.

[3. Haeufigeres Einchecken hat selten geschadet. Man *kann* ja Versions-
~   kontrollsysteme durchaus als Vehikel zum "Deployment" nutzen: Damit
~   koennen gewisse (interessierte, technisch versierte) Anwender Fehler
~   finden, die sonst erst nach dem Bereitstellen von inst-all.exe
~   auffallen (ich denke da v.a. an Parameterdateien, Hilfetexte und
~   Flexe etc., .exe-Dateien sollte man m.E. eher nicht haeufig
~   einchecken, wenn ueberhaupt).
]

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3-nr1 (Windows XP)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHg1rGhKFJT0F1FsoRAnVCAKCG9PBQBPzZqpq0+OtzMFwIEZvCzwCfVBYz
ZI/Mxl7L/Rvn9mNFKMZ+XZk=
=PP9M
-----END PGP SIGNATURE-----