Subversion mit BlueJ, die Fortsetzung

By | 30.10.2015

Ich habe vor ein paar Jahren schon mal über Subversion mit BlueJ geschrieben, inzwischen habe ich das mit Schülern weiter erprobt und mit Peter Brichzin einen Workshop dazu auf der INFOS15 gehalten. Subversion: So heißt ein verbreitetetes System, mit dem verschiedene Autoren gleichzeitig an einem aus vielen Dateien bestehenden Progammierprojekt arbeiten können, so dass jeder jeweils die aktuelle Fassung der anderen Teammitglieder zur Verfügung hat.
Für den Workshop habe ich eine kleine Broschüre gemacht (ich mag Broschüren), hier ist deren Inhalt, falls mal jemand danach sucht.


Teil 1 – Auschecken

Teamarbeits-Menü einschalten

Bevor man den in BlueJ integrierten SVN-Client benutzen kann, muss man ihn frei­schalten. Dazu muss man im Menü unter „Werkzeuge > Einstellungen… > Inter­face“ ein Häkchen setzen bei „Teamarbeitswerkzeuge anzeigen“.

Erstmalig ein BlueJ-Projekt aus einem Reposito­ry aus­checken

Es ist egal, ob man an dieser Stelle mit einem bereits geöffneten BlueJ-Projekt arbeitet oder nicht, die neu heruntergeladenen Dateien werden auf jeden Fall als neues, eige­nes BlueJ-Projekt gespeichert.

Nach Auswahl des Menüpunkts „Werkzeuge > Teamarbeit > Arbeitskopie erstel­len…“ muss man die Serverangaben eingeben:

svn_anmelden

Das Passwort braucht man bei öffentlichen Repositories nur für das Hochladen; aller­dings verlangt BlueJ auf jeden Fall die Eingabe eines (auch beliebigen) Benutzerna­mens.

Danach kann man sich mit dem Knopf „Anzeigen“ die unter dieser Adresse gespei­cherten BlueJ-Projekte zeigen lassen:

svn_projektauswahl

Nach der Auswahl des BlueJ-Projekts, das man herunterladen möchte, wird man gebe­ten, einen Speicherort dafür anzugeben. Das heißt, die Dateien werden auf jeden Fall in einem neuen BlueJ-Projekt gespeichert.

Tipps:

  • Das Auschecken erfolgt üblicherweise nur einmal am Anfang. Da­nach lädt man nicht mehr das ganze Projekt neu vom Server herunter, sondern aktualisiert nur die auf dem Server geänderten Dateien oder fügt eigene Ände­rungen der Version auf dem Server hinzu.
  • Ausnahme: Wenn später einmal irgendetwas mit dem eigenen BlueJ-Projekt nicht funktioniert oder zu kompliziert wird, dann ist es manchmal einfacher, die Datei­en wieder ganz neu vom Server auszuchecken und mit einem neuen BlueJ-Pro­jekt weiterzuarbeiten. Man muss nur daran denken, das alte zu löschen.
  • Fehlerquelle: Beim Speichern reicht ein Laufwerksbuchstabe nicht, man muss einen Ordner angeben, in den dann der BlueJ-Projektordner gespeichert wird. Wenn man den Namen eines bereits existierenden BlueJ-Projekts angibt, kann das dazu führen, dass ein BlueJ-Projekt innerhalb eines anderen gespeichert wird (als package), was alles nur komplizierter macht.

Aufgabe: Checken Sie beliebige Projekte aus dem Server aus, aber auf jeden Fall das BlueJ-Projekt „SVN Aufgabe 1“ für den nächsten Schritt.


Teil 2 – Erstes Arbeiten

Benutzername und Passwort eingeben

Checken Sie das BlueJ-Projekt „SVN Aufgabe 1“ aus.

Bisher waren Benutzername und Passwort egal, aber ab diesem Zeitpunkt müssen Sie konkrete Daten eingeben. Wählen Sie dazu im Menü „Werkzeuge > Teamarbeit > Teamarbeitseinstellungen…“ und ergänzen Sie die fol­genden Informationen:

