Matthias: Versionsverwaltung unter Windows?

Hallo zusammen,

ich bin seit längerem auf der Suche nach einer Versionsverwaltung für meine diversen privaten (Web-)Projekte.

Gestern bin ich an Subversion gescheitert (u.a. weil es nicht auf meinem lokalen Apache 2.2 läuft, und ich eine Parallelinstallation von einem 2.0er nicht hinbekommen habe: Am Ende ging keiner von beiden mehr richtig und ich musste alles neu aufsetzen...)

Jetzt brauche ich also die Antwort auf eine von 2 Fragen:

  • Wie bringt man Subversion parallel zu einem Apache 2.2 zum laufen ohne diesen zu stören?
    oder
  • Welche Alternativen gibt es zu Subversion? Wunscheigenschaften:

* halbwegs intuitiv bedienbar (ich habs nicht  so damit, halbe Romane in die Kommandozeile zu tippen)
* brauchbares Featureset (Dateien umbenennen, löschen oder ganze Verzeichnisbäume importieren ist halt schon praktisch)
* wenn sich das ganze dann noch in (Easy-)Eclipse integrieren lässt, bin ich wunschlos glücklich.

Vielen Dank für Eure Hilfe!

Matthias

  1. Moin!

    Gestern bin ich an Subversion gescheitert (u.a. weil es nicht auf meinem lokalen Apache 2.2 läuft, und ich eine Parallelinstallation von einem 2.0er nicht hinbekommen habe: Am Ende ging keiner von beiden mehr richtig und ich musste alles neu aufsetzen...)

    Mußt du den Zugriff auf das Repository rechnerübergreifend bzw. für mehrere User anbieten?

    Wenn nein, würde ich schlicht empfehlen, dass du dir z.B. TortioseSVN installierst und irgendwo auf deiner Festplatte ein Repository erstellen läßt, dass sich dann ganz simpel über das file-Protokoll ansprechen läßt. Und schwups - schon hast du eine Versionsverwaltung, vollkommen ohne lästigen Apache-Krams.

    - Sven Rautenberg

    --
    "Love your nation - respect the others."
    1. Hallo Sven,

      danke für Deine Antwort. Wie oben zu lesen ist, habe ich den svnserve lokal zum laufen bekommen.

      Mußt du den Zugriff auf das Repository rechnerübergreifend bzw. für mehrere User anbieten?

      Im Moment nicht, aber wer weiss...

      Wenn nein, würde ich schlicht empfehlen, dass du dir z.B. TortioseSVN installierst und irgendwo auf deiner Festplatte ein Repository erstellen läßt, dass sich dann ganz simpel über das file-Protokoll ansprechen läßt. Und schwups - schon hast du eine Versionsverwaltung, vollkommen ohne lästigen Apache-Krams.

      Subclipse (Das Eclipse-Plugin für Subversion) scheint mit dem Zugriff über file:/// auf die Repositories leider nicht zurecht zu kommen (vielleicht habe ich aber auch einfach was falsch gemacht...), per svn:/ geht es jedoch. Trotzdem habe ich mir mal TortoiseSVN installiert und finde dass es eine prima Ergänzung ist.

      So sehe ich dank "überlagerten Symbolen" direkt im Explorer im Projektordner (aus dem auch der Apache zum testen die Seiten serviert), welche Dateien geändert wurden, ob alles auf dem neusten Stand ist, usw...

      Eigentlich wäre die ganze Materie doch ein interessantes Thema für einen SELFHTML aktuell - Artikel...

      Vielen Dank für Deine Hilfe!

      Matthias

  2. Hallo,

    ich bin seit längerem auf der Suche nach einer Versionsverwaltung für meine diversen privaten (Web-)Projekte.

    Gestern bin ich an Subversion gescheitert (u.a. weil es nicht auf meinem lokalen Apache 2.2 läuft,

    Jetzt brauche ich also die Antwort auf eine von 2 Fragen:

    • Wie bringt man Subversion parallel zu einem Apache 2.2 zum laufen ohne diesen zu stören?

    Wozu brauchst du dafür den Apache?
    (OK, wenn es zu mühsam ist, die Dateien selbst zu kopieren)

    Die Dateien sind ja lokal auf deinem Rechern: d.h. die Dateien selbst sind immer auf dem letzen Stand.
    Dem Apache kannst du dann folgendes sagen, damit keine .svn Verzeichnisse "abgesurft" werden können:

    <DirectoryMatch "^/.*/.svn/">
        Order deny,allow
        Deny from all
    </DirectoryMatch>

    Du kannst svnserve ab 1.4 von Subversion auch als Dienst installieren (Statt Apache):
    http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup-svnserve.html
    http://svn.collab.net/repos/svn/trunk/notes/windows-service.txt

    Grüße
    Thomas

    1. Hallo Thomas,

      danke für Deine Antwort.

      Wozu brauchst du dafür den Apache?
      [...]
      Du kannst svnserve ab 1.4 von Subversion auch als Dienst installieren (Statt Apache):

      Tatsächlich hatte ich bis jetzt nicht realisiert, das Subversion nicht zwangsläufig über Apache laufen muss. Ich habe es mit Hilfe Deiner verlinkten Anleitungen und etwas Gefummel jetzt lokal als Daemon eingerichtet. So kann ich es jederzeit starten wenn ich es brauche, und sonst frisst es keine Ressourcen. Auch die Verbindung von Subclipse mit dem daemon scheint gut zu funktionieren.

      Ich danke für Deine wirklich hilfreiche Hilfe!

      Matthias

      1. Fürs Archiv:

        snvserve.exe lässt sich auch einfach als Windows-Service registrieren. Der zugehörige Befehl:

        sc create svn binpath= ""C:\program files\svn\bin\svnserve.exe" --service [args]" displayname= "Subversion Server" depend= Tcpip start= auto

        Dabei auf die Leerzeichen nach den "ist gleich (=)" achten!

        Der Pfad zu Subversion (binpath=) muss natürlich angepasst werden.

        Für [args] können weitere Argumente angegeben werden, zum Beispiel der Pfad zum Repository-Wurzelverzeichnis mir "-r "c:\Pfad zum\Verzeichnis".

        Anschliessen lässt er sich wie jeder Service bequem per >>net start "Subversion Server"<< starten und stoppen.

        Das alles lässt sich nachlesen im hervorragenden svn-Buch von Ben Collins-Sussman u.a., siehe http://svnbook.red-bean.com/ (und zum Teil auch in der Hilfe zu TortoiseSVN, die es auch auf Deutsch gibt)

  3. Hallo Matthias,

    ich bin seit längerem auf der Suche nach einer Versionsverwaltung für meine diversen privaten (Web-)Projekte.

    Ich nutze seit einiger Zeit privat das dezentrale VCS Bazaar. Dezentral heisst hier: Es gibt kein zentrales Repository, stattdessen werden die Versionen im versionskontrollierten Ordner unter .bzr/ gespeichert. Branchen war nie einfacher. Andere Dezentrale VCS sind darcs, git, Mercurial, etc. Manche meinen, dass das Python-basierte Bazaar etwas langweilig sei, ich hab jedoch keine Probleme.

    Tim

    1. Moin!

      Branchen war nie einfacher.

      Will man das denn?

      Ich denke, wenn man einen neuen Zweig eröffnet, hat man hinterher nicht einen Ort, an dem Probleme gelöst werden müssen, sondern schon zwei. Also mitunter doppelte Arbeit, und in jedem Fall mehr Organisationsaufwand.

      - Sven Rautenberg

      --
      "Love your nation - respect the others."
      1. Hallo Sven,

        Will man das denn? Ich denke, wenn man einen neuen Zweig eröffnet, hat man hinterher nicht einen Ort, an dem Probleme gelöst werden müssen, sondern schon zwei. Also mitunter doppelte Arbeit, und in jedem Fall mehr Organisationsaufwand.

        Branchen bedeutet ja nicht, dass es keine Kommunikation aktueller Weiterentwicklungen zwischen den einzelnen Zweigen gibt. Ein zeitweiliger Branch ist durchaus praktisch für langfristige Umbauten, Neuentwicklungen, Experimente, Dinge, die gerne versionskontrolliert werden möchten, aber nicht mit einem einzigen Commit abgetan sind. Im Ein-Personen-Kontext mit „Ein Problem pro Zeit“ ist das zugegebenermassen etwas seltener, aber durchaus auch praktisch. Im größeren Organisationsteam an einem größeren Projekt wird es aber durchaus praktischer.

        Mal ein hypothetisches Beispiel anhand von SELFHTML: Abteilung Javascript beschliesst, jetzt Die Große Umorganisation Des DOM-Kapitels Des Jahres 2007 anzugehen. Nehmen wir mal einen größeren Prozess mit einer vollkommen neueren Struktur an, massiv hyperverlinkt bei der die DOM-Referenz mehr dem DOM-Baum folgt und auch z.B. Vererbungen wie im DOM darstellt. Also: Alle Seiten anders, alle Konventionen anders, eine Operation am offenen Herzen, hart am Rande des Neuschreibens, das durchaus etwas länger dauern kann.

        Gleichzeitig will Abteilung CSS jetzt stückweise anfangen, neue kleine atomare Einzelstücke von CSS ins CSS-Eigenschaften-Kapitel einzusortieren, Abteilung Webserver will das und das und noch was ganz anderes machen und Abteilung Gesunder Menschenverstand will gerne Bugs verbessern, sobald diese auftreten. Diese Fraktion will also gerne die Weiterentwicklungen an SELFHTML im schnelleren Rythmus veröffentlichen, während Abteilung Javascript mehr mit einer Klausur geholfen wäre.

        Also zweigt Abt. JS. einen DOM-Rewrite-Zweig ab und arbeitet dort an der großen Umstrukturierung, während der Rest an normalen Trunk weiterarbeitet und dort nicht so riesige Neuerungen aber dafür Veröffentlichungen macht. Team JS verfolgt die Änderungen im Trunk und mergt diese mehr oder minder regelmäßig in ihren Zweig ein, so dass dieser auf dem aktuellen Stand bleibt. SELFHTML als Dokumentation ist da perfekt für, da die Verpflechtungen zwischen den Dateien letztendlich nur Verweise sind, also relativ leicht zu mergen; Software ist da zugegebenermassen schwieriger.

        Irgendwann ist das große DOM-Rewrite-Projekt fertig, SELFHTML 8.2, 8.2.1, 8.2.2, 8.2.3 sind erschienen (hoffentlich kommt es niemals dazu ;). Also wird der DOM-Rewrite-Zweig wieder in den Trunk gemergt. Oder umgekehrt, ist doch der Nicht-DOM-Rest der Kapitel von SELFHTML durch das regelmäßige Mergen der Neuerungen im Trunk in den Zweig auf einem neueren Stand als der Nicht-DOM-Rest im Trunk, der wegen Veröffentlichungszwang keine angepassten Verweise besitzt.

        Klar hat man einen etwas höheren Organisationsaufwand beim branchen, das Mergen vom Trunk. Aber wenn man nur in einem Gesamttrunk arbeitet, kann man irgendwann nur noch ganz kleine Schritte unternehmen, weil man dann die Gefahr läuft, etwas so durcheinander zu bringen, dass man andere mit dem Wunsch des schnelleren Veröffentlichungen bremst. Größere Schritte wie größere Umbauten wirken sich dadurch dann auf die Veröffentlichungen aus.

        Zurück zu Bazaar: Hier ist jede Working Copy ein eigener Branch, in dem man selbst committen kann, wie man lustig ist. Ein zentraler Branch existiert nur durch soziale Kontrolle, d.h. eine Kopie, auf der sich jeder verständigt hat, dass das der Trunk sei. Der klassische Commit aus der Working Copy ins zentrale Repository ist hier mehr ein Mergen. Das mag extrem erscheinen, ist aber letztendlich nur ein Weiterdenken des Gedanken dass so eine Entwicklung kein Baum mit sich abzweigenden Ästen ist, sondern mehr ein mäandernder Fluss mit unzähligen Nebenläufen, die wieder zum Fluss zurückkehren oder mit ihm durch kleine Bäche verflochten sind.

        Tim

    2. Hallo Gunnar,

      Manche meinen, dass das Python-basierte Bazaar etwas langweilig sei ...

      Langweilig? Langsam. Ich meinte langsam.

      Tim

    3. Ich nutze seit einiger Zeit privat das dezentrale VCS Bazaar. Dezentral heisst hier: Es gibt kein zentrales Repository, stattdessen werden die Versionen im versionskontrollierten Ordner unter .bzr/ gespeichert. Branchen war nie einfacher. Andere Dezentrale VCS sind darcs, git, Mercurial, etc. Manche meinen, dass das Python-basierte Bazaar etwas langweilig sei, ich hab jedoch keine Probleme.

      Hallo Tim,

      danke für Deine Antwort. Auch wenn ich mich erstmal entschieden habe, Subversion (ohne Apache) noch eine Chance zu geben, werde ich Deine Vorschläge auf jeden Fall im Hinterkopf (bzw. in den Bookmarks ;-) ) behalten.

      Viele Grüsse,

      Matthias