Welches Versionierungssystem ist das Richtige?

[milchshake]

Hallo Zusammen,

ich würde gerne für uns ein Versionierungssystem installieren, jedoch weiß ich nicht welches für uns am Besten geeignet ist, vlt. könnt ihr mir dabei helfen. Hier mal mein Vorhaben:

Wir haben einen Entwicklungsserver und einen Produktionsserver, beide (Linux) dezentral. Nun möchte ich vermeiden, das sich jeder XAMPP auf dem lokalen System installiert und dort entwickelt. Lieber hätte ich es so, das jeder am Entwicklungsserver arbeite, dort die Dateien gesperrt werden, die der Benutzer gerade bearbeitet. Nach erfolgreichem Schließen der Datei wird die Datei wieder frei gegeben, so das andere Entwickler daran schreiben können.

Wenn alle Entwickler ihr Werk fertig gestellt haben, möchte ich, teile der Entwicklerversion (Config Dateien mit Datenbank-Hosts etc. ausgeschlossen) auf den Produktionsserver übertragen/mergen.

Jemand nen Vorschlag?

Viele Grüße
Paul

[mermshaus]

Ich glaube nicht, dass das Modell praktikabel ist. Das macht das Testen praktisch unmöglich, weil die gesamte Ausführungsumgebung (der Server, auf dem alle Leute zwangsweise entwickeln müssen) in einem sich ständig verändernden Zustand ist. Du dürftest ja nur dann „Speichern“ klicken, wenn du weißt, dass deine Änderungen (a) funktionieren und (b) keine API-Schnittstellen beeinflussen, weil meinetwegen Code, an dem andere Entwickler arbeiten, deinen Code als funktionstüchtig voraussetzt. Das ist völlig illusorisch. So kann niemand arbeiten.

Meine Empfehlung wäre es, dir ein verteiltes SCM wie Git anzusehen.

- Git - About

Ich denke, es lässt sich als eine Art Faustregel formulieren, dass lokale Entwicklung und lokales Testen auf dem eigenen Rechner meist die vorteilhaftere Variante ist.

[milchshake]

Git hatte ich mir auch schonmal angeschaut, komme auch soweit mit klar, aber ich wollte halt wirklich vermeiden das jeder auf seinem lokalem System developed. Vorallem haben wir alle Windows Rechner, und dort XAMPP laufen zu lassen ist einfach nur mies, da unser Webserver Linux hat. Bevor alle Einstellungen und Funktionen laufen (zB money_format geht nur am Linux-Rechner) vergeht erstmal ne Zeit.

Gibt es den keine andere Möglichkeit?

[mermshaus]

Ich sehe bei der Variante, alle auf dem Server arbeiten zu lassen, keine Lösung für das von mir angesprochene Problem.

Die Vorteile liegen mehr oder weniger alle beim persönlichen Entwicklungsrechner. Auf dem kannst du als Programmierer machen, was du willst (auch etwa weitere Software einsetzen oder Testdateien erstellen oder alles zerschießen), ohne Angst haben zu müssen, jemandem ins Handwerk zu pfuschen.

Gerade bei Git beziehungsweise SCM (Source Code Management) generell ist zudem das Branching zu nennen, das es erlaubt, beliebige Arbeitskopien des Projekts zu erstellen, die beliebig mit anderen Entwicklern ausgetauscht werden können, ohne das große Ganze oder wichtigere Branches zu beeinflussen. (Siehe dazu erneut die verlinkte Seite. Ich weiß nicht, inwieweit du dich mit solchen Konzepten bereits beschäftigt hast. Ich kann das persönlich alles nur nachdrücklich empfehlen. So was lernt man vor allem einmal und ist dann auf der höhe der Zeit und kann in Zukunft immer davon profitieren. Etwa auch beim Umgang mit Projekten auf GitHub.)

Aber zu konkreten Lösungen: Ich würde auf Virtualisierung setzen und das Zielsystem zum Testen auf den Entwicklungsrechnern in einer Virtual Machine laufen lassen. Das klingt kompliziert, ist aber mit Software wie VirtualBox (unter GPL nutzbar) eine überraschend komfortable Geschichte. Du kannst vor allem die Virtual Machine samt virtueller Festplatte einmal erstellen und dann einfach auf alle Entwicklungsrechner kopieren. Dort muss lediglich VirtualBox installiert sein und ein paar GB Speicherplatz (nicht der Rede wert) zur Verfügung stehen.

Ob dann auch direkt in der VM entwickelt wird oder ob sie nur als Testumgebung dient, ist frei entscheidbar.

- https://www.virtualbox.org/ (oder entsprechende andere Virtualisierungssoftware)

[steffomia]

