Ich weiß, dass es immer wieder auftaucht, aber meine spezifische Frage ist: Ich habe mehrere Arbeitsbereiche, die die Erweiterungen wpt, cdt und jdt (und andere) benutzen. Ich möchte harte Verbindungen (ich bin auf Windows) von allen meinen Arbeitsbereichen zu einer Untergruppe von Einstellungsdateien schaffen, die Dinge wie Abkürzungen, Arbeitsplatzpräferenzen usw. regeln. So wenn ich zum Beispiel eine Abkürzung in einem Arbeitsbereich verändere, wird die Änderung propagieren zu allen anderen Arbeitsbereichen. Problem ist der .metadata / .plugins Ordner ist ein komplettes Chaos (ich glaube, die Einstellungen sind alle da). Zum Beispiel weiß ich, dass ich die Dateien verknüpfen muss:
%Vor%Ich glaube, ich sollte nicht versuchen, den gesamten .metadata / .plugins-Ordner zu verknüpfen, da er arbeitsbereichsspezifische Daten enthält.
Wäre es sicher und genug , um das Verzeichnis \.metadata\.plugins\org.eclipse.core.runtime\.settings fest zu verknüpfen?
Kann mir jemand auf irgendeine Dokumentation hinweisen, was all diese .index und .dat Binärdateien in \.metadata\.plugins\ sind?
Wenn das nicht möglich ist, würde ich mich über eine Referenz für die verschiedenen .prefs -Dateien in \.metadata\.plugins\*\.settings -Verzeichnissen freuen, besonders die .metadata\.plugins\org.eclipse.core.runtime\.settings one
Danke
Okay, was ich getan habe (eclipse juno auf Windows 7) war:
Erstellen Sie einen neuen Eclipse-Arbeitsbereich, sagen Sie test , führen Sie ihn aus und beenden Sie ihn einfach
Hat es zu einem Git Repo gemacht
Committed die Dateien, die von eclipse zusammen mit diesem .gitignore erstellt wurden:
%Vor%Auf einen neuen Zweig umgeschaltet
Hat einen meiner Arbeitsbereiche aufgerufen, ALLE Einstellungen exportiert, dann den Arbeitsbereich test gestartet und sie importiert. Vergleichen Sie die .metadata / dirs der Arbeitsbereiche mit Hilfe von Beyond Compare. Die Ordner .metadata\.plugins\org.eclipse.core.runtime\.settings\ waren bis auf die Datei org.eclipse.ui.workbench.prefs identisch, aber die Unterschiede schienen nicht wichtig zu sein (d. H. Arbeitsplatzspezifisch). Beim Herunterfahren des Arbeitsbereichs wurde auch die Datei org.eclipse.jdt.launching.prefs geändert. Zum Master gewechselt und für den Rest meiner Arbeitsbereiche wiederholt.
Es gab Komplikationen - so zum Beispiel:
Die Datei org.eclipse.jdt.core.prefs war im test Workspace vorhanden, während es im ursprünglichen Workspace (von wo ich importiert habe) die (binär identische) org.eclipse.jdt.core.prefs.bak gab.
Die Datei org.eclipse.pde.core.prefs wurde nicht importiert
Die Dateien org.eclipse.jdt.launching.prefs und org.eclipse.ui.workbench.prefs unterscheiden sich.
Nach dem fünften Arbeitsraum wurde ich darauf festgelegt, dass die Dateien
%Vor% werden erstellt, wenn Einstellungen importiert werden (in einem neuen Arbeitsbereich), dass die Datei .metadata\.plugins\org.eclipse.core.runtime\.settings\org.eclipse.pde.core.prefs nicht exportiert / importiert wird, dass die Datei .settings\org.eclipse.ui.workbench.prefs beim Import merge ist (nämlich die * ENABLED_DECORATORS * var bleibt so wie es ist) und org.eclipse.jdt.launching.prefs wird beim Schließen der Finsternis bearbeitet.
Es gibt weitere Komplikationen wie Dateien mit Projektreferenzen:
Zum Beispiel enthält die Datei org.eclipse.wst.sse.core.prefs Projektnamen aus dem Arbeitsbereich - ich habe dies als Bug (es wurde sehr schnell behoben!).
CDT erstellt eine Reihe von Dateien wie:
%Vor%die beim Export / Import blind synchronisiert werden. Dies ist tatsächlich ein viel komplizierterer Fall als der vorherige - meldete es auch .
> Tatsächlich wird alles, was Sie im .settings Verzeichnis haben, mitkopiert (vorausgesetzt, es hat ein .prefs Suffix). Dies rechtfertigt einen anderen Fehlerbericht.
Ähnliche Situationen treten in anderen Dateien auf, die arbeitsplatzspezifische Optionen enthalten - wie in org.eclipse.ui.ide.prefs , die Referenzen auf die Arbeitssätze enthalten - die eher arbeitsplatzspezifisch sind - oder in org.eclipse.ui.browser.prefs , die den internenWebBrowserHistory enthält - der normalerweise auch Arbeitsbereich ist spezifisch.
Wie auch immer, ich entschied mich für die harten Links - also normalisierte ich meine Einstellungen (es wäre viel einfacher, mit einem neuen Arbeitsbereich zu beginnen) und kopierte alle Einstellungen außer org.eclipse.wst.sse.core.prefs , cdt one und org.eclipse.pde.core.prefs (aus irgendeinem Grund wurde es nicht importiert. Das org.eclipse.ui.workbench.prefs , das ziemlich speziell ist, enthält auch die Verknüpfungen). Dann renne ich:
für meine Arbeitsbereiche.
Und raten Sie mal: Eklipse bricht harte Links . Ich habe versucht, weiche Links ( mklink %WORKSPACE_SETTINGS_DIR%\%%G %SETTINGS_DIR%\%%G ), aber auch keine Freude.
Ich musste das gesamte Einstellungsverzeichnis (zusammen mit allen problematischen Dateien, die ich erwähnt habe) hart verbinden (das ist wirklich keine Lösung). Eines Tages muss die Situation angegangen werden. Wie auch immer, hier ist das .bat , das ich benutzt habe:
Ich werde diesen Beitrag nach Bedarf aktualisieren
Sie können auch einen Blick auf Workspace Mechanic werfen, ein kleines Plugin, das von Google entwickelt wurde: Ссылка
UPDATE 28/11/12
Soweit ich das verstanden habe, müssen Sie einige Plugins-Einstellungen synchronisieren.
Das Wiki erklärt es sehr gut. Die folgenden Schritte empfehle ich Ihnen:
Damit sollten Sie in der Lage sein, Ihre Arbeitsbereichseinstellungen zu synchronisieren.
Bonus: Ich möchte die Einstellungen für die Workspace Mechanic auf die Dropbox legen, um sie zwischen den Teammitgliedern und / oder zwischen meinen Computern zu teilen. Hier finden Sie eine kleine Anleitung: Ссылка
Hoffe, das hilft.
Grüße
Es ist schade, dass es immer noch Workarounds dafür geben muss .. Ich habe ähnliche Schritte wie Sie gemacht, aber ich habe zuerst versucht, Hardlink und dann das Git Repository.
Für mich ist das Git-Repository die bessere Option, da ich meinen Arbeitsbereich über mehrere Arbeitsstationen synchronisieren möchte. Also für all die Leute, die immer noch nach einer Lösung suchen, habe ich gerade wie du angefangen:
Bisher habe ich ein .gitignore mit allen Dingen, die nicht benötigt oder unwichtig sind, erstellt. Mein Arbeitsplatz ist immer noch nicht 100% tragbar, aber fast ..
Was ich tun muss, wenn ich einen neuen Eclipse-Arbeitsbereich starte, ist nur ein git clone , das ist einfach. Der Nachteil ist, dass einige Einstellungen nicht verfolgt werden. Dies sind hauptsächlich GUI-Einstellungen, die fast immer auch arbeitsbereichsspezifische Einstellungen enthalten.
Mit diesem .gitignore können Sie also einen manuell synchronisierten Arbeitsbereich haben, der für die meisten Einstellungen funktioniert. Aber es muss beibehalten werden.
%Vor%Mein Tipp ist, dass Sie sich ansehen, was sich nach jedem Shutdown von Eclipse ändert. Das hat mir geholfen, diese Gitignore-Datei zu erstellen, und es funktioniert besser als ein Plugin.
Tags und Links eclipse