Welche Eclipse-Dateien ist es angemessen, neben den Quellen natürlich unter die Quellcodeverwaltung zu stellen?10 Welche Eclipse-Dateien gehören zur Versionskontrolle?
In meinem Projekt, speziell, ich frage mich über:
.metadata/*
Projektverzeichnis/.project
Projektverzeichnis/.classpath
Projektverzeichnis/.settings/*
Wenn es irgendwelche davon gibt, für die es abhängt, erklären Sie bitte Ihre Richtlinien.
Metadaten sollten nicht in der Quellcodeverwaltung verwaltet werden. Sie enthalten hauptsächlich Daten, die für Ihren Arbeitsplatz relevant sind.
Die einzige Ausnahme ist die 10 XML-Dateien (Launcher-Definition).
Sie sind in
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
gefunden Und sie sollten in Ihrem Projektverzeichnis kopiert werden: Wenn Ihr Projekt aktualisiert wird, werden diese Konfigurationen in der „Run-Konfiguration“ Dialog angezeigt.
Auf diese Weise können diese Startparameterdateien auch im SCM verwaltet werden.
(Achtung: Deaktivieren Sie die Option Do „Konfigurationen löschen, wenn zugehörige Ressource gelöscht wird“ im Run/Starten/Startkonfiguration Einstellungsfenster: Es ist üblich, ein Projekt, um die Soft-löschen importieren sie wieder zurück - eine Re-Initialisierung der Finsternis Metadaten zwingen Aber diese Option, wenn aktiviert, wird Ihre ausführliche Einführung Parameter entfernen)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
in Ihrem SCM (insbesondere .project sein soll.! und .classpath gemäß der Eclipse documentation).
Das Ziel ist, dass jeder seinen/ihren SCM-Arbeitsbereich auschecken/aktualisieren und das Eclipse-Projekt in den Eclipse-Arbeitsbereich importieren kann.
Dafür wollen Sie nur relative Pfade in Ihrem .classpath verwenden, linked resources verwenden.
Hinweis: Es ist besser, wenn project-dir auf ein "externes" Projektverzeichnis verweist, nicht auf ein Verzeichnis, das im Eclipse-Arbeitsbereich erstellt wurde. Auf diese Weise sind die beiden Begriffe (Eclipse Workspace vs. SCM Workspace) klar getrennt.
Wie ipsquiggle erwähnt im Kommentar, und als ich zu in an old answer erwähnt haben, können Sie tatsächlich direkt in Ihrem Projektverzeichnis die Startkonfiguration als freigegebene Datei speichern. Alle Startkonfigurationen können dann wie die anderen Projektdateien versioniert werden.
(Aus dem Blog-Post Tip: Creating and Sharing Launch Configurations von KD)
würde ich sagen, keiner von ihnen. Sie enthalten höchstwahrscheinlich Informationen, die nur für Ihre Workstation relevant sind (ich denke über Pfade für Bibliotheken und alle). Was passiert auch, wenn jemand in Ihrem Team Eclipse nicht verwendet?
Nein, Sie können relative Pfade in Ihrem .classpath haben. Siehe http://stackoverflow.com/questions/300328#300346. – VonC
Klingt wie ein ziemlich inkohärentes/ineffizientes Team, wenn sie nicht denselben Entwickler verwenden. Tools, Projekt-, Debug- und Build-Definitionen usw. - Als nächstes werden Sie mir sagen, dass ich keinen Standard für die Kodierung oder JDK verwenden soll. - Im Idealfall sollte ein Benutzer in der Lage sein, ein Projekt von der Quellcodeverwaltung herunter zu ziehen und ohne viele zusätzliche Setups oder Anweisungen direkt in das Projekt zu springen. Diese Antwort ist für mich einfach inakzeptabel. – BrainSlugs83
Es ist viel ineffizienter, mit den Konflikten in den Einstellungsdateien während einer Zusammenführung umzugehen, nur weil jemand das Projekt von einem neuen Arbeitsbereich aus geöffnet hat - das ist ein Albtraum in großen Projekten. Darüber hinaus klingt das Erzwingen, dieselbe IDE mit genau der gleichen Konfiguration zu verwenden, wie eine unnötige Einschränkung. –
Ich arbeite gerade an einem Projekt, in dem wir die .project und .cproject Dateien unter Quellcodeverwaltung haben. Die Idee war, dass sich Einstellungen, die sich auf Bibliothekspfade und Link-Direktiven beziehen, im gesamten Team verbreiten würden.
In der Praxis hat es nicht sehr gut funktioniert, verschmilzt fast immer wieder in einem konfliktbehafteten Zustand, die außerhalb der Finsternis dekonfiziert werden müssen und dann das Projekt geschlossen und wieder geöffnet für die Änderungen wirksam werden.
Ich würde nicht empfehlen, sie in der Quellcodeverwaltung zu halten.
Einige Projekte, wie diejenigen, die Maven verwenden, erzeugen gern die auf POMs basierenden .project-Dateien.
Das heißt, anders als das - .metadata sollte nicht in der Quellcodeverwaltung sein. Ihr Projekt muss eine Entscheidung darüber treffen, ob projectdir/.settings, basierend auf der Art und Weise, wie Sie Standards verwalten wollen, dies tut. Wenn Sie Ihren Entwicklern aufrichtig vertrauen können, dass sie ihre Umgebung auf Basis des Standards einrichten, und Sie müssen nichts Spezielles für jedes Projekt anpassen, dann müssen Sie sie nicht einfügen. Ich empfehle, jedes Projekt speziell zu konfigurieren . Dies ermöglicht es Entwicklern, an mehreren Projekten im selben Arbeitsbereich zu arbeiten, ohne die Standardeinstellungen ändern zu müssen, und die Einstellungen werden sehr explizit gemacht. Sie überschreiben die Standardeinstellungen, die den Projektstandards entsprechen.
Nur schwieriger Teil ist sicherzustellen, dass sie alle synchron bleiben. In den meisten Fällen können Sie die .settings-Dateien jedoch von Projekt zu Projekt kopieren. Wenn es etwas gibt, das Sie nicht in der Quellcodeverwaltung haben wollen, tun Sie das Äquivalent zur Einstellung von svn: ignore für sie, wenn Ihr SCM dies unterstützt.
Wir verwenden Maven 1 und 2, und es generiert nur die .project-Datei, wenn Sie darum bitten. Und selbst wenn Sie dies tun, basiert dies auf dem Inhalt des POM. Wenn also ein anderer Entwickler diesen Schritt für Sie bereits durchgeführt und das Ergebnis in die Versionskontrolle eingecheckt hat, warum nutzen Sie das nicht aus? –
Es ist nichts wert CDT Konfigurationsdateien sind nicht Source-Control-freundlich. Es gibt einen Fehler für .cproject-Dateien, der sich sehr häufig ändert und Konflikte verursacht, siehe Sharing cdt-project files in repository always causes conflicts.
Huch - dieser Fehler ist sechs Jahre alt und immer noch nicht berührt. Die Unterstützung der Quellcodeverwaltung ist für das Eclipse-Team keine Priorität! – BrainSlugs83
Es sollte auch beachtet werden, dass die .cproject-Datei Konfigurationsinformationen enthält, die andere Entwickler nicht manuell erzwingen müssten. Pfui. –
Die Datei .classpath ist definitiv ein guter Kandidat für das Einchecken in scm, da das Setzen von Hand sehr viel Arbeit machen kann und für neue Entwickler, die in das Projekt einsteigen, schwierig sein wird. Es ist wahr, es kann aus anderen Quellen generiert werden, in diesem Fall würden Sie die andere Quelle einchecken.
Wie für .settings, hängt es von den Einstellungen ab. Dies ist ein grauer Bereich, aber einige Einstellungen sind fast obligatorisch und es ist praktisch, ein Projekt auschecken, es in Eclipse importieren zu können und alles einzurichten und gut zu machen.
In unserem Projekt pflegen wir daher eine Kopie des .settings-Ordners namens CVS.settings und wir haben eine ant-Aufgabe, um sie nach .settings zu kopieren. Wenn Sie das Projekt von CVS erhalten, rufen Sie die Task 'eclipsify' auf, um die Standardeinstellungen in den neuen Ordner .settings zu kopieren. Wenn Sie Einstellungen konfigurieren, die von allen Entwicklern im Projekt benötigt werden, führen Sie diese zurück in den Ordner CVS.settings und binden diese an CVS. Auf diese Weise wird das Speichern von Einstellungen in SCM zu einem bewussten Prozess. Es erfordert Entwickler, diese Einstellungen von Zeit zu Zeit wieder in ihre .settings-Ordner zu integrieren, wenn große Änderungen eingecheckt werden. Aber es ist ein einfaches System, das überraschend gut funktioniert.
Bedenken Sie:
.classpath
.project
.launch
Diese so lange in der Versionskontrolle sein sollte, wie Sie mit Projekt-relativen Pfaden bleiben. Dies ermöglicht anderen Entwicklern, das Projekt zu überprüfen und sofort mit der Arbeit zu beginnen, ohne dass sie alle Setup-Probleme durchgehen müssen, die andere Entwickler ebenfalls durchgemacht haben.
Sie könnten versucht sein, .metadata in die Versionskontrolle einzubinden, damit Eclipse-Entwickler einen gesamten Arbeitsbereich auschecken und mit den richtigen Projekten vorkonfigurieren können, aber es enthält viele benutzerspezifische Informationen, an denen jeder arbeiten kann Es wird sich ändern, also würde ich empfehlen, .metadata NICHT zu enthalten. Es ist einfach, einen lokalen Arbeitsbereich zu erstellen, indem Sie einfach alle vorhandenen Eclipse-Projekte importieren.
Nach meiner Erfahrung tendieren diese dazu, auf verschiedene Arten zu brechen, wenn Sie Eclipse auf eine neuere Version aktualisieren oder zwischen den Varianten wechseln. –
Ich habe zu viele Stunden damit verbracht, die Einstellungen für den Eclipse-Arbeitsbereich für neue Kollegen (und mich selbst) zu konfigurieren. Am Ende habe ich meine eigenen .metadata auf den neuen Entwickler kopiert.
Wenn Sie in einem Team arbeiten, dann denke ich, die folgenden sind sehr gute Kandidaten unter Versionskontrolle behalten:
A (IMO) viel besser Arbeitsablauf zu mit irgendetwas in .metadata für die .launch Dateien arbeiten, ist: Wenn Sie eine Startkonfiguration bearbeiten, auf Wählen Sie auf der Registerkarte "Allgemein" die Option "Speichern unter> Gemeinsame Datei". Dadurch wird es direkt in den Projektordner verschoben, so dass es mit dem Rest des Projekts in SCM umgewandelt werden kann. – Ipsquiggle
@lpsquiggle: guter Punkt. Ich habe meine Antwort vervollständigt, um diese Möglichkeit besser widerzuspiegeln. – VonC
Warum sollte .project in SCM sein? Zum Beispiel möchte ich ein Code-Metriken-Tool verwenden, das Änderungen in .project verursacht, wenn es aktiviert ist. Ich würde das nicht allen Nutzern des Projekts aufzwingen wollen. – jfritz42