Komfortabler Dateimanager mit vielen Funktionen

Von SourceSafe zu Subversion

By Sven on 28.05.2008 - 10:00 in Tools & Bibliotheken

Seit mehr als 11 Jahren nutze ich Visual SourceSafe als Quellcodeverwaltung, letzte Woche habe ich meine Projekte auf Subversion umgestellt. Als SourceSafe-Geschädigter muss man sich aber erst einmal an das neue Modell gewöhnen. Unter SourceSafe checkt man die zu bearbeitenden Dateien einzeln oder in Gruppen aus, editiert sie und checkt sie dann wieder ein. Eingecheckte Dateien werden mit einem Schreibschutz-Attribut versehen und können daher nicht einfach so bearbeitet werden. Damit das Auschecken funktioniert, muss Visual Studio eine ständige Verbindung zum Server mit der Quellcodeverwaltung haben. Arbeitet man mal unterwegs, dann simuliert Visual Studio ein Auschecken, indem es das Schreibschutz-Attribut der lokalen Datei entfernt. Beim nächsten Andocken an den Server werden die Dateien dann richtig ausgescheckt.

Mit Subversion ist das alles ein wenig anders. Nach dem Abruf einer Arbeitskopie vom Subversion-Server kann man Dateien beliebig editieren. Sind die Änderungen abgeschlossen, werden die Dateien wieder auf den Subversion-Server übertragen. Dieser speichert dann nur die Unterschiede und hält so seine Datenbank möglichst klein. Eine Verbindung zum Subversion-Server muss nur während des Abrufens/Aktualisierens der Arbeitskopie und des Übertragens zurück bestehen. Damit lässt es sich auch problemlos unterwegs arbeiten.

Die Unterstützung von mehreren Entwicklungszweigen (Branches) ist in SourceSafe quasi gar nicht vorhanden. Zudem wird die Verbindung eines Projekts zur Quellcodeverwaltung direkt in der Projektdatei gespeichert, was die Ablage von Projektkopien in anderen Ordnern (z.B. bei einem neuen Release) sehr erschwert. Wenn man dann die Verbindung nicht löst, möchte Visual Studio immer die Verbindung zum Originalprojekt herstellen.

Mit Subversion gibt es diese Probleme nicht. Verschiedene Entwicklungszweige sind einfach zu verwalten, auch die Übernahme von Änderungen in andere Zweige ist problemlos möglich. Die Projektdateien sind anderen Dateien gleichgestellt und enthalten keine datenbankspezifischen Informationen mehr.

Das ermöglicht es mir jetzt endlich, ein paar Wochen vor der Veröffentlichung eines Updates einen separaten Zweig dafür zu erstellen, die aktive Entwicklung dafür einzustellen und wirklich nur noch nötige Korrekturen vorzunehmen. Die normale Entwicklung an der nächsten Version kann dann schon weitergehen, ohne auf das geplante Update Einfluss zu nehmen.  Damit entfällt nun auch die Wohlverhaltensperiode vor und nach dem Release, in der ich mich zwingen musste, meine Finger im Zaum zu halten. Treten nach dem Update doch noch unerwartete Fehler auf, so können diese im separaten Zweig behoben und schneller als Fix zur Verfügung gestellt werden.

Die Einrichtung von Subversion ist sehr einfach. Nach der Installation wechselt man in der Kommandozeile in das bin-Verzeichnis und richtet svnserver.exe als Dienst ein:

sc create svnserve binPath= “C:\Programme\Subversion\bin\svnserve.exe –service -r D:\Projekte\Subversion” DisplayName= “Subversion” depend= tcpip start= auto

Anschließend muss nur noch ein neues Projektarchiv erstellt werden. Alternativ kann man sich auch das Rundum-Sorglos-Paket VisualSVN Server herunterladen. Dieses installiert einen Apache-Server samt Subversion-Integration und erstellt auch gleich das Projektarchiv. Damit hatte ich meine ersten Gehversuche gemacht, bin aber anschließend auf die performantere Dienst-Methode umgestiegen.