svn_teamarbeitseinstellungen

Der Benutzer ist „fortbildung“, das Passwort erfahren Sie mündlich.

Aktualisieren (update) und Abgeben (commit)

Aufgabe: Legen Sie in „SVN Aufgabe 1“ eine neue Klasse an, die das Interface „Tier“ implemen­tiert. Die Klasse „Loewe“ kann als Beispiel dienen. Sie machen es sich etwas einfacher, wenn Sie ein exotisches Tier wählen, weil Sie dadurch Konflikte mit anderen Projekt­mitarbeitern vermeiden.

svn_aufgabe1

Schritt 1: Bevor Sie Ihre Klasse hochladen, sollten Sie schauen, ob es inzwischen viel­leicht schon Beiträge anderer Projektmitarbeiter gibt. Wählen Sie dazu im seitlichen Menü unten „Aktualisieren…“ (englisch: „Update…“). Wenn inzwischen jemand an­deres die Klasse „Kakapo“ angelegt hat (ein flugunfähiger Papagei auf Neuseeland), wird Ih­nen folgender Dialog angezeigt:

svn_aktualisieren_kakapo

Wenn Sie das Aktualisieren bestätigen, wird der Kakapo Ihrem BlueJ-Projekt hinzuge­fügt.

Schritt 2: Laden Sie jetzt Ihre eigenen Änderungen (Ihre Klasse „Pinguin“ zum Beispiel) hoch. Wählen Sie dazu im seitlichen Menü unten „Abgeben…“ oder „Commit…“ Darauf erscheint eine Liste der von Ihnen geänderten Dateien. Fügen Sie einen Kom­mentar hinzu und geben Sie die Änderungen ab:

svn_abgeben_pinguin

Aufgabe: Führen Sie einige Updates und Commits durch. Wenn Sie auf Konflikte stoßen, ignorieren Sie sie bis zum nächsten Schritt.

Grundsätzliche Reihenfolge beim Arbeiten

Nach dem erstmaligen Auschecken des Projekts sieht das Arbeiten immer so aus:

  1. Update, um zu sehen, ob sich am Server etwas geändert hat.
  2. Eigenen Code ergänzen und testen.
  3. Commit – der findet nur statt, wenn es keine Konflikte mehr gibt.

svn_arbeitszyklus

Tipps und Regeln fürs Arbeiten mit Schülerinnen und Schülern:

  1. Einen Commit nur dann durchführen, wenn alle Klassen im BlueJ-Projekt fehlerfrei übersetzt werden.
  2. Um Konflikte zu vermeiden, sollte klar sein, welches Team oder welche ein­zelne Schülerin für welche Klasse oder Klassen zuständig sind. Und die Schüler müssen die Finger von den Klassen anderer Schüler lassen.
  3. Wenn eine Datei ganz gelöscht wurde, kann sie mit BlueJ nicht mehr aus dem Repository ergänzt werden. Man muss dann das Projekt komplett neu aus­checken und damit weitermachen, oder die fehlende Datei von dort ergänzen.

Teil 3 – Konflikte

Wenn mehrere Bearbeiter unabhängig von einander an einer Klasse arbeiten, kommt es zu einem Konflikt. Das SVN-System kann einfache Konflikte selbstständig auflösen, bei den meisten muss aber ein Benutzer entscheiden, welche der in Konflikt stehenden Versionen gelten soll.

Aufgabe: Checken Sie das Projekt „SVN Aufgabe 2“ aus und ergänzen Sie eine noch nicht vorhandene getter- oder setter-Methode für ein Attribut der Klasse „Held“. Führen Sie dann einen Commit durch (bzw. vorher ein eventuell einge­fordertes Update).

Fall 1: Die entstehenden Konflikte lassen sich automatisch lösen. Dann zeigt BlueJ – nach dem Aktualisieren – folgende Meldung, mit der man das automatische Zusammenführen bestätigen kann:

svn_konflikt1

Fall 2: Der Konflikt lässt sich nicht automatisch lösen, weil Attribute der Klasse be­troffen sind oder die Änderungen eine Methode betreffen. Dann meldet BlueJ den Kon­flikt so:

svn_konflikt2

Daraufhin lässt man sich die Konflikte anzeigen. Die in Konflikt stehenden Codestellen werden beide in einem BlueJ-Editorfenster angezeigt. Von den Zeichen <<<<<<< bis ======= steht die eine Fassung (die des aktuellen Benutzers), von den Zeichen ======= bis >>>>>>> steht die andere Fassung (die aktuell auf dem Server befindli­che). Der aktuelle Benutzer muss den Konflikt manuell lösen.

svn_konflikt3

Tipp:

  • Im Rahmen eines Workshops sind Konflikte schwer zu lösen: Wenn es einen Kon­flikt gibt, und mehrere Teilnehmer versuchen gleichzeitig, ihn zu lösen, gibt das nur noch mehr Durcheinander.
  • Beim Arbeiten mit Schülerinnen und Schülern ist es besser, wenn sich die Grup­pen auf einzelne Klassen spezialisieren, so dass Konflikte ganz vermieden werden.

Teil 4 – Der Server

Man kann einen SVN-Server lokal im Netz installieren (etwa den Visual SVN Server https://www.visualsvn.com/server/ für Windows), aber eigentlich möchte man einen über das WWW erreichbaren Server. Dafür gibt es verschiedene kostenlose Anbieter, die aber alle das Problem haben, dass a) die Projekte öffentlich einsehbar sind (Vorteil: Keine Registrierung zum Aktualisieren nötig, Nachteil: Urheberrecht und Daten­schutz) und b) die Projektarbeiter alle eine Registrierung brauchen, wenn sie Commits durchführen sollen.
Unsere Projekte sind bei sourceforge.net gehostet. Ein SourceForge-Projekt kann man allerdings nicht so einfach wieder löschen, man muss eine Nachricht an einen Admi­nistrator schicken, der die Löschung einleitet. Die Inhalte des SourceForge-Projekts, also die BlueJ-Projekte, kann man natürlich jederzeit verändern.

Vorgehen:

  1. Registrierung bei SourceForge (einmalig) unter Angabe einer E-Mail-Adresse und eines Benutzernamens; das Passwort kann frei gewählt werden. Werden für Schüler Dummy-Accounts erstellt, besteht natürlich die Möglichkeit, dass sie E-Mail und Passwort ändern.

  2. Anmelden bei SourceForge und Anlegen eines neuen Projekts. Dabei enthält die voreingestellte Auswahl als Versionskontrolle nicht Subversion, sondern das jüngere Git. Außerdem kann man wählen, ob man ein Wiki, ein Forum, ein Ticketsystem oder andere Features haben möchte:
    svn_sourceforge

  3. Das SourceForge-Projekt ist zu Beginn ganz leer. Üblicherweise gibt es bei Subversion auf der obersten Ebene die Ordner „branches“, „tags“ und „trunk“; nur in letzterem werden die aktuellen Dateien gespeichert. Die anderen Ordner betreffen Subversion-Features, die von BlueJ nicht genutzt werden. Man kann also auf sie verzichten. Dann muss man nur:
    1. Ein neues BlueJ-Projekt anlegen.
    2. „Werkzeuge > Teamarbeit > Projekt gemeinsam nutzen…“ auswählen, Benutzername, Passwort und Serveradresse des SourceForge-Projekts eingeben. Das war’s schon.

  4.  Will man dennoch mit den Ordnern „branches“, „tags“ und „trunk“ arbeiten, etwa um in Zukunft die Möglichkeiten anderer Subversion-Clients zu nutzen, muss man einen externen SVN-Client benutzen; mit BlueJ alleine geht das nicht.
    1. Kommandozeilen-SVN-Client bei Linzux: Die bei SourceForge angegebenen Befehle eingeben.
    2. Mit einem anderen externen SVN-Client (etwa TortoiseSVN) eine temporä­re lokale Kopie des – vorerst noch leeren – Repository anlegen. Dann die drei Order lokal anlegen und auf den Server hochladen („commit“). laden. Danach wird die temporäre Kopie gelöschgt; die Ordner werden nur auf dem Server gebraucht.

Aufgabe: Legen Sie ein neues BlueJ-Projekt an und fügen Sie es mit „Werkzeuge > Teamarbeit > Projekt gemeinsam nutzen…“ dem SourceForge-Projekt svn.code.sf.net/p/fortbildung/code/ hinzu.

Tipps:

  • Jeder Projektmitarbeiter braucht einen eigenen Benutzernamen und ein eigenes Passwort, eventuell Dummy-Accounts für Schüler anlegen.
  • Ein möglichst kurzer Projektname erleichtert das Eingeben der Serveradresse in BlueJ.
  • Eine im Repository angelegte Datei (also auch Code) kann man nicht einfach wieder löschen. Grundsätzlich bleiben alle bisherigen Versionen von Textda­teien erhalten – man soll bei Subversion auch auf frühere Versionen zurückgrei­fen können soll, auch wenn BlueJ diese Funktion nicht unterstützt.

Teil 5 – Workflow für die Lehrkraft

Tortoise SVN – Update, Commit

Wenn man als Lehrkraft mehrer Projekte verwalten möchte, ist der in BlueJ integrierte SVN-Client umständlich, es empfiehlt sich die Verwendung eines eigenen SVN-Clients, für Windows z.B. TortoiseSVN (http://tortoisesvn.net/).

Damit kann man z.B. einen Ordner mit verschiedenen gesammelten BlueJ-Projekten mit einem SVN-Repository verknüpfen.

svn_tortoise_verzeichnisse

Nach Belieben markiert man einige der Verzeichnisse darin mit TortoiseSVN als „add to ignore list“, so dass diese Verzeichnisse eben nicht hochgeladen werden. Im Bild lie­gen nur die grünen Verzeichnisse auf dem Server und werden damit synchronisiert.

Man aktualisiert die BlueJ-Projekte jetzt nicht mehr von BlueJ aus (und kann das auch gar nicht), sondern über den eigenen Client, der sich in das Windows-Kontektmenü integriert:

svn_tortoise_update

Das Menü bietet noch weitere Möglichkeiten von Subversion, die für das Arbeiten in der Schule und mit BlueJ aber alle nicht nötig sind:

svn_tortoise_contextmenu

Tipps:

  • Wenn die Lehrkraft mit TortoiseSVN arbeitet, kann sie nicht wie die Schüler mit BlueJ arbeiten. Bei den Schülern hat jedes BlueJ-Projekt seine eigene .svn (ein verstecktes Verzeichnis mit SVN-Daten), bei der Lehrkraft gibt es ein .svn für das Verzeichnis mit den BlueJ-Projekten.
  • Will die Lehrkraft sich ein BlueJ-Projekt aus Schülersicht betrachten, muss sie das Projekt erst aus BlueJ heraus auschecken und kann das daraufhin neu ge­speicherte Projekt dann auch mit BlueJ committen. Das ist dann aber nicht das Projekt im eigentlichen zentralen BlueJ-Ordner des Lehrers.

Tortoise SVN – Eine lokale Kopie des Repository

Ganz am Anfang steht das Anlegen einer lokalen Kopie des Repository:

  • Optional: Legen Sie ein leeres Repository auf einem Server an.
  • Legen Sie ein Verzeichnis an für alle Projekte, die Sie zum Beispiel mit einer Schulklasse nutzen wollen, etwa „Klasse_10a“.
  • Wählen Sie für das Verzeichnis im Kontextmenü „SVN Checkout…“
    svn_tortoise_checkout
  • Geben Sie danach die URL des eben angelegten oder bereits existierenden Repository an:
    svn_tortoise_checkout2
  • Danach werden alle Verzeichnisse und Dateien im Repository – also in der Regel alle BlueJ-Projekte dort – in das gewählte Verzeichnis übertragen.
  • Ab jetzt kann das gewählte Verzeichnis mit dem Repository synchronisiert werden. Das geschieht über „SVN Update“ beziehungsweise „SVN Commit…“ im Kontextmenü.

Teil 6 – Erfahrungen

Rückmeldung aus der Praxis

  • Kommt bei Schülern sehr gut an.
  • Die Aktualisierung bestehender BlueJ-Projekte ist leichter als sie etwa bei Moodle aktuell zu halten
  • Am Anfang unbedingt im Computerraum gemeinsam machen; zu Hause kommt kaum einer allein zurecht
  • Gelegentlich gibt es ein unerklärtes write lock auf lokalem Projekt. Dann ein­fach neu auschecken und den bisher verwendeten BlueJ-Projekt-Ordner lö­schen.
  • Interessierte Schüler gehen ins Repository und blättern dort. („Wer hat die Da­tei gelöscht?“)
  • Für Projektarbeit enorm hilfreich. Der Austausch und die Koordination gehen sehr viel schneller und fehlerfreier als beim manuellen Dateienaustausch zwi­schen Teammitgliedern. Im Computerraum verständigt man sich durch kurzes Zwischenrufe „Habt ihr schon Update gemacht“ usw.
  • Oft arbeiten Schüler mit dem Account eines anderen Schülers, weil die Ab-/Anmeldung ihnen zu umständlich erscheint oder nicht alle ihre Zugangs­daten dabei haben.
  • Es ist vielleicht hilfreich, wenn Schülerinnen und Schüler erst einige Zeit lang nur BlueJ-Projekte auschecken (Aufgaben, Musterlösungen), und erst, wenn sie damit vertraut sind, Commits durchführen.
  • Schülerinnen und Schüler denken selten daran, einem Commit einen Kommen­tar hinzuzufügen.

Typische Probleme

  • Eingabe der korrekten Daten in BlueJ (Benutzername, Passwort) für manche schwierig, das Passwort wird vergessen oder nicht richtig aufgeschrieben – Schüler müssen sich ihre Zugangsdaten aufschreiben und jedesmal mitbringen.
  • Tatsächlich werden Schüler immer die Zugangsdaten ihrer Mitschüler nutzen. Das hat den Nachteil, dass man eventuelle Zugangsprobleme erst spät feststellt.
  • Manche Schüler hatten Schwierigkeiten, zu Hause die Teamarbeitseinstellun­gen in BlueJ einzuschalten, weil sie den Menüpunkt nicht gefunden haben, eventuell ist das Interface bei BlueJ auch auf englische Sprache eingestellt.
  • Die Arbeit mit dem in BlueJ integrierten und einem externen SVN-Client muss getrennt bleiben. Wenn der externe Client eine .svn-Datei in einem BlueJ-Pro­jekt entdeckt, führt das zu Problemen.
  • Gelegentlich kommt es aus irgendwelchen Gründen zu SVN-Fehlermeldungen des BlueJ-Clients (wie einem write lock, einem von BlueJ nicht genutzten und ansprechbaren SVN-Feature). Dann einfach das Projekt ganz neu auschecken, das alte lokale löschen und eventuelle Codeergänzungen noch einmal durch­führen.Cartoon http://xkcd.com/1597/
    Randall Munroe/xkcd, Creative Commons Attribution-NonCommercial 2.5
  • Enthält ein Verzeichnis Bilddateien, fügt Windows oft eine versteckte Datei „thumbs.db“ hinzu, die dann mit synchronisiert wird.

Zur Erinnerung und als Übersicht:

  • Checkout – macht man meist einmalig und lädt dabei alle Inhalte aus einem Repository in ein lokales Verzeichnis.
  • Update – führt man regelmäßig und insbesondere vor Beginn eigenen Arbeitens durch. Dabei werden lokale Fassungen eventuell durch aktuellere aus dem Repository ersetzt. Kann zu Konflikten führen.
  • Commit – führt man unmittelbar nach dem eigenen Arbeiten durch. Wenn inzwischen neuere Fassungen im Repository liegen, wird man stattdessen zu einem Update und anschließender Konfliktläsung gezwungen. Danach kann man den Commit noch einmal versuchen.

Teil 7 – Beispiele

Einfaches Tic-Tac-Toe mit Model-View-Controller

Als Fingerübung vor der eigentlichen Projektarbeit sollte ein Tic-Tac-Toe-Spiel pro­grammiert werden. Dazu wurde in einer Stunde ein Klassendiagramm erstellt, ange­fangen vom Model (was muss gespeichert werden?) über den View (was muss der er­fahren, um den Spielstand darstellen zu können?) bis hin zum Controller.

svn_mvc_tictactoe

Dann wurden drei Teams eingeteilt (Alpha, Bravo, Charlie); in jedem Team waren je­weils zwei bis drei Schülerinnen und Schüler für die konkrete Umsetzung der drei ab­strakten Klassen zuständig. So konnten über zwanzig Schüler weitgehend unab­hängig von den anderen arbeiten.

svn_mvc_bluej1

Am Schluss sah das Projekt so aus, alle drei Model-, View- und Controller-Implementierungen konnten untereinander ausgetauscht werden:

svn_mvc_bluej2

Größeres Programmierprojekt

Danach folgten acht Wochen Programmierprojekt in drei Gruppen zu jeweils 7-8 Mit­gliedern. Jede Gruppe arbeitete in einem eigenen BlueJ-Projekt.

svn_team_alpha

svn_team_bravo

svn_team_charlie


Nachtrag: Für kommende Versionen von BlueJ ist Git-Unterstützung angekündigt; Git ist ein etwas jüngeres System, das ähnliche Wünsche wie Subversion erfüllt. Für Mebis ist, wenn auch nicht in unmittelbarer Zukunft, FTP-Zugang angekündigt und die Möglichkeit, gemeinsam an Dokumenten zu arbeiten, „mit Versionskontrolle“. Ich kann mir nicht vorstellen, dass das Versionskontrolle im Sinn von Git oder Subversion ist – aber das wäre schon schön.

9 thoughts on “Subversion mit BlueJ, die Fortsetzung

  1. Aginor

    Bei SVN bin ich purist. Nach schlechten Erfahrungen mit den SVN-clients bzw. -plugins von verschiedenen Programmen gibt es bei mir unter Windows nur noch Tortoise. Es funktioniert nicht ideal (die Windows-Version zerstört z.B. zuweilen die Dateirechte von Linux-Programmen), aber ziemlich gut. Selbst Anfänger kommen IMHO damit relativ gut zurecht. Das eingebaute diff ist z.B. relativ gut. Nur wenn was schiefgeht, dann muss jemand hin der versteht wie SVN funktioniert. Aber sehr sehr oft gilt die Methode aus dem XKCD-Comic. Die tut einfach. :)
    Was auch klasse ist sind die automatischen Funktionen, die z.B. Versionsnummern und den Nutzer der den Code zuletzt eingecheckt hat in einen Kommentar im File einfügen ($VERSION$ und so weiter).

    Git ist genauso gut, aber da finde ich die Installation des Servers etwas aufwendiger. Bei svn ist das kinderleicht (zumindest auf Linux, auf Windows habe ich das noch nicht gemacht). Da ist halt das öffentliche Arbeiten toll. Github FTW!

    Achja, und natürlich deswegen:
    http://i.imgur.com/3POtveC.jpg

    Insgesamt kann ich Versionskontrollsysteme nur empfehlen. Was habe ich früher Dateien verloren, überschrieben etc…. Seit SVN kein Problem mehr. Backups des Server halt nicht vergessen und gut is.

  2. Michael Brenner

    Toll! Bin beeindruckt. Und gut zu hören, dass es bei den Schülern gut ankommt. Wenn man früh erkennt, welche Sicherheit (und dadurch Freiheit auszuprobieren) so ein Versionskontrollsystem bringt, dann ist das super. Und git ist da wahrscheinlich noch besser, weil man auch lokal und individuell zum häufigen Commiten ermutigt wird. (Aber eigene Erfahrung habe ich damit peinlicherweise nicht. Seit Jahren nehme ich’s mir vor…)

    Und den brandaktuellen XKCD hast du natürlich auch gleich eingebaut…

    Abgesehen von Subversion gefällt mir auch sehr gut die Idee, die Interfaces bzw. abstrakten Klassen so zu definieren, dass der Code der einzelnen Gruppen austauschbar wurde. (Wie immer bin ich beeindruckt, wie anspruchsvoll das bei euch in Bayern zugeht!)

  3. Herr Rau Post author

    Tortoise ist äußerst praktisch. Für die Schule ist es aber ein dickes Plus, dass die Entwicklungsumgebung BlueJ einen eingebauten Client hat, auch wenn er schmächtig ist.

    >Das eingebaute diff ist z.B. relativ gut.

    Mich tät mal interessieren, wie dieses diff eigentlich funktioniert. Und wie gut. Mir ist noch nicht klar, welche Konflikte SVN selber lösen kann und welche nicht.

    >Abgesehen von Subversion gefällt mir auch sehr gut die Idee, die Interfaces bzw. abstrakten Klassen so zu definieren, dass der Code der einzelnen Gruppen austauschbar wurde

    Ja, das war schöner, als ich zuvor gedacht hatte.

    (Den xkcd habe ich sogar nachträglich eingebaut, ein paar Minuten nach dem Eintrag traf der Cartoon im Feedreader ein und passte genau.)

  4. Aginor

    Zum Diffen in Tortoise:

    Grundsätzlich kann man jede nicht-binäre Datei diffen.
    Im Fall eines zu diffenden Word-Dokuments ruft Tortoise einfach Word auf (denn Word kann diffen), alle anderen Textformate, die ASCII, UTF8 oder so sind, werden intern geöffnet. Optionen dabei:

    – vergleichen meiner geänderten Version (working copy) mit der von mir zuletzt heruntergeladenen
    – vergleichen meiner geänderten Version mit einer beliebigen Revision oder der head revision
    – vergleichen von zwei Revisions

    Wenn man dann difft dann hat man die Wahl zwischen einem „unified diff“ mit durchgestrichenen Zeilen des alten Dokuments und den eingefügten farblich hervorgehoben, oder einem side-by-side diff.

    Man kann dann jeweils durch anklicken einer Schaltfläche (oder rechtsklick IIRC) entscheiden, welchen Block man übernehmen will. Das System erkennt eingefügte Leerzeilen und fügt diese in der Ansicht hinzu, sodass die Dokumente schön parallel laufen.

    Grundsätzlich funktioniert das mergen automatisch, ohne dass der User diffen muss, mit folgenden Einschränkungen:
    – Änderungen in der selben Zeile. Das System kann nicht entscheiden was richtig ist. Dabei ist in der Praxis dann die XKCD-Methode oft dem diffen vorzuziehen.
    – Änderungen in unterschiedlichen Zeilen, die selbe Sache betreffend. Beispiel: Zwei auskommentierte Zeilen oder Blöcke. User A entfernt die Kommentare im ersten Block, User B die Kommentare im zweiten Block. Beide Committen. Das merged ohne Fehlermeldung in Tortoise, aber der Code läuft später nicht (oder falsch). Trotzdem hilft das Diff hier weiter, denn man kann schön sehen welcher User was comitted hat, und was die Änderungen in diesen Revisionen waren. Stichwort ist die Revision history des einzelnen Files.

    Mein Tipp fürs diffen: einfach mal ein simples Beispiel einer Textdatei nehmen und solche Fälle durchspielen, danach versteht man die Einschränkungen und Stärken.

    Achja, zu den Fallen noch, in die man tappen kann: Umbenennen von Dateien. NIE NIE NIE einfach so umbenennen im Dateisystem. Das führt zu lustigen Dingen wie dass die Datei mit dem Originalnamen beim nächsten Update zusätzlich zu der umbenannten erscheint. Umbenennen nur über das Kontextmenü von Tortoise, dann klappt das.
    Ist wie beim Löschen (sogar genauso, denn umbenennen IST löschen), ständig gibt es Wiedergänger wenn man nicht aufpasst.

    Was ich über SVN quasi gar nicht weiss ist wie das branchen funktioniert. Das vermeide ich wo es nur geht. Es gibt nur einen funktionierenden branch, sich in unterschiedliche, miteinander inkompatible Richtungen zu entwickeln sollte meines Erachtens nicht im SVN stattfinden. Das macht nur Ärger. (evtl. bin ich aber einfach zu konservativ, also wenn jemand eine gute Erklärung findet oder geben will, her damit!)

    Was noch interessant ist bei SVN: Externals. Ist jetzt zu lang zum schnell mal in einem Kommentar erklären, aber sehr mächtig. Hier zwei Links:
    https://blog.kowalczyk.info/article/q8/Short-tutorial-on-svn-propset-for-svnexternals-p.html
    http://tortoisesvn.net/docs/release/TortoiseSVN_de/tsvn-dug-externals.html

  5. Herr Rau Post author

    Danke für die ausführlichen Erklärungen. Externals wären eigentlich toll, genau so etwas habe ich gesucht – aber nachdem ich in der Schule nur mit BlueJ arbeiten kann, das das nicht kann, werde ich leider auch zu Hause darauf verzichten. Branches nutze ich auch gar nicht.

    Das mit dem Diffen müsste ich tatsächlich mal gründlich ausprobieren. Weihnachtsferien vielleicht.

  6. Marco Schanzer

    Hallo,

    ich wollte heute mit meinen Schülern für ein Zwischenprojekt BlueJ mit svn schon mal ausprobieren und hab dann feststellen müssen, dass mein BlueJ in der Schule keine Verbindung zum svn Server aufbauen kann. Wenn ich die Verbindung testen möchte, kommt der Wartebildschirm und dann fährt die Fortschrittsleiste hin und her und es passiert sonst nichts mehr. Zuhause funktionierts ohne Probleme. Haben Sie in der Hinsicht Erfahrungen gemacht? Leider kann ich BlueJ auch nicht als Administrator starten, weil dann BlueJ gar nicht startet.
    Vielen Dank schonmal für Ihre Antwort.

  7. Herr Rau Post author

    Das trat bei mir in der Schule früher auch auf, und noch heute gibt es einen Rechner im Computerraum, bei dem es nicht geht. Ich weiß nicht woran, es liegt, aber ich würde ausprobieren: Ist in der Schule die Version 3.1.7 installiert? Frühere Versionen haben leider immer wieder mal verschiedene Bugs. Zur Not würde ich eine portable Version von BlueJ 3.17 in die Schule mitnehmen und es mit der versuchen. Außerdem kann es an den Windows-Firewall-Einstellungen liegen, dass ein Admin zum Beispiel fast allen Anwendungen verboten hat, Kontakt ins Internet aufzunehmen. Das ist bei uns teilweise der Fall, allerdings nur bei https- und anderen Kontakten innerhalb unseres Netzwerks, also zu einem anderen Rechner; ins Internet kommt BlueJ problemlos.

    Um herauszufinden, ob es an BlueJ liegt, könnte man auch einen externen portablen SVN-Client installieren, da gab es zumindest mal ein paar zum Ausoprobieren.

  8. Marco Schanzer

    So, mit BlueJ 3.17 hats funktioniert. Ich hab die portable-Version zur Verfügung gestellt und nach etwas hin und her ist es dann doch gegangen. Vielen Dank für die Hinweise.
    Im Übrigen, seit zwei Wochen gibts BlueJ 4, u.a. mit Git-Unterstützung.

  9. Herr Rau Post author

    Schön! BlueJ und Git: Ja, irgendwann werde ich umsteigen müssen. Allerdings muss ich pro BlueJ-Projekt immer ein eigenes Git-Projekt erstellen, während eines meiner Subversion-Projekte manchmal zwei Dutzend BlueJ-Projekte enthält, deswegen scheue ich das noch.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.