[new001]

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

[bacon]

So wie Du Dir das vorstellst, ist das quatsch. "Normalerweise" entwickelt tatsächlich jeder an seiner eigenen Kiste, der Quellcode steht allgemein unter Versionskontrolle durch ein beliebiges VCS (CVS, Subversion, ein wenig moderner: git sind bekannte Vertreter).

Steht der Code, der auf die Integrationsserver deployed wird, ebenfalls unter Versionskontrolle, kannst Du Änderungen an den Sourcen (neue Releases) jederzeit mit einem simplen Kommando übernehmen. Blacklists (svn ignore, gitignore) können Dir dabei helfen, nicht änderliche Dateien (Konfigurationen, Buildscripts etc.) von Änderungen per se auszuschließen. Effektiver geht das aber mit einem vernünftigen Environment-Management.

CI-Server wie der olle Jenkins bspw. können Dir die leidliche Arbeit abnehmen und den Aktualisierungsvorgang hübsch automatisieren.

P.s. wenn ihr hauptsächlich LAMP-Stacks benutzt, würde ich von Windows schnell abrücken und ebenfalls auf einer Unixoiden, der Zielplattform entsprechenden Umgebung entwickeln.

[new001]

Danke für deine schnelle Antwort, aber genau das ist das was ich vermeiden will.
Ich will vermeiden, das sich jeder Developer jedes mal eine aktuelle Version ziehen muss, nur weil irgendwer irgendwelche Änderungen gemacht hat, die sich auf sein Feature auswirken.

[bacon]

Was willst Du genau vermeiden? Dass es Konflikte dabei gibt? Das vcs zeigt etwähige Konflikte an und listet sie zur Auflösung auf. Konflikte sollte es sowieso nur selten geben, wenn das häufiger unkontrolliert vorkommt, stimmt generell im Arbeitsablauf was nicht.

[pantonine]

Dein Ziel ist absolut illusorisch.

1. Arbeit an jedem nicht-trivialen System erfordert, dass Du im Alltag an mehr als einem Script „gleichzeitig“ (im Änderungsprozess) arbeiten wirst.
2. Jede Änderung sofort einzuchecken ist illusorisch, weil aufwendig und widerspricht dem Versionierungsgedanken. Nämlich sinnvolle funktionale Zwischenstände abzulegen.
3. Dein Verständnis von Versionierung ist falsch. Es geht eben nicht darum, Ressourcen zu sperren.
4. Und wenn, wäre das ein absolut grausames arbeiten, wenn jeder auf die Änderungen des Kollegen warten müsste.
5. Direktes Arbeiten auf dem Server verlangsamt den Dateizugriff und damit den Arbeitsprozess.

Tipps:
1. Projektarbeit wird möglichst auf verschiedene Bereiche verteilt
2. Jeder entwickelt lokal. Bei Bedarf versioniert die Entwicklungsumgebung halt mit. (oder deren Konfiguration)
3. Ich empfehle ein verteiltes Versionierungssystem wie Git oder Mercurial
4. Sinnvolle Zwischenstände werden sauber beschrieben versioniert. Konflikte werden gemeinsam ge„mergt“
5. Funktionale/Fertige Bestandteile werden in das Haupt-Repo gepusht.

[phihochzwei]

Hinzukommt, das deine Konstellation den gesamten Arbeitsfluss extrem ausbremsen würde/könnte.

Vertrau doch einfach mal darauf, das Millionen Entwickler vor Dir nicht vollkommen synoptisch entkoppelt sind.

[sahnemuh]

Wenn du vermeiden willst, dass die workspaces jeweils auf dem rechner des entwicklers liegen, kannst du auch einen groß dimensionierten (oder mehrere kleine) server hinstellen: jeder entwickler bekommt auf dem server einen eigenen benutzer und die home directorys werden jeweils z.B. per ssh gemountet und "wie ein lokales laufwerk" genutzt.
vorteil: es gibt keine unterschiede in der konfiguration / hardware etc.
voraussetzung: schnelle internet / wan / lan anbindung bei den entwicklern und ein entsprechend dimensionierter, performanter server (vorzugsweise im selben netz).
ich habe so ein mal in einem großen projekt als externer entwickler gearbeitet und fand es zwar gewöhnungsbedürftig aber vom konzept ganz nett.
was die versionierung angeht: was die andern sagen!
dateien sperren ist unfug (habe bis vor kurzem mit einem properitäten vcs gearbeitet, in dem es so funktionierte: das war die hölle!). halt dich an z.B. git oder wenn es sein muss svn und vergiss diesen quatsch.

[DEKONSTRUKTIV]

wozu soll denn so gammliger filer für n paar handvoll entwickler großzügig dimensioniert sein?