Quellcodeverwaltung mit TortoiseSVN ist ganz einfach.
Andere Quellcodeverwaltungssysteme gehen ebenfalls einfach, lediglich der TFS (Team Foundation Server) von Microsoft ist bei der Installation eher eine Wissenschaft.
Was ist Quellcodeverwaltung?
Quellcodeverwaltung speichert alle Änderungen zu einem vorherigen Zustand bzw. zu einem Initialzustand, so dass jede dieser Änderungen schrittweise abgerufen und visualisiert werden kann.
Dadurch ist der Speicherverbrauch minimal.
So lassen sich die Unterschiede einer Datei von Version 123 (z.B. vorgestern) zu Version 89 (z.B. vor 2 Wochen) anzeigen, während wir mittlerweile bei Version 135 sind.
Wird ein Release erstellt, sollte diese Version in der Quellcodeverwaltung "ge-tagt" werden, so dass immer klar ist, welcher Code zur Version 1.2.3.4 gehört.
Soll mal etwas ausprobiert werden, was nicht unbedingt in die nächste Release gehört, aber elementarer Bestandteil des Projekts ist, wird ein "Branch" angelegt. In diesem Zweig kann dann nach Bedarf weiter entwickelt und gespeichert werden.
Wenn klar ist, was davon für das Produkt benötigt wird, werden die betreffenden Quellen vom Branch in den Hauptzweig zurückgeführt. Anm.: Dies tue ich selber im Studio und nicht in der Quellcodeverwaltung.
Wie auch immer.
Die Quellcodeverwaltung ist ein wichtiges und mächtiges Tool, um Quellen vor der Vernichtung zu schützen und Versionen als solche zu bewahren.
Folgende Bestandteile müssen vorhanden sein bzw. installiert werden:
Nachdem einige Fragen zur Quellen-Herkunft und dem Ziel-Repository (Gruppe von Quelldateien, die als eine gemeinsame Source-Gruppe behandelt werden, z.B. mehrere Tools-Projekte) und dessen Verzeichnis vorgegeben wurde, wird das Repository angelegt und das Projekt diesem hinzugefügt:
==>
Ist das geschehen, werden die entsprechenden Icons und im Explorer und im Studio angezeigt:
Nun kann das Projekt "hochgeladen" werden.
Es werden alle betroffenen Dateien angezeigt. Nachdem ein signifikanter Kommentar vorgegeben wurde, wird das Projekt übergeben.
Es wird noch einmal die Liste der gespeicherten Dateien angezeigt und die Farbe der Icins wechselt zu grün:
Jetzt kann Feierabend gemacht werden.
======
Wird nun das Projekt geändert, werden die Änderungen sofort in der Farbe der Icons angezeigt:
Wird dann im Commit-Fenster auf eine geänderte Datei doppelgeklickt, werden im eingestellten Vergleichstool (hier: WinMerge) beide Datei-Versionen angezeigt und die Änderungen hervorgehoben:
======
Nun wollen wir das Projekt auschecken.
Nichts leichter als das:
Wir legen ein neues Verzeichnis an und klicken im Explorer mit der rechten Maustaste da rein:
Nach der Auswahl des Repositories wird die komplette Projektmappe in das Verzeichnis geladen und es kann weiter gearbeitet werden.
======
Wenn gleichzeitig an mehreren PCs dieselben Quellen bearbeitet werden, werden wir beim Einchecken darauf hingewiesen, dass der Quellenstand nicht aktuell iest, wir müssen erst die aktuelle Version auschecken.
Haben wir zufällig dieselbe Datei an 2 Orten bearbeitet, kommt es zu einem Konflikt. Ist dieser trivial, werden die beiden Versionen vom SVN ge-merged.
Ist er es nicht, werden beide Versionen geladen und eine Differenzversion erzeugt, die Farbe der Icons ändert sich zu Rot.
==> ==>
Diese Differenzversion muss manuell bearbeitet werden. Außerdem müssen die Quelldateien im Explorer beräumt werden, die Dateien, die SVN zusätzlich erzeugt hat, müssen zunächst im Explorer gelöscht werden:
Ist das geschehen, kann das Projekt eingecheckt und Feierabend gemacht werden.
======
Noch ein paar Tipps:
Andere Quellcodeverwaltungssysteme gehen ebenfalls einfach, lediglich der TFS (Team Foundation Server) von Microsoft ist bei der Installation eher eine Wissenschaft.
Was ist Quellcodeverwaltung?
Quellcodeverwaltung speichert alle Änderungen zu einem vorherigen Zustand bzw. zu einem Initialzustand, so dass jede dieser Änderungen schrittweise abgerufen und visualisiert werden kann.
Dadurch ist der Speicherverbrauch minimal.
So lassen sich die Unterschiede einer Datei von Version 123 (z.B. vorgestern) zu Version 89 (z.B. vor 2 Wochen) anzeigen, während wir mittlerweile bei Version 135 sind.
Wird ein Release erstellt, sollte diese Version in der Quellcodeverwaltung "ge-tagt" werden, so dass immer klar ist, welcher Code zur Version 1.2.3.4 gehört.
Soll mal etwas ausprobiert werden, was nicht unbedingt in die nächste Release gehört, aber elementarer Bestandteil des Projekts ist, wird ein "Branch" angelegt. In diesem Zweig kann dann nach Bedarf weiter entwickelt und gespeichert werden.
Wenn klar ist, was davon für das Produkt benötigt wird, werden die betreffenden Quellen vom Branch in den Hauptzweig zurückgeführt. Anm.: Dies tue ich selber im Studio und nicht in der Quellcodeverwaltung.
Wie auch immer.
Die Quellcodeverwaltung ist ein wichtiges und mächtiges Tool, um Quellen vor der Vernichtung zu schützen und Versionen als solche zu bewahren.
Folgende Bestandteile müssen vorhanden sein bzw. installiert werden:
- Eine externe Festplatte, auf der die Quellen gespeichert werden sollen, hier kann auch ein Server eingerichtet werden, was für den Zugriff von mehreren Entwickler-PCs aus notwendig ist.
Sicher geht auch die Festplatte im PC selbst, aber raucht die einmal ab, ist alles umsonst. - Die Quellcodeverwaltung als solche, das ist TortoiseSVN. Sie handelt die Quellcode-Datenbank und die zusätzlichen Einträge im Projekt sowie die zusätzlichen Menüpunkte und Icons im Explorer.
Bei der Installation muss das Laufwerk, auf dem die Quellen gespeichert werden sollen, ausgewählt werden.
Mit diesem Tool alleine kann man bereits arbeiten, nur ist das etwas mühselig. Deswegen ist unverzichtbar - Das Plugin für das Visual Studio: VisualSVN, das uns die Arbeit mit der Quellcodeverwaltung abnimmt.
- Wird SVN von einem Server aus installiert (das kommt mit, wenn Server-Festplatten ins Netzwerk gestellt werden), kann dort als Administrator die Repository-Verwaltung durchgeführt werden.
Repository auf dem Server anlegen, auf dem Arbeitsrechner das (leere) Repository auschecken, Projekte hinzufügen und einchecken.
Nachdem einige Fragen zur Quellen-Herkunft und dem Ziel-Repository (Gruppe von Quelldateien, die als eine gemeinsame Source-Gruppe behandelt werden, z.B. mehrere Tools-Projekte) und dessen Verzeichnis vorgegeben wurde, wird das Repository angelegt und das Projekt diesem hinzugefügt:
==>
Ist das geschehen, werden die entsprechenden Icons und im Explorer und im Studio angezeigt:
Nun kann das Projekt "hochgeladen" werden.
Es werden alle betroffenen Dateien angezeigt. Nachdem ein signifikanter Kommentar vorgegeben wurde, wird das Projekt übergeben.
Es wird noch einmal die Liste der gespeicherten Dateien angezeigt und die Farbe der Icins wechselt zu grün:
Jetzt kann Feierabend gemacht werden.
======
Wird nun das Projekt geändert, werden die Änderungen sofort in der Farbe der Icons angezeigt:
Wird dann im Commit-Fenster auf eine geänderte Datei doppelgeklickt, werden im eingestellten Vergleichstool (hier: WinMerge) beide Datei-Versionen angezeigt und die Änderungen hervorgehoben:
======
Nun wollen wir das Projekt auschecken.
Nichts leichter als das:
Wir legen ein neues Verzeichnis an und klicken im Explorer mit der rechten Maustaste da rein:
Nach der Auswahl des Repositories wird die komplette Projektmappe in das Verzeichnis geladen und es kann weiter gearbeitet werden.
======
Wenn gleichzeitig an mehreren PCs dieselben Quellen bearbeitet werden, werden wir beim Einchecken darauf hingewiesen, dass der Quellenstand nicht aktuell iest, wir müssen erst die aktuelle Version auschecken.
Haben wir zufällig dieselbe Datei an 2 Orten bearbeitet, kommt es zu einem Konflikt. Ist dieser trivial, werden die beiden Versionen vom SVN ge-merged.
Ist er es nicht, werden beide Versionen geladen und eine Differenzversion erzeugt, die Farbe der Icons ändert sich zu Rot.
==> ==>
Diese Differenzversion muss manuell bearbeitet werden. Außerdem müssen die Quelldateien im Explorer beräumt werden, die Dateien, die SVN zusätzlich erzeugt hat, müssen zunächst im Explorer gelöscht werden:
Ist das geschehen, kann das Projekt eingecheckt und Feierabend gemacht werden.
======
Noch ein paar Tipps:
- Checkt nur Versionen ein, die compilierbar sind. Nichts ist schrecklicher, als wenn ein Kollege mal schnell seine letzten Edits hochschiebt bevor er in Urlaub fährt und Ihr müsst daran weiterarbeiten, aber sie compilieren nicht.
Üblicherweise arbeitet der Kollege an einem Teil, in den Ihr nicht eingearbeitet seid und Ihr habt einen riesen Aufwand, das ganze zum Compilieren, geschweige zum Laufen zu bekommen. - Schreibt prägnante Kommentare zu den Änderungen.
Wenn Ihr die Versionen vergleicht, bekommt Ihr alle Kommentare angezeigt, sie dienen als Orientierung, was wann geschehen ist. - Wenn Ihr mehrere Baustellen im Projekt gleichzeitig bearbeitet, checkt diese einzeln ein.
Das erleichtert die Rückverfolgung und die Zuordnung der Kommentare.
Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch
Ein guter .NET-Snippetkonverter (der ist verfügbar).
Programmierfragen über PN / Konversation werden ignoriert!
Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch
Ein guter .NET-Snippetkonverter (der ist verfügbar).
Programmierfragen über PN / Konversation werden ignoriert!