Eclipse und Java Einheit 05: Arbeiten im Team: CVS Laith Raed Ludwig-Maximilians-Universität München Institut für Informatik: Programmierung und Softwaretechnik Prof.Wirsing
Inhaltsverzeichnis 1 Source Controll Software Motivation und Definition von Source Controll Software Bekannte frei verfügbare Source Controll Softwares Eclipse und Source Control Software 2 Einführung in CVS unter Eclipse CVS Grundlage Installation und Einrichtung von CVS in Eclipse Arbeiten mit CVS in Eclipse 3 Einführung in Subversion (SVN) unter Eclipse CVS vs. SVN Installation und Einrichtung von SVN Arbeiten mit SVN unter Eclipse
Motivation zur Entwicklung von Source Controll Software Teamarbeit braucht Koordination (Diskussionen, Planung) Konflikte sind bei der besten Koordination unvermeidlich Neue Codeversion darf die alte nicht überschreiben Manuelle Verwaltung gemeinsames Projektes sehr aufwendig Source Control Software wurde entwickelt, um diese Probleme zu bewältigen
Source Controll Software Aufgaben Zugriff auf Sourcecode kontrollieren (Rechte verwalten) Änderungen an Code speichern, dokumentieren Code-History einführen: Codes vergleichen, umschalten Automatische Versionierung von Codes Parallele Projekt-Entwicklung durch Projektzweige (Branches) Source Control Software sind mächtige Tools, welche die Softwareentwicklung eines Projekts durch mehrere Personen(Team) möglich machen und massiv erleichtern.
Bekannte Source Controll Software Es gibt viele frei verfügbare Source Controll Softwares: CVS (Concurrent Versions System) SVN (Subversion) Bazzar Darcs Git Mercurial Monotone SVK Für mehr Informationen siehe: 1)http://en.wikipedia.org/wiki/Revision control 2)http://www.thefreecountry.com/programming/versioncontrol.shtml
Eclipse und Source Control Software Eclipse ist nicht nur für Solo-Programmierer geeignet Eclipse Entwicklungsumgebung unterstützt Teamarbeit Wichtige Source Control Software für Eclipse: CVS und SVN. CVS ist in Eclipse standardmäßig integriert (Window Open Perspective CVS Repository Exploring) SVN muss als Plugins in Eclipse hinzugefügt werden.
CVS Grundlage I: Geschichte CVS ist ein Open Source Projekt zur Versionsverwaltung und Speicherung von Codeänderungen. Begonnen 1986 als eine Menge von Unix Shell Scripts und seit 1989 als eigenständige Software Verfügbar für mehrere Betriebssysteme: Unix, Linux, Windows Unix, Linux Installationen haben built-in CVS Server Für Windows gibt es CVS Variante wie z.b CVSNT Für mehr Informationen über CVS: www.cvshome.org
CVS Grundlage II: Struktur Wurzelelement ist der Projektarchive (Repository) CVS Ordner präsentieren CVS-Module Ein CVS-Modul entspricht einem Eclipse-Projekt Physikalische Module entsprechen Standardprojekten Logische oder virtuelle Module sind Sammlungen von verwandten Resourcen.
Installation und Einrichtung von CVS in Eclipse 1 Schritt 1 Einen CVS Server installieren Unix, Linux haben CVS-Server als built-in Für Windows: downloade CVS Variante: www.cvsnt.org 2 Schritt 2 Einen CVS-Client installieren Eclipse hat einen integrierten CVS-Client Für Nicht-Eclipse Projekte: Totoisecvs (www.tortoisecvs.org) 3 Schritt 3 Verbindung CVS-Client Server aufbauen Window Open Perspective CVS Repository Exploring Rechter Mausklick in dem CVS Repositories View New Repository Location erscheint Add CVS Repository (Host, Repository path, User, Password,..) Verbindungsaufbau Einstellungen zu einem CVS-Server (von dem Adminstrator erhalten) eintragen, Finish anklicken
Arbeiten mit CVS in Eclipse Repository erstellen Verbindung zum CVS-Server herstellen Projekt zum CVS-Repository hinzufügen Projektdateien committing Projekt Checkout Code updaten Code Konflikte beseitigen Code einchecken (Committing Code) Code Synchronisieren Patch erzeugen Tagging Version Branches erzeugen
1) Repository erstellen Was ist Repository? Repository ist der Projektarchive und speichert eine komplette Kopie aller Dateien und Ordner, die unter die Versionkontrolle sind. Repository unter Unix erstellen Das Kommando: cvs -d path init eintippen path: ist der Ordner, der als Repository benutzt wird. Respoitory unter Windows erstellen Auch mit dem Kommand: cvs -d path init. ODER: In CVSNT controll panel Repository Configuration tab Add Button betätigen, path eintragen z.b C:/eclipsekurs OK anklicken
2) Verbindung zum CVS-Server herstellen Unter Unix oder Linux CVS:SSh(Secure Shell) oder pserver Protokoll benutzen Eins von den beiden, der auf die Maschine verfügbar ist Unter Windows CVSNT läuft als Service und ist für Eclipse direkt verfügbar In CVSNT controll panel About CVSNT Service und CVSNT Lock Service starten. CVS Repository in Eclipse einbinden Window Open Perspective CVS Repository Exlproing In CVS Repositories View rechter Mausklick New Repository Location Einstellungen eintragen OK.
3) Projekt zum CVS-Repository hinzufügen In Java Perspective wechseln Java Projekt erstellen Rechter Mausklick auf ein Projekt Team auswählen Share Projekt Select a repository type: CVS auswählen Next Use existing Repository Location ODER falls keine Repository: CVS auswählen Einstellung eintragen Use Project name as module name aktiveren Finish betätigen Für Eclipse Projekte muss die Datei.project immer ein (check in) und ausgecheckt (check out) Projektdateien committing
4) Projektdateien committing (check in) Projektdateien zur CVS-Repository in zwei Schritte schicken Datei Team Add to Version Controll Datei Team Commit Projektdateien zur CVS-Repository in einem Schritt schicken Projekt Team Commit Zur CVS Perspective wechseln: das Projekt ist als CVS Module da in dem Repsitory Head Section Beachte den CVS Ordner, der administrative Daten und andere Branches enthält.
5) Projekt einchecken (check out) Andere Programmierer wollen neue CVS Module auschecken Verbindung zum CVS-Server herstellen In die Repsitory View Projekct auswählen(modul) Rechter Mausklick Check Out As: a) a project configured using the New Project Wizart b) a project in the workspace Falls das CVS-Modul keine.proect hat, wähle Variante a Falls das CVS-Modul die Datei.proect hat, wähle Variante b Eine Kopie von dem Projekt (CVS-Modul) wird nun lokal auf der Festplatte jedes Entwicklerrechners gespeichert. Entwickler brauchen nur mit ihrer lokalen Kopie arbeiten und ihre Änderungen an den CVS-Server einchecken, damit alle diese Änderungen mitbekommen.
Code updaten Ein Programmierer P1 arbeitet an x.java x.java wird zu >x.java in Package Explorer View. > signalisiert Änderungen, die committed werden müssen >x.java Team Committ... x.java Version wird in der Repository um 1 erhöht Ein Programmierer P2 arbeitet an x.java P2 möchte alle Updates von x.java erfahren >x.java Team update Falls es keine Konflikte gibt, fügt CVS die Änderung von P1 in P2 Code ein, sonst erkennt CVS Konflikte Bei einem Konflikt muss der Programmierer den Konflikt manuell beseitigen
Konflikt beseitigen Ein Konflikt tritt ein, wenn zwei Programmierer P1, P2 die gleiche Datei gleichzeitig geändert haben P1 kommittet seinen Code, P2 updatet seinen Code Soll P2 den Code von P1 übernehmen, ändern, überschreiben? CVS erkennt Konflikte und listet bei update beide Versionen mit CVS Markup auf <<<<<<< Repository Code und Version >>>>>>> Lokaler Code und Version Mehr Infos: x.java Rechter Mausklick Team Show in Resource History (Zeigt commit für jede Code Version) Code mit local History vergleichen: x.java Compare With Local History (Graphische Darstellung der Änderung: Source/Local History) Konflikt manuell beseitigen: Version von P1 akzeptieren, erweitern, ersetzen.
Code einchecken (Committing Code) Goldenes Regel: erst updaten, mögliche Konflikte beseitigen, dann Code committen Commiting Code: x.java Team Commit... Kommentare schreiben: z.b. was ist die Änderung, wieso? Es gibt jedoch eine andere Methode, um den Code upzudaten: Synchronisation.
Code Synchronisieren Synchronisation ist sinnvoll, wenn die Änderung zwischen eigenem Code und Repository sehr groß ist Update ist ist sinnvoll, wenn die Änderung zwischen eigenem Code und Repository gering ist. Synchronization mit Repository vergleicht Änderungen in leichtern Format als update Projekt Team Synchronize with Repository Alle Dateien, die im Repository anders als in der lokalen Kopie, erscheinen mit einem roten Pfeil in Synchronization View
Code Synchronisieren: Fortsetzung Doppelklick auf eine Datei: Java Source Compare View erscheint: Workspace File(vers M)/Local History(vers N) Eine Linie verbindet Workspace File Fenster mit Local History Fenster. In der Mitte ist ein weises Box. Der Mauscursor auf das weise Box fixieren: Der weise Box wird zu einem linken Pfeil Linken Pfeil anklicken: Die Änderung werden in die Workspace File importiert. Nach der Synchonization sollte der Code committet werden.
Code Synchronisieren: Fortsetzung II In Synchronize View unterscheidet man 3 Modes: Incoming Mode: zeigt alle Repository Files, die seit der letzten Synchronisation, update oder commit geändert haben Outcoming Mode: zeigt alle workspace Files, die seit der letzten Synchronisation, update oder commit geändert haben Incoming/Outcoming Mode: zeigt alle Repository ODER Workspace Files, die seit der letzten Synchronisation, update oder commit geändert haben Bei öfteren Codeänderungen sollte man regelmäßig Synchonisation/Update durchführen
Patch erzeugen Ein Patch ist für Partner-Entwickler ohne CVS-Zugriff gedacht Programmierer P1 schickt z.b. den Partner-Entwicklern per Email Patch Files für seine Änderung, die sie in eclipse übernehmen können P1 ändert x.java, speichert es, ohne es zu kommitten. Patch erzeugen: x.java Team Create Patch Erezeugte Patch File an beliebiger Stelle speichern Finish Eclipse vergleicht loka Code mit Repository und erzeugt Path File, in dem die Änderungen mit + markiert sind. P1 schickt das patch File per E-mail zu anderen Entwicklern. Ein Partner-Entwickler wählt x.java in Eclipse Team Applay Patch Patch auswählen Die Version Nr von x.java in Eclipse bleibt erhalten, jedoch den x.java Source Code wird auf die Version von P1 upgedatet.
Tagging Version Milestone Versionen wie z.b. beta, Release müssen komplett als eine Einheit, die jeder Zeit wieder abrufbar und Verfügbar ist, gespeichert werden. Projekt auswählen Team Tag As Version Name geben Finish Das gesamte Projekt wird unter Repository Versions gepseichert. Braucht man irgendwann diese Version, muss man dann Check Out Projekt durchführen. Alternative: Projekt Replace With Base Revion/Latest from Repository/Branch/Tag... und die gewünschte Version wählen
Branches erzeugen Branchen ermöglichen parallele Entwicklung mehrerer Projektvarianten z.b.: Var1 hat Feautres A, B, C während Var2 hat nur A, B P1 hat sehr gute Idee, P2 andere gute Lösung. Beide erstellen ihre eigene Branch und arbeiten damit. Deadline nährt sich, keine Fehler mehr bauen: Testen nicht in Trunk/Head einschicken: Branch zum Testen erstellen. Branche erzeugen: Projekt Team Branch/Tag... Next Head revision in the repository: erstellt die letzte Version Specific revision in the repository: aus einem tagged Version Working Copy: aus der eigenen lokalen Projektkopie Anschließend muss man den Branch mit Check Out auf die lokale Maschine kopieren, und damit dann arbeiten.
SVN hat bessere Versionierung als CVS z.b. ermöglicht Benennung, und Verschiebung von Dateien CVS visioniert die Dateien unabhängig von dem Projekt-Version Nr, SVN in Abhängigkeit CVS speichert Änderung (Projektarchive, Ort, Zeit) während SVN (Projektarchive, Zeit, Ort) SVN ist mächtiger und besser als CVS
SVN Server installieren: www.subversion.tigris.org Repository einstellen. In Eclipse SVN als Plugin (subclipse) hinzufügen: Eclipse Software Updates... Add Site... http://subclipse.tigris.org/update 1.6.x OK Der neue Seiteneintrag auswählen: alles markieren Install... klicken Projekt zum Repository hinzufügen und damit wie in CVS arbeiten.
Ist wie bei CVS