Versionsverwaltung mit Zentralserver: Mercurial? SVN?

[jaenicke]

Hallo,

wir möchten eine aktuellere Versionsverwaltung einsetzen. Leider finde ich nicht wirklich viel Material insbesondere zu Git und Mercurial was zu unseren Anforderungen passt. Eigentlich gefallen mir diese privat ja ganz gut, aber irgendwie finde ich nicht viel für eine professionelle Nutzung. Nur x verschiedene Seiten mit y verschiedenen Vorschlägen, die wiederum y - 1 Vorschläge ablehnen... :roll: (gut, das ist etwas übertrieben ;-))

Die Anforderungen sind jedenfalls klar:

• Zentraler Server (was ein lokales zusätzliches Repository usw. natürlich nicht ausschließen soll, Betonung auf zusätzlich ;-))
• Windows Server
• Direkter Zugriff im lokalen Netzwerk ohne SSH oder ähnliches

Die Frage ist nun wie sich das mit welchem Tool umsetzen lässt.

Ich habe HgService und so etwas durchaus schon gesehen, aber eine Übersicht wie was wo läuft oder ein Setuppaket oder irgendwas habe ich dazu nicht gefunden. Nur, dass hg serve auf der einen Seite vorgeschlagen wird, auf einer anderen besser auf eine CGI-Lösung verwiesen wird, ...

Und bei Git scheint es nur über cygwin überhaupt zu laufen, so dass das natürlich ganz ausscheidet.

Ich habe jetzt schon einige Zeit investiert, weil immer wieder auf Mercurial oder Git verwiesen wird, bin aber dennoch an einem Punkt angekommen, wo ich doch wieder zu SVN tendiere.

Ich hoffe mal, jemand von euch hat Erfahrung damit und Ratschläge parat...

Vielen Dank,
schönen Gruß,
Sebastian

[mquadrat]

Die verteilten Versionsverwaltungen sind IMHO besonders für stark verteilte Teams nützlich, oder Projekte, in denen man keinen Einfluss auf die Zahl oder Art der Mitarbeitenden hat (Pull Requests sind da eine feine Sache).

Im Unternehmen mit klar definierten Strukturen sehe ich persönlich weniger Vorteile. Wir setzen als Server VisualSVN ein und auf den Clients TortoiseSVN. Solange das für uns funktioniert wird sich daran auch nichts ändern.

[Phoenix]

Du kannst einen Zentralen SVN-Server einsetzen (VisualSVN bietet sich hier an).

Jeder Mitarbeiter der möchte, kann darüber hinaus lokal mit Git oder Hg arbeiten, denn für beide Systeme gibt es bridges die von SVN pullen und nach SVN pushen können, so dass man lokal oft committen kann und hinterher kompilierfähiges Zeug in den zentralen SVN-Server pusht.

[Uwe Raabe]

Als langjähriger FogBugz-User bin ich letztendlich bei Kiln gelandet - nicht zuletzt auch wegen der hervorragenden Integration. Der Schritt von SVN nach Mercurial war schon ein ziemlicher Paradigmenwechsel und somit einige Male sehr schmerzhaft, aber ich würde es jederzeit wieder machen. Seitdem ist mein SVN-Server in Rente.

Bedauerlich ist das noch recht dünne Ecosystem zu Mercurial. Da hat SVN halt immer noch die Nase vorn.

[Nersgatt]

Wir setzen auch SVN + Tortoise ein. Der Server läuft auf einer Windowskiste (ich glaub, unter XP). Visual SVN setzen wir dort ein. Ist in 5 Minuten installiert. Von außen ist auch ein Zugriff problemlos möglich. DynDns, ensprechende Ports weiterleiten, fertig. Läuft sogar mit einem 2000er-DSL auf der Serverseite noch annehmbar flott.
Und im Moment fehlt mir kein Feature.

Ich würde aber an eurer Stelle den Windowsserver nicht zum K.O.-Kriterium machen. Eine virtuelle Maschine mit irgend einer Linuxdistribution ist ja auch schnell aufgesetzt. Auf die Art läuft bei uns noch ein Bugzilla (für interne Zwecke).

[jaenicke]

Zitat:

Zitat von Nersgatt (Beitrag 1117861)

Ich würde aber an eurer Stelle den Windowsserver nicht zum K.O.-Kriterium machen. Eine virtuelle Maschine mit irgend einer Linuxdistribution ist ja auch schnell aufgesetzt.

Danke, uns reicht ein Server, der ständig Probleme macht... (natürlich auf Linux Basis)
Wobei ich privat auch einen Linux Server nutze, aber ich habe auch schon viel zu viele Stunden an dessen Konfiguration usw. verbracht, die ich besser hätte nutzen können. Aber immerhin läuft der. Ein Windows Server allerdings parallel auch und dessen Konfiguration hat einen Bruchteil der Zeit gebraucht.

Zitat:

Zitat von Phoenix (Beitrag 1117743)

Jeder Mitarbeiter der möchte, kann darüber hinaus lokal mit Git oder Hg arbeiten, denn für beide Systeme gibt es bridges die von SVN pullen und nach SVN pushen können, so dass man lokal oft committen kann und hinterher kompilierfähiges Zeug in den zentralen SVN-Server pusht.

Das hört sich allerdings interessant an. Das werde ich mir einmal anschauen.

Ich denke einmal dann ist SVN wirklich die sinnvollste Variante. Damit gab es zwar die nächsten Probleme (Repository ist nicht erreichbar...), aber das muss ich mir einmal genauer anschauen.

Zitat:

Zitat von Uwe Raabe (Beitrag 1117768)

Als langjähriger FogBugz-User bin ich letztendlich bei Kiln gelandet - nicht zuletzt auch wegen der hervorragenden Integration.

Mal schauen, was die Systeme können, die kannte ich noch gar nicht.

Danke schon einmal, mal sehen was am Ende herauskommt. ;-)

[s.h.a.r.k]

Bei Git reicht es doch auch voll und ganz aus via Samba auf ein Verzeichnis zugreifen zu können. Da braucht man keinerlei Server-Software. Ob das unbedingt gut ist, steht auf einem anderen Platt Papier. Über Mercurial kann ich leider nichts sagen, außer, dass es sehr ähnlich zu Git sein soll.

Hier noch schnell eine Ergänzung:

Zitat:

Zitat von http://www.kernel.org/pub/software/scm/git/docs/git-clone.html

Git natively supports ssh, git, http, https, ftp, ftps, and rsync protocols. The following syntaxes may be used with them:

[jaenicke]

Bei Git braucht man aber offenbar cygwin, es ist also keine echte Windowslösung. Das finde ich ein wenig suboptimal. Mit so etwas habe ich schon viele schlechte Erfahrungen gehabt...

Ich glaube eine Lösung mit echtem Server wäre schon stabiler als eine Lösung, bei der mehrere parallel auf eine Freigabe zugreifen. Oder?

[s.h.a.r.k]

Jetzt verstehe ich erst was du genau meinst :stupid: es gibt doch das schöne msysgit-Projekt. Wenn einem das nicht taugt, dann gibts doch auch ein TortoiseGit.

Das mit dem Server stimmt natürlich. Habe mich darum aber noch nie gekümmert. Bisher hatte ich immer reine Online-Repositories und da musste ich bisher nichts anlegen.