Hallo,

eigentlich eine ganz simple Frage: Wie nutzt man Komponenten im Netzwerk?

Also mehrere Entwickler im Netzwerk die immer die gleichen Versionen der Komponenten nutzen sollen.

Ich würde jetzt so vorgehen, dass ich gemeinsam genutzte Komponenten auf den Server lege und alle das Netzlaufwerk in den entsprechenden Suchpfad eintragen.

Aber ist das auch der korrekte Weg? Wie macht Ihr das?

Eine weitere Möglichkeit wäre es ein Sourceverwaltungstool wie CVS/SVN o.ä zu nutzen

Zitat von Angel4585:

Ich würde jetzt so vorgehen, dass ich gemeinsam genutzte Komponenten auf den Server lege und alle das Netzlaufwerk in den entsprechenden Suchpfad eintragen.

Genau so machen wir das auch. dann noch eine Batch-Datei erzeugt damit bei neuen Kompo-Versionen die IDE mit einem Klick aktualisiert wird indem die Packages neu kompiliert werden und damit die bpl und dcp-Dateien neu für den User erzeugt werden bzw. vorhandene kopiert werden.

ach ok die bpl un dcp müssen bei jedem User extra sein? kann man die nicht auch aufs Netz legen?

Zitat von Angel4585:

ach ok die bpl un dcp müssen bei jedem User extra sein? kann man die nicht auch aufs Netz legen?

Würde gehen, empfehle ich aber nicht. stell dir vor du willst was ausprobieren (z.B. neue eigene Komponente in Package aufnehmen). Wie willst du das machen wenn die Dateien von anderen Usern gesperrt sind?

ok, ich wusste nich das die gesperrt werden
dann ist das klar

Die Variante mit dem Netzlaufwerk halte ich für gefährlich bis ungünstig. Denn sobald mehr als 1 Person gleichzeitig an einer Datei arbeitet überschreibt Nutzer1 Dinge die Nutzer2 eingepflegt hat. Natürlich sagt Delphi "oh da wurde eine Datei geändert, willst du diese erneut laden". Aber wenn man dort ja wählt ist ja das eigene getippte auch wieder weg.

Zitat von SirThornberry:

Die Variante mit dem Netzlaufwerk halte ich für gefährlich bis ungünstig. Denn sobald mehr als 1 Person gleichzeitig an einer Datei arbeitet überschreibt Nutzer1 Dinge die Nutzer2 eingepflegt hat. Natürlich sagt Delphi "oh da wurde eine Datei geändert, willst du diese erneut laden". Aber wenn man dort ja wählt ist ja das eigene getippte auch wieder weg.

Hallo,

wenn ich das richtig sehe (keine Erfahrung damit), ist das bei einem Versionsverwaltungssystem eigentlich auch nicht anders - ein System, dass aus 2 geänderten Versionen eine logisch korrekte dritte zusammensetzt, kann es doch garnicht geben.

Da hilft nur Disziplin, Disziplin, Disziplin. Ich kenne nur Systeme, bei denen ein Entwickler die Komponente, die er ändert, für andere gegen Ändern sperrt. M.a.W. alle können lesen, nur einer kann ändern, aber dazu muss er Source usw. "auschecken", damit die anderen keine u.U. kaputte Zwischenversion bekommen.

Gruss Reinhard

Zitat von Reinhard Kern:

wenn ich das richtig sehe (keine Erfahrung damit), ist das bei einem Versionsverwaltungssystem eigentlich auch nicht anders - ein System, dass aus 2 geänderten Versionen eine logisch korrekte dritte zusammensetzt, kann es doch garnicht geben.

Subversion macht das bei uns täglich. Wenn zwei Entwickler an der gleichen Datei, aber an verschiedenen Stellen Änderungen machen, werden die beim anderen jeweils integriert - automatisch. Nicht ohne Grund heissen diese System auch z.B. 'Concurrent Versions System'.

Zitat von Reinhard Kern:

Da hilft nur Disziplin, Disziplin, Disziplin. Ich kenne nur Systeme, bei denen ein Entwickler die Komponente, die er ändert, für andere gegen Ändern sperrt. M.a.W. alle können lesen, nur einer kann ändern, aber dazu muss er Source usw. "auschecken", damit die anderen keine u.U. kaputte Zwischenversion bekommen.

Solche Systeme gibt - aber sie machen auch Ärger. Wenn der Entwickler krank wird oder in Urlaub fährt, ohne seine Version wieder zu entriegeln, muss ein Admin ran. Und die zeitliche Koordination (welcher Entwickler darf als nächster an den Quelltext) wird auch erschwert, wenn immer nur einer ändern darf, aber eventuell drei Entwickler Änderungen an der gleichen Datei vornehmen müssen.

Bei kaputten Zwischenversionen gibt es eins auf die Finger - einchecken "darf" man natürlich nur etwas, das zuvor Unittests passiert hat, oder zumindest einen Smoke-Test besteht (kompilier- und startbar), je nach internem Standard.

Aber sie verhindern ungewolltes oder unbemerktes Überschreiben von Änderungen und ermöglichen es auf jeden beliebeigen Zeitpunkt zurückzugehen