Linux bietet standardmäßig Subversion an. Das ist auch in NetBeans PHP auch als Client integriert.
Ein guter freier Windows Client ist TortoiseSVN

Das SVN Repository installierst irgendwo geschützt auf dem Server und machst regelmäßig einen Checkout der neuesten Version in das htdocs Verzeichnis des Webservers.
Die Entwickler können sich ebenfalls immer die neueste Version auschecken, bearbeiten und wieder einchecken (commit).
SVN erstellt automatisch für jede Datei eine History. Auch hier bietet NetBeans ein Diff-Tool um die Änderungen Human-Lesbar darzustellen.

Allerdings braucht es etwas Linux-Erfahrung um einen sicheren SVN-Server mit Mehrbenutzer-Zugang zu installieren.

Ich habe das mal gemacht auf Debian Squeeze mit SVN+SSH und HTTPS Zugang. Da gibt es ein paar Kniffe über die man stolpern kann.
Nicht desto trotz gibt es brauchbare Tutorials im Internet, die einem helfen.

Siehe auch SourceForge - Download, Develop and Publish Free Open Source Software
Oder hier mein Projekt. Da kannst du alle Versionen zurück verfolgen...

[steffomia]

Das habe ich gerade noch gefunden: GIT vs. SVN

http://www.aservo.com/uploads/media/...P_GITvsSVN.pdf

[mermshaus]

Linux bietet standardmäßig Subversion an.

Die Aussage ist nicht falsch (wobei Linux „standardmäßig“ sozusagen alles anbietet, auch Git[1]), entbehrt aber ebenfalls nicht einer gewissen Ironie, wenn man bedenkt, wer Git ursprünglich geschrieben hat und was diese Person von Subversion hält (absolut gar nix). Das soll kein Widerspruch sein, nur eine Anmerkung. Sorry, falls es wie ein Widerspruch klingt.

Na ja, ich glaube, wir müssen das Fass SVN vs. Git vs. X hier nicht aufmachen. Für einen zentralisierten Entwicklungsstil (ein zentraler Server, viele Clients mit eigener Arbeitskopie) eignen sich beide Versionskontrollsysteme. Das „distributed“ bei Git, Bazaar, Mercurial und Co. ist mehr als „Bonus“ zu verstehen, der auch optional einen stärker verästelten Entwicklungsstil mit weiteren „Knotenpunkten“ zulassen würde. Ich erwähne das, weil das glaube ich häufig falsch verstanden wird. (Deswegen habe ich hier im Thread auch die Links gesetzt. Mir ging es gar nicht so sehr um Werbung speziell für Git, sondern um das Konzept.)

Wie ich das umrissene Szenario hier im Thread lese, geben die SCM-Systeme sich alle wenig. Ich mache keinen Hehl daraus, dass ich Git favorisiere, aber zu behaupten, dass SVN den Job nicht erfüllen könnte, ist auch Unsinn. Die Chancen stehen glaube ich ganz gut, dass die Arbeit mit SVN oder Git zu 95 % deckungsgleich wäre, weil der wesentliche Aspekt darin läge, überhaupt ein SCM-System einzusetzen.

Wie schwierig es ist, so einen Server aufzusetzen? Das ist nicht ganz leicht zu beurteilen. Ich behaupte mal, prinzipiell nicht wesentlich einfacher oder schwieriger als das Einrichten von SMB-Shares. Wer noch keinen Grund gefunden hat, Linux zu benutzen: Das wäre die Chance. (Ich weiß nicht, wie ich das glaubwürdig ausdrücken kann, aber Linux ist einfach so so viel besser und einfacher in solchen Dingen.[2] Das muss man wahrscheinlich selbst erfahren haben, um es zu glauben.) Ich sage mal, der entscheidende Begriff ist SSH Public Key.

PS: Ach ja, die Darstellungen im verlinkten PDF sind nichts, was Einsteiger oder „normale Nutzer“ zu interessieren braucht. Davon bitte nicht verunsichern lassen. Da spricht ein Experte (SVN-Entwickler) über Themen, die aus meiner Sicht definitiv fortgeschritten sind (im Text selbst wird ja auch öfter mal auf die Praxisrelevanz eingegangen; ist kein schlechter Artikel).



1: Die Entwicklung des Linux-Kernels wird mit Git verwaltet. Git wurde anfangs vor allem zu diesem Zweck konzipiert. Auch NetBeans unterstützt Git. Es gibt sogar ein TortoiseGit. SourceForge unterstützt ebenfalls Git.

2: Nicht nur in solchen. Arr.

[steffomia]

Als traditionsliebender Schluffen sollte ich mir Git wohl mal etwas näher anschauen.
Danke für dein Statement!