Auf dem Client-Rechner wird TortoiseSVN installiert, damit erfolgt der Zugriff auf die Quellcodeverwaltung bequem aus SpeedCommander (oder dem Explorer) heraus. Für die Integration in Visual Studio empfiehlt sich VisualSVN. Die Einzellizenz kostet $49 und macht sich schnell bezahlt.

Letztlich kann ich jedem SourceSafe-Anwender nur empfehlen, auf Subversion zu wechseln. Beim Einstieg beantwortet die umfangreiche Dokumentation viele Fragen, für die ersten Gehversuche kann man sich ein Projektarchiv zum Spielen einrichten. Mit einer möglichen Konvertierung der SourceSafe-Datenbank habe ich mich nicht beschäftigt, ich wollte einen frischen Start ohne Altlasten.

Es gibt 9 Kommentare zu diesem Beitrag

Trackback URL | RSS-Feed für Kommentare

  1. ItsMe sagt:

    Was war ich froh als ich nach einem halben Jahr Subversion wieder SourceSafe benutzen durfte! Allerdings haben wir das bei uns im Team auch so gelöst das wir manuell auschecken und nicht über das Studio gehen.
    Und Entwicklungszweige sind auch kein Problem wenn man sich angewöhnt zu labeln…

  2. Milindur sagt:

    Subversion ist schon eine sehr angenehme Sache. Vorher habe ich mit CVS gearbeitet, das war eher gruselig. Mittlerweile bin ich jedoch von Subversion auf Mercurial umgestiegen:
    http://www.selenic.com/mercurial/wiki/
    http://de.wikipedia.org/wiki/Mercurial

    Mercurial hat für mich gegenüber Subversion den Vorteil, dass ein Checkout immer das komplette Repository beinhaltet und ich somit auch unterwegs (ohne Internet) Zugriff auf die vollständige Historie habe. Außerdem kann ich auch unterwegs (z.B. beim Kunden) Bugfixes commiten, ältere Versionen auschecken, Branches zum Testen anlegen usw. Sobald ich wieder Internet bzw. Zugriff auf meinen Server habe, synchronisiere ich die Änderungen mit dem Hauptrepository.

    Der wesentliche Nachteil von Mercurial ist derzeit noch, dass mit TortoiseHg zwar eine Windows-Shell-Integration in Entwicklung ist, diese aber noch längst nicht den Reifegrad von TortoiseSvn erreicht hat. Eine Visual-Studio-Integration gibt es derzeit auch noch nicht, soweit ich weiß.

  3. Warum verwendest Du nicht den TFS? In meinen Augen die beste integrierte Löung die einem sehr sehr viel abnimmt.
    Mit Subversion hatte ich nur Bauchschmerzen… Wir haben einen Testbetrieb nicht weitergeführt und sind bei VSS geblieben. Und jetzt sind wir absolut glückliche Nutzer von TFS-2008 und ich ärgere mich heute noch grün und blau, dass wir produktiv nicht früher umgestiegen sind.

  4. Sven sagt:

    @ItsMe: Labeln ist das eine, richtiges Verzweigen und einfaches Weiterarbeiten daran das andere.

    @Milindur: In der aktuellen c’t ist auch ein Artikel zum Umstieg von Subversion auf Mercurial. Der einfache Zugriff aus dem SC und die VS-Integration waren mir aber wichtiger als der ständige Zugriff auf das Projektarchiv.

    @Martin: Den TFS Workgroup gibt es erst ab MSDN Premium. Vom Umfang her reicht mir MSDN Professional völlig aus, für MSDN Premium müsste ich knapp das Dreifache (ca. 3000 Euro) zahlen. Und das ist mir der TFS einfach nicht wert.

  5. Es ist nicht sonderlich schwer MS-Certified Partner und ISV zu werden. Das kostest das selbe (oder sogar weniger) wie ein MSDN Abo. Dann bekommt man aber den TFS gratis… 😉

  6. Sven sagt:

    Soweit ich weiß, beträgt die Jahresgebühr für MS-Certified Partner ca. 1500 Euro. Beim Empower-Programm gelten die Lizenzen nur für die Dauer der Mitgliedschaft. Ich vermute mal, dass es beim Certified Partner ebenso ist.

    Da fahre ich mit mit meinem MSDN-Abo (500 Euro pro Jahr) ein wenig günstiger, zumal der Umfang für mich als Einzelkämpfer auch völlig ausreichend ist. 🙂

  7. Thorsten sagt:

    Nachdem ich 2 Wochen lang versucht habe (ca 1-2Std / Tag) einen TFS aufzusetzen, damit ich meine (Verteilte) Entwickler vom VSS zu etwas ‘neuem’ bekomme, habe ich es aufgegeben:
    Ich habe einen Virtuellen Server im Netz (W2K3 Server) auf dem ich das alles installieren wollte:
    1. SQL-Server installieren
    2. TFS installieren
    – geht nicht, da mein angemieteter Server eine 64-Bit Maschine ist, das Kapitel “TFS und 64 Bit” tut so, als ob das alles kein Problem währe, um letztendlich zu deer Schlussfolgerung zu gelangen, das TFS selber nicht auf einem 64-Server läuft.

    Neuanfang:
    1. Eigenen Rechner aufgesetzt, W2K8 Server installiert (32 Bit!)
    2. SQL-Server (2005) installiert
    3. TFS installiert
    – Fehlermeldung: Sharepoint muss vorher noch drauf
    4. Sharepoint Services installiert
    5. TFS(2008) installiert
    – Fehlermeldung SQL-Reporting-Services nicht da
    SQL-Setup neu gestartet; kann Reporting-Services nicht aufsetzen, da gar nicht erst auswählbar
    Nach Fehlersuche, die IIS6 – Kompatibilitätsschicht installiert (und 32 andere Rollen und – Rollfeatures)
    SQL-Reporting-Services installiert
    (eigentlich brauche ich nur eine Quellcodeverwaltung, mit der ich Branchen und Mergen kann.. keine Reports, keine Arbeitsbereiceh usw.. )
    TFS (wider) installiert
    – sieht gut aus,
    In den Setup-Dialogen wurden Sharepoint- Management-Pfade und Sites-Pfade vorgeschlagen, die so gar nicht stimmen, also Pfade angepasst
    Fast ganz zum schluss weigert sich die Installation beharrlich sich mit den Report-Services zu verbinden, warum sagt der mir nicht. Auch aus den Protokoll werde ich nicht schlau.

    Nach fast 2 Wochen abgebrochen.
    VisualSVN-Server installiert (6Mb download, kostenlos!)
    Auf dem Client AnkhSvn installiert, => Läuft !

    Ätzend!
    TFS ist sehr wohl eine Mächtige Architektur, leider kann man bei der Installation nicht angeben, welche Dienste man nicht braucht. Ein weitere richtiger Nachteil ist die Anforderung an die Plattform (Server-OS, SQL-Server, Sharepoint usw)

    Fazit: Für grosse Firmen ist TFS ok, aber SVN tuts auch. Als eigenständiger Entwickler, der auch auf das Geld achten muss, und in seiner Freizeit nicht auch noch einen W2Kx -Server administrieren möchte ist TFS nicht die richtige Wahl.
    Ich nutze nun SVN!

    BTW: Mein Ticket / Bug – System ist “Bugzille”: Installation auf Windows- ist etwas aufwändig, geht aber auch. (habe sowohl unter Windows Bugzilla am Laufen, als unter Linux)

  8. Sven sagt:

    Bei mir lief die TFS-Installation auf Windows Server 2003 R2 recht problemlos. Die Sharepoint-Services wurden vom TFS-Installationsprogramm selbst installiert.

  9. Beat sagt:

    @Thorsten
    Wir verwenden den Bugtracker ‘Mantis’ unter Linux, sollte aber auch unter Windows einfach zu installieren sein.

Top