SVN Management auf einem Projekt, das absolute Pfade verwendet

Question

Ich habe schon gehört, dass Projekt und Arbeitsbereich/Lösung Dateien in der Quellcodeverwaltung in der Regel sowieso schlecht ist, aber ich wollte Feedback über den besten Weg, um diese Situation zu behandeln bekommen.

Meine Arbeit hat angefordert, dass ich einen Quellkontrolldienst für meine Abteilung einrichte (nach dem ich seit dem Tag 1, vor 3 Jahren gefragt habe). Meine größten Hürden sind wie folgt.

Wir behalten einen Snapshot der neuesten Version auf einem Netzwerk SMB-Freigabe, verwenden Sie ein Tag und manuell aktualisieren? Können mehrere Personen diese Arbeitskopie gleichzeitig verwalten oder ist der Ordner nur mit dem Ersteller verknüpft?

Alle unsere "Projekt" -Dateien (mit Dateimanifesten, Build-Informationen usw.) verwenden absolute Pfade. Das ist ein echter Schmerz, wenn ich c: \ myproject verwende und ein Kollege c: \ MaiPrjLolKeke verwendet habe. Ich habe verschiedene Argumente gegen die Verwendung von Putting-Projektdateien unter Quellcodeverwaltung gehört, aber dann, wenn eine neue Datei hinzugefügt wird Projekt, was ist der beste Weg, Mitarbeiter zu benachrichtigen, dass neue Dateien hinzugefügt werden müssen?

Answer 1

Ihre Build-Dateien einrichten relative Pfade zu verwenden.

Im Idealfall sollten Sie in der Lage sein, jederzeit eine Kopie von SVN (und in einen beliebigen Ordner) auszuchecken, das Build-Skript auszuführen, die automatisierten Tests auszuführen und sofort einsatzbereit zu sein. Wenn du das nicht kannst, machst du etwas falsch.

(Ja, Sie müssen möglicherweise auch zuerst das Betriebssystem, den Datenbankserver, den Webserver, die Programmiersprache und die IDE einrichten. Aber sobald die globale Infrastruktur bereits vorhanden ist, sollten Sie in der Lage sein den Boden zu jeder Zeit und von jedem Ort aus zu schlagen.)

Answer 2

Das Problem ist nicht Projektdateien in der Quelle. Das Problem sind die hartcodierten Pfade in den Projektdateien.

Sie können entweder relative Pfade verwenden oder Umgebungsvariablen dafür verwenden.

Zum Beispiel können Sie einen gemeinsamen "root" für Ihre Include-Dateien und einen gemeinsamen "root" für andere Bibliotheken von Drittanbietern verwenden. Die Hierarchie unter den Wurzeln dieser sollte die gleiche sein.

Dies ist in der Regel an vielen Orten verwendet, wo ich gearbeitet habe und es ist normalerweise, wie Sie auf Drittanbieter-Bibliotheken verweisen können. Es behebt auch das Problem, mehrere Versionen einiger Dateien auf einem Computer zu haben. Indem Sie eine Umgebungsvariable (in einem Build-Skript oder auf andere Weise) ändern, können Sie bestimmte Ziele/Builds berücksichtigen.

Zu Ihrer anderen Frage - es ist nicht genau klar, was Sie sagen. Ich denke, du fragst, ob mehrere Leute den gleichen geteilten Pfad/Netzwerk-Share auschecken. Das ist keine gute Idee. Sie können alle Ihre eigene Arbeitssatz/Arbeitskopie der Quelldateien haben und SVN "sperrt" standardmäßig nicht Dateien, so dass Sie gleichzeitig daran arbeiten können. Sie müssen sich in die Praxis begeben, die neuesten Quellen/Änderungen zu aktualisieren/zu bekommen.

EDIT - als ein weiteres Plakat sagte (und ich wiederhole es hier, so dass Sie es nicht verfehlen) -

Lösung und/oder Projektdateien in der Quellcodeverwaltung ist nicht schlecht Praxis.

EDIT:

Hier ist eine andere Lösung - nicht sicher, ob jemand bereits vorgeschlagen.

eine Zuordnung zu einem anderen Ort in der Pfadstruktur erstellen und ein Netzlaufwerk machen - wie x: \

Wenn jeder das tut sie ihre Verzeichnisstrukturen behalten, wie sie mögen und immer noch die gleichen Projektdateien verwenden . Keine Notwendigkeit für Dummy.

Zum Beispiel, wenn Entwickler A

hat

C: \ Entwicklung \ Projekt \ blah Map X: \ Projekt c: \ Entwicklung \ Projekt

und Entwickler 2 hat: C: \ my Dokumente \ Benutzer \ Visual Studio \ etc ..., sie bildet X: \ auf diesen Pfad ab.

Viola!

C: \

Answer 3

Wenn Sie hart-codierte Pfade in Ihren Projekten haben, dann müssen Sie auf einer standardisieren, damit Sie alle zusammenarbeiten können. Dies kann bedeuten, dass Sie alle ändern müssen, um "c: \ work" oder "C: \ dev" zu verwenden, aber das ist ein kleiner Preis, den Sie dafür bezahlen müssen, dass alles "nur funktioniert".

Wenn Sie das absolut nicht tun können, empfehle ich junction - dies richtet Links von einem Verzeichnis zu einem anderen. Sie können alle Dateien für den 'gemeinsamen' Pfad einchecken, aber immer noch von Ihrem eigenen bevorzugten Pfad aus zugreifen. Nicht das Beste, aber machbar.

Wenn Sie relative Pfade verwenden können, dann sind Sie in Shared-Working Nirvana. Versuchen Sie es wirklich, denn es löst nur all Ihre Probleme.

Wenn Sie Probleme mit referenzierten Dateien haben, die sich in einem bestimmten Verzeichnis relativ zu Ihren anderen Projekten befinden müssen (z. B. ein gemeinsamer Satz in c: \ include), verbinden Sie ihn mit dem Ort, an dem Sie ihn auschecken und Sie werden in Ordnung sein, vorausgesetzt, Sie können mit der Disziplin umgehen, die das Verwalten erfordert. Oder Sie können svn: externals verwenden, um die allgemeinen Dateien für einen fest codierten Pfad auszuchecken.

PS. Das Einfügen von Projektdateien in Ihren SCM ist keine schlechte Übung, ich denke, jeder tut es, aber alle Pfade müssen relativ zum Projekt selbst sein, so dass Sie die ganze Menge überall hin überprüfen können, wo Sie möchten.

Answer 4

Ich muss mich mit einer ähnlichen Konfiguration befassen (Projektdateien im SVN-Repository.) Das Hauptproblem ist, dass jemand den Pfad für ihr System "repariert" und dann die Änderungen eincheckt (was das Projekt eines anderen tötet) forces (evil) merging.)

Eine Lösung, die für die Verwendung funktioniert, ist das Speichern einer Vorlage (zB TEMPLATE.project) im Repository und das Hinzufügen (.project) zu SVN: ignore. Auf diese Weise kann jeder Entwickler eine Vorlage der erforderlichen Datei auschecken, aber unbeabsichtigte Änderungen nicht einfach einchecken.

Eine weitere Möglichkeit zur Behebung des Problems mit .classpath besteht darin, mithilfe von UserLibraries alle Bibliotheken von Drittanbietern zu integrieren. Dies ermöglicht es Entwicklern, sie dort zu speichern, wo sie möchten, und ein Mapping in Eclipse zu konfigurieren.