3. versions- und konfigurationsmanagement inkrementelle...
TRANSCRIPT
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 47
3. Versions- und Konfigurationsmanagement
• Inkrementelle Entwicklungsschritte• Varianten der Versionskontrolle• Repository• Typischer Arbeitszyklus• Auflösung von Konflikten
Literatur:• [CFP07] B. Collins-Sussman, B. W. Fitzpatrick, C. M .
Pilato, Version Control with Subversion, [als PDF von Subversion-Webseite frei verfügbar]
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 48
Typischer Weg der Software-Entwicklung
Programmstück kodieren
Aufgabenteil auswählen
Programmstück testen
Korrektur-versuch
Einbau/Nutzung von Debuginformationen
kleine Lösungsvariante
große Lösungsvarianteläuft
nicht fertigfertig
kleiner Fehler
Fehlerunklar
kleine Überar-beitung
Umstruk-turierung
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 49
Software-Versionen
• Software entwickelt sich inkrementell, bei Versuchen muss der Weg zurück möglich sein
• Versionsbaum
Paket 1
V 1
V 2
V 3
V 4
V 5
Paket 2
V 1
V 2
V 3
V 4
V 5
V 6
Paket 3
V 1
V 2
V 3V 4
V 5V 6
V 7
Inkrement 1
Inkrement 2
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 50
Verwaltung von Software
• Die gemeinsame Entwicklung von Software hat u. a. folgende Aufgaben zu lösen:– wie kann ein Entwickler seine eigene
Softwareentwicklung koordinieren– wie bekommen andere Entwickler mit, was der
aktuelle Entwicklungsstand ist– wie wird aus den einzelnen Dateien effizient das
lauffähige System kompiliert
• Die ersten beiden Fragen beantwortet ein Versionskontrollsystem
• die letzte Frage fordert die Erweiterung zum Softwarekonfigurationsmanagementsystem (-> Ant)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 51
Versionskontrolle: konservative Variante
• Dateien werden zentral im Repository verwaltet• Entwickler checkt zu ändernde Software aus• Entwickler erhält damit lokale Kopie zur Bearbeitung• Während der Entwickler an der Software arbeitet, kann n iemand
anderes diese Software bearbeiten (erhält die Situatio n klärenden Hinweis)
• Entwickler checkt lokale Kopie (mit Änderungsverweis) wieder ein; jeder kann diese Kopie zur erneuten Bearbeitung auschecken
• Vorteil: garantiert nur ein Bearbeiter• Nachteile: keine gleichzeitige Arbeit an unterschiedl ichen
Programmstellen, wartende Entwickler, vergessenes Einchecken
• Realisierung von Repository sehr unterschiedlich lösba r (Datenbanksystem, Aufsatz auf Filesystem)
• Hinweis: Generell sollte das Einchecken mit einer Prüf ung verbunden sein
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 52
Versionskontrolle: progressive/chaotische Variante
• Dateien werden zentral im Repository verwaltet• Entwickler checkt zu ändernde Software aus• Entwickler erhält damit lokale Kopie zur Bearbeitung• andere Entwickler können gleichen Programmcode
auschecken• erst beim Einchecken wird geprüft, ob seit dem Ausche cken
zwischenzeitliche neue Version eingecheckt wurde, wen n ja, passiert Versionsabgleich, Konflikt muss gelöst werde n
• Vorteil: massive parallele Arbeit wird möglich, kein Ausbremsen anderer Entwickler
• Nachteil: Chaos bei häufig veränderten Ressourcen
• Lösung: für selten genutzte Dateien progressiver, für s ehr kritische oder häufig genutzte Dateien konservativer An satz
• bisher Open Source: progressiv, kommerziell: konservativ
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 53
Übungsaufgabe
• Ein klassisches Problem der Versionierung ist der Fall, dass ein Entwickler X alleine bearbeitet, ein anderer Entwickler Y alleine bearbeitet und beide (ohne Probleme) ihre Änderungen einchecken.Das alte Programm lief ohne Probleme, die neue Variante läuft nicht, da gegenseitige Abhängigkeite n nicht berücksichtigt worden.Schreiben Sie ein einfaches lauffähige Programm mit den Klassen A und B. Überlegen Sie sich Änderungen von A nach A‘ und von B nach B‘, so dass A‘ mit B und A mit B‘ ohne Probleme laufen, A‘mit B‘ zusammen aber nicht läuft.
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 54
Arc
hite
ktur
von
Sub
vers
ion
[CF
P07
]
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 55
Repository anlegen
• Hinweis: Sie werden bei der Arbeit mit Subversion typischerweise nur sehr wenige Befehle benötigen, hie r werden weitere Befehle vorgestellt, die das Üben auf dem eig enen Rechner ermöglichen. Dabei immer das lesenswerte freie B uch [CFP07] beachten
• Hinweis: Anlegen passiert durch zentralen Administra tor (FH-Regelung im Praktikum)
• G:\> svnadmin create /svnrepos
• hier wird u. a. eine Datenbank angelegt, diesen Ordner n ie von Hand bearbeiten
• svnadmin ist Administrationswerkzeug und wird von einfachen Nutzern nie genutzt
• Repository in Ordnerstruktur organisiert, diese Ordner werd en vom Nutzer selbst angelegt
• Man beachte, dass immer / genutzt werden muss
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 56
Einspielen der Daten
• Es werden lokale Daten in das Repository eingespielt• Zentrale Versionsmanagementaufgabe: Sinnvolle Datei struktur
für das Projekt anzulegen• Typischerweise werden generierbare Dateien (*.class) ni cht
unter Versionskontrolle genommen, evtl. sinnvoll, fer tige Releases vollständig einzuchecken (mit Executable), dieses aber nicht veränderbar
• Daten vor dem Einspielen in eine sinnvolle Repositor y-Strukturbringen
• G:\>svn import g:/antspiel/srcfile:///g:/svnrepos/MVC/source -m:"Ausgangsdaten"
• file steht für lokales Verzeichnis, hier normalerweise URL– http://svn.example.com:9834/repos
– file://localhost/svnrepos
– file:///g:/svnrepos oder "file:///g|/svnrepos"
• Hinweis: import Befehl wird nur einmal für Daten genut zt, danach zum Ändern immer die folgenden Befehle nutzen
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 57
Auschecken der Daten• Ansatz: Daten werden immer aus Repository in lokalen Ordner
kopiertG:\arbeit>svn checkout
file:///g:/svnrepos/MVC/source quelleA quelle/deA quelle/de/kleukerA quelle/de/kleuker/XView.javaA quelle/de/kleuker/XModel.javaA quelle/de/kleuker/XController.javaA quelle/de/kleuker/XStarter.javaA quelle/de/kleuker/XModelListener.javaAusgecheckt, Revision 1.G:\arbeit>dir quelle10.02.2007 17:28 <DIR> .10.02.2007 17:28 <DIR> ..10.02.2007 17:28 <DIR> .svn10.02.2007 17:28 <DIR> de
• .svn ist zentrales Verwaltungsverzeichnis zum Erkennen von Änderungen (verwaltet u. a. den Stand beim Auschecke n)
• Danach ist lokale Bearbeitung der Dateien möglich
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 58
Einchecken der Daten
• ausgecheckte Dateien beliebig veränderbar• löschen, kopieren und verschieben, an Subversion melde n• Mit commit können ganze Verzeichnisse eingecheckt werden,
man kann aber auch Dateien angeben (nur Neues wird ko piert), z. B. (ohne –mmit Kommentar oder –f File nicht ausführbar)G:\arbeit\quelle\de\kleuker>svn commit XView.java
-m"Groesse angepasst"Sende XView.javaübertrage Daten .Revision 2 übertragen.G:\arbeit\quelle\de\kleuker>svn commit -m"Groesse
450"Sende kleuker/XView.javaübertrage Daten .Revision 3 übertragen.
• Bei Problemen wird das Einchecken nicht durchgeführt• Einchecken ist atomar (ganz oder gar nicht)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 59
Datenunterschiede erkennen
• diff-Befehl zeigt zeilenweise Unterschiede (bei eigen er Arbeit, aber auch zwischen zwei Dateien), hier XStarter.java be arbeitetG:\arbeit\quelle\de\kleuker>svn diff XStarter.javaIndex: XStarter.java==================================================--- XStarter.java (Revision 8)+++ XStarter.java (Arbeitskopie)@@ -3,9 +3,9 @@
public class XStarter {public static void main(String[] args) {
- XModel x= new XModel();- new XView(x);- new XController(x);+ XModel xmodel= new XModel();+ new XView(xmodel);+ new XController(xmodel);
}}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 60
Konfliktbearbeitung (1/5)
• Annahme: wir bearbeiten XStarter.java, diese Datei wurd e nach uns von anderem Entwickler zwischenzeitlich eingechec ktG:\arbeit\quelle\de\kleuker>svn commit
XStarter.java -m"Variablennamen angepasst"Sende XStarter.javasvn: übertragen fehlgeschlagen (Details folgen):svn: Out of date:
'/MVC/source/de/kleuker/XStarter.java' in transaction '6'
• Lösungsansatz: Zunächst eigene Dateien aktualisierenG:\arbeit\quelle\de\kleuker>svn updateG XStarter.javaAktualisiert zu Revision 5.
• U: selbst nicht bearbeitet, aber neue Version im Reposi tory• G: lokal und im Repository bearbeitet, von Subversion gelöst
(merGe) [???!!!]• C: selbst bearbeitet und im Repository bearbeitet, Sub version
hat keinen Lösungsvorschlag
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 61
Konfliktbearbeitung (2/5)
• merGe muss kontrolliert werden (Änderungen an unterschiedlichen Stellen)
• hier Ergebnis (überlegen Sie, was anderer Implementierer gemacht hat): public class XStarter {
public static void main(String[] args) {
XModel xmodel= new XModel();
new XView(xmodel);
new XController(xmodel);
new XView(x); // zweiter View
new XController(x); // zweiter Controller
}
}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 62
Konfliktbearbeitung (3/5)
• Bei erkanntem Konflikt auf Datei XStarter.java werden b ei update folgende Dateien angelegtG:\arbeit\quelle\de\kleuker>svn updateC XStarter.javaAktualisiert zu Revision 11.G:\arbeit\quelle\de\kleuker>dir XStarter.*11.02.2007 10:01 504 XStarter.java11.02.2007 10:01 306 XStarter.java.mine11.02.2007 10:01 296 XStarter.java.r1011.02.2007 10:01 313 XStarter.java.r11
• .java.mine : unsere aktuelle Variante (falls .java verändert)• .r<alt> : Version beim Auschecken• .r<neu> : aktuelle Version aus dem Repository • .java : unsere Datei mit Konfliktmarkierungen (wenn
Subversion Überarbeitung für möglich hält)• Nutzer muss dann von Hand die wünschenswerte Lösung
komponieren (diff ist hilfreich)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 63
Konfliktbearbeitung (4/5)
• Beispiel für Konfliktbeschreibung in Dateipackage de.kleuker;public class XStarter {
public static void main(String[] args) {XModel xmodel= new XModel();
<<<<<<< .minenew XView(xmodel);new XController(xmodel);new XView(xmodel);new XController(xmodel);
=======XView[] views= {new XView(xmodel),
new XView(xmodel)};new XController(xmodel);for(int i=0;i<2;i++)
views[i].setLocation(0+i*500,0);>>>>>>> .r11
}}
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 64
Konfliktbearbeitung (5/5)
• Nutzer überarbeitet Konflikt• eine Variante: eigene Änderungen zurückziehen
(lokale Dateien automatisch gelöscht)svn revert XStarter.java
• Konfliktlösung muss Subversion mitgeteilt werden (lokale Dateien automatisch gelöscht)svn resolved XStarter.java
• ohne Meldung der Lösung kann keine commiterfolgreich sein (theoretisch neues Problem möglich , falls zwischenzeitlich erneut neue Version eingespielt)
• Generell gilt, dass häufig auftretende Konflikte au f eine mangelnde Projektorganisation oder Kommunikation hindeuten
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 65
History-Informationen
• svn log-------------------------------------------------r4 | Administrator | 2007-02-11 09:59:52 +0100 (Sun, 11 Feb 2007) | 1 lineArrayStrukur-------------------------------------------------r3 | Administrator | 2007-02-10 19:12:26 +0100 (Sat, 10 Feb 2007) | 1 lineVariablennamen angepasst-------------------------------------------------r2 | Administrator | 2007-02-10 17:50:30 +0100 (Sat, 10 Feb 2007) | 1 linezwei Models und Views-------------------------------------------------r1 | Administrator | 2007-02-10 17:40:28 +0100 (Sat, 10 Feb 2007) | 1 lineAusgangsdaten-------------------------------------------------
• Möglichkeit, bestimmte Releases anzusehen: svn log –r 4:3
• Möglichkeit History einer Datei anzusehen (nur Release s mit Änderung angezeigt) : svn log XModel.java
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 66
Arbeit mit alten Versionen
• man kann aktuellen Stand mit Revisionen vergleichensvn diff –r3 XStarter.java
• man kann zwei Revisionen vergleichensvn diff –r2:3 XStarter.java
• man kann sich alten Stand ansehen (evtl. umlenken)svn cat –r2 XStarter.javasvn cat –r2 XStarter.java > analysedatei
• Inhalt des Repository ansehen (-v verbose häufiger nut zbar)G:\arbeit\quelle\de\kleuker>svn list -v
file:///g:/svnrepos/MVC/source/de/kleuker1 Administ 1566 Feb 10 17:16 XController.java1 Administ 1186 Feb 10 17:16 XModel.java1 Administ 90 Feb 10 17:16 XModelListener.java
11 Administ 313 Feb 11 09:59 XStarter.java4 Administ 1223 Feb 10 17:40 XView.java
• Auschecken einer alten Revisionsnummer (richtigen Ort beachten, danach normal mit commit und update bearbeit bar)svn checkout file:///g:/svnrepos/MVC/source/de -r3
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 67
Versionsnummern
• Versionsnummern einzelner Dateien werden bei commithochgezählt
• Subversion nutzt Versionsnummern für vollständige Bäume , bedeutet, dass Revisionsnummer für alle Dateien (auch nicht geänderte) hochgezählt wird (anders in anderen Versionsmanagementwerkzeugen)
• mit Abfrage der History feststellbar, ob Datei überhaupt in der Version geändert wurde
• Statusabfrage zeigt aktuelle Versionsnummer und in wel cher Version letzte Änderung (formal alle in Version 19)G:\arbeit\quelle\de\kleuker>svn status -v11 11 Administrator .11 4 Administrator XView.java19 19 Administrator doku19 19 Administrator doku/comment.txt11 1 Administrator XModel.java11 1 Administrator XController.java11 11 Administrator XStarter.java11 1 Administrator XModelListener.java
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 68
Status abfragen
• Vor commit oder update immer sinnvoll, den aktuellen Arbeitsstatus abzufragen, gibt Informationen welche Änderungen durchgeführt wurden
Nicht versioniert, aber als extern gekennzeichnetX
Nicht unter Versionskontrolle, Ignorieren vereinbartI
Typ in Repository und Arbeitsbereich passt nicht~
Unter Versionskontrolle, fehlt aber (irrtümlich gelöscht )!
Befindet sich nicht unter Versionskontrolle (kein Prob lem)?
Soll ersetzt werden (gleicher Name, neuer Inhalt, replac e)R
Inhalt wurde verändert (modify)M
Soll gelöscht werden (delete)D
Steht in einem Konflikt, muss vor commit gelöst werdenC
Soll hinzugefügt werden (add)A
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 69
Arbeiten an der Dateistruktur
• Werden Dateistrukturen geändert, so muss dies Subversio n mitgeteilt werden, da Dateien sonst nicht unter Versionsverwaltung (Änderungen erst nach commit)
• Hinzufügen einer Datei oder eines Verzeichnisses (Verz eichnis automatisch rekursiv absteigend, ausschalten mit --non-recursive ), Daten müssen vorher existierensvn add neueDatei
• Löschen einer Datei oder eines Verzeichnissessvn delete wegDamit
• Kopieren einer Datei /eines Verzeichnisses (kein *)svn copy quelldatei zieldatei
• Verschieben einer Datei/ eines Vezeichnisses (kein *)svn move quelldatei neuerQuelldateiname
• Verzeichnis anlegensvn mkdir verzeichnis
• (einige Befehle direkt auf Repository anwendbar)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 70
Locking• Setzen eines Locks (aktuell nur für Dateien möglich! )
svn lock XStarter.java -m "Namen anpassen"»XStarter.java« gesperrt durch »Administrator«.[anderer Nutzer] svn lock XStarter.javasvn: warnung: Pfad
»/MVC/source/src/de/kleuker/XStarter.java« ist bereits durch Benutzer »Administrator« im Dateisystem »g:/svnrepos/db« gesperrt
• Aufheben eines Locks, entweder mit commit (für alle Dateien eines angegebenen Verzeichnisses) odersvn unlock XStarter.java
• Erkennen eines Locks (z. B.)svn -v status --show-updates
K 3 3 Administrator XStarter.java• Neben dem Administrator kann jeder auch ein Lock lösch en
oder sogar stehlen (schlechter Projektstil)svn lock XStarter.java --force -m "Namen anpassen"
• evtl. aufräumen: svn cleanup (z. B. Problem, wenn ein Nutzer mehrmals gleiche Dateien auscheckt)
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 71
Nutzung von Properties
• Dateien und Verzeichnisse können Properties(Eigenschaften) als Paare Eigenschaftsname und Wert zugeordnet werden
• Properties stehen unter Versionskontrolle• Es gibt Systemproperties (eigene dürfen deshalb
nicht mit svn: beginnen• Setzen (und ändern) von Properties
svn propset lizenz 'free' XModel.java
• Lesen von Propertiessvn propget lizenz XModel.javasvn proplist -v XModel.java
• Löschen von Propertiessvn propdel lizenz XModel.java
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 72
Dateien ignorieren
• Generierte Dateien werden typischerweise nicht unter Versionskontrolle genommen, diese und „Hilfsdateien“ w ie ~*, können aus der Verwaltung ausgeschlossen werden
• es gibt zentrale Möglichkeit für Repository (haben wi r nicht)• Einstellung über Properties für Verzeichnisse (nicht ab steigend
gesetzt) svn propset svn:ignore -F ignore.txt kleuker
• ignore.txt ist Datei mit folgendem Inhalt: (Zeilenumbrüche beachten)
• Wenn doch alles gezeigt werden sollsvn status --no-ignore
? ignore.txt
I bla.class
I x.jar
*.class*.jar
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 73
Verzweigungen
• In großen Projekten möchte man häufig auf einem stab ilen Stand eigene Experimente machen
• Typisch ist die Möglichkeit, Branches (Verzweigungen) ab einer bestimmten Version anzulegen (nicht Subversion)
• Subversion-Ansatz: Arbeitsversion als Kopie in Subversi on erstellen (diese später synchronisieren und löschen)
• Direktes Kopieren auf Repository ist möglichsvn copy file:///svnrepos/MVC/sourcefile:///g:/svnrepos/MVC/branch -m"lokaler Branch"
svn list -v file:///svnrepos/MVC
23 Administ Feb 11 15:09 branch/
22 Administ Feb 11 15:06 source/
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 74
Zusammenfassung: Typische Arbeitsschritte
• Am Anfang auschecken (einmal) oder aktualisierencheckout update
• evtl. Dateien erzeugen, löschen, verschiebenadd delete copy remove
• Änderungen analysierenstatus diff revert
• Änderungen durchführencommit
• Konflikte lösenupdate resolved
• Man beachte: Lokale Arbeitskopien können einfach gelöscht werden, dann neue Version auschecken
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 75
Weitere Konfigurationsmanagementaufgaben
• generell: Verwaltung aller Projektergebnisse, neben Que llcodes– Dokumentation– Arbeitsplatzstruktur (Dateistruktur des Projekts)– Sicherung der benutzen Arbeitsumgebung, z. B.
• Kopie des verwendeten Betriebssystems• Kopie des verwendeten Compilers• Kopie der verwendeten Software-
Entwicklungsumgebung– eventuell alles mit Versionsnummer (z. B. bei
Compilerwechsel)• Erstellung von Sicherungskopien (wenn Server abbrennt,
müssen fast aktuelle Arbeitsergebnisse erhalten bleibe n; gibt Internetlösungen)
• muss jederzeit in der Lage sein, jedes Release in ku rzer Zeit wieder herzustellen
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 76
Subversion und Eclipse = Subversive
• Subversion gut in Eclipse integriert
• Ansatz: Eclipseprojekt erstellen und dann in den Projektbaum in Subversion (nicht oberste Ebene) einbauen
• Generell dann Subversion-Nutzung bei Programmierung nur aus Eclipse heraus
• Shell, z. B. für Befehl svn status, zum Schauen ist erlaubt
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 77
Subversionverbindung in Eclipse
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 78
Windows-Explorer+Subversion=TortoiseSVN
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 79
Übung (1/2) [Angaben für UNIX anpassen]
1. Neben dem eigentlichen Projekt-Repository, das Sie „nur“nutzen können, haben Sie die Möglichkeit, eigene Re positoriesanzulegen. Legen Sie zum Üben ein Repository unter z:/svnrepos an und spielen Sie ein Java-Projekt, genau er die *.java-Dateien, ein.
2. Gehen Sie in ein anderes Verzeichnis, z. B. z:/tmp/s vn1 und checken Sie das Projekt aus, probieren Sie die Befehl e status, diff, commit und revert mehrfach mit kleinen Dateiänderun gen aus.
3. Öffnen Sie eine zweite DOS-Box (cmd), gehen Sie in ein zweites Verzeichnis, z. B. /tmp/svn2 und checken Sie das Projekt aus. Ändern Sie in beiden DOS-Boxen eine Date i und versuchen Sie sie einzuchecken, nutzen Sie die Befeh le status, update und resolved. Erzeugen Sie einmal eine Situation, in der Subversion die Dateien automatisch mergedund eine Situation, in der Sie den Konflikt von Hand lösen müssen.
Prof. Dr. Stephan KleukerSoftware-Engineering Projekt 80
Übung (2/2)
4. Experimentieren Sie mit den Befehlen add, delete, c opy.5. Stellen Sie in einem Verzeichnis sicher, dass Date ien mit der
Endung tmp nicht von Subversion verwaltet werden und prüfen Sie den Erfolg.
6. Setzen Sie und verändern Sie Eigenschaften (Propert ies) einer Datei. Was passiert, wenn zwei Nutzer unterschiedlich e Änderungen machen?
7. Erzeugen Sie in Eclipse ein neues Java-Projekt und spielen Sie (nicht-versionierte) Dateien ein. Stellen Sie das Projekt unter Versionskontrolle und wiederholen Sie die Befehl e ab Aufgabe 2 erneut (Sie müssen allerdings nicht erneut auschecken.)
8. Ergänzen Sie in Ihrem Repository ein neues Projekt von Eclipse aus. Ändern Sie eine Datei in Eclipse und au ßerhalb von Eclipse, checken Sie in Eclipse ein.
9. [Windows: Beschäftigen Sie sich mit den Nutzungsmöglichkeiten von TortoiseSVN]