Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Projekt-Einstellungen von Eclipse mit subversion verwalten
ich möchte Eclipse-Projekte mit subversion verwalten (subversion-Plugin). Habe mich auch einige Zeit eingelesen und es funktioniert soweit auch ganz gut. Es gibt nur noch ein paar Details, die ich nicht verstehe.
Vor allem geht es darum, dass bestimmte Dateien außerhalb des src-Verzeichnisses eingecheckt bzw. nicht eingecheckt werden sollen. Im Moment habe ich ohne händische Anpassungen folgenden Stand:
bin-Verzeichnis => wird eingecheckt (erscheint mir nicht notwendig?!?)
.settings => wird eingecheckt (notwendig? Wenn ja, warum?)
.classpath => wird nicht eingecheckt. Fände ich aber sinnvoll
.project => wird nicht eingecheckt
Wenn ich die Tutorials richtig verstehe, sind da Einträge lokal in der subversion-config-Datei notwendig. Das mag bei einigen Einstellungen (Dateien mit svn-Eigenschaften versehen) sinnvoll sein. Aber wie ist das bei meinen Einstellungen? Muss das in dem Fall jedes Teammitglied machen? Das Prinzip habe ich überhaupt nicht verstanden ???:L
Ich fände es sehr angenehm, wenn Projekt-Einstellungen und classpath zentral abgelegt sind. Dann wäre sichergestellt, dass alle immer mit den gleichen Einstellungen arbeiten. Muss dann auch die Eclipse- und JDK-Version bei allen identisch sein?
Bleibt für mich aber immer noch die Frage mit dem bin-Verzeichnis bzw. den settings. Warum ist es sinnvoll, das bin-Verzeichnis einzuchecken? Hat das Einchecken der .settings irgendwelche Konsequenzen für Abhängigkeiten der Teammitglieder untereinander?
Wenn ich die Tutorials richtig verstehe, sind da Einträge lokal in der subversion-config-Datei notwendig. Das mag bei einigen Einstellungen (Dateien mit svn-Eigenschaften versehen) sinnvoll sein. Aber wie ist das bei meinen Einstellungen? Muss das in dem Fall jedes Teammitglied machen? Das Prinzip habe ich überhaupt nicht verstanden ???:L
Bedeutet hier auf projektName die svn:ignore Property mit folgendem Inhalt:
Code:
.classpath
.project
.settings
bin
Wenn Du mit Maven arbeitest dann auch noch
Code:
.classpath
.project
.settings
target
Dass checkst Du dann ein und jeder der das Projekt auscheckt bekommt die Einstellung...
Das bin Verzeichnis würde ich nicht einchecken, da es bei Bedarf von Eclipse erstellt wird und die compilierten Klassen etc. enthält... (Bei Maven target Verzeichnis).
Das .settings Verzeichnis würde ich nicht einchecken, das es Einstellungen von Eclipse beinhaltet... (bei Arbeit mit Maven auf keinen Fall) OHNE Maven müsst Ihr das entscheiden...
Einstellungen an der Subversion-Config sind nicht notwendig und auch nicht sinnvoll...
IMHO sollten .project & .classpath bei nicht-mavenisierten Projekten eingecheckt werden, sonst muss man beim auschecken jedesmal den New Project Wizard bemühen.
Wobei wenn man den Classpath mit eincheckt, dann immer ein eigenes Library Projekt haben sollte, in das man die Jars packt, damit der Classpath relativ bleibt. Sonst haste gleich mal Schwirigkeiten, weil jeder immer einen anderen absoluten Path zur Library eincheckt.
Danke euch drei. Vor allem das Nutzen des "New Project Wizzards" ist nämlich der Hintergrund meiner Anfrage. Werde mal testen, ob das mit den zusätzlich eingecheckten Dateien besser zu verwalten ist.
Dass die Pfade zu den lib-Dateien passen wird kein großes Problem sein.
Verstehe ich es richtig, dass es auch mit eingechecktem .classpath/.project trotzdem nicht notwendig ist, dass alle Entwickler die selbe Eclipse-Version nutzen?
Was noch zu beachten ist, viele Workspace Einstellungen lassen sich auch Projektspezifisch setzen, was du dann auch machen solltest, damit für das Projekt keiner an seinen Workspace rumschrauben muss.
Verstehe ich es richtig, dass es auch mit eingechecktem .classpath/.project trotzdem nicht notwendig ist, dass alle Entwickler die selbe Eclipse-Version nutzen?
So, Umstellung ist abgeschlossen und es hat alles gut geklappt. Danke euch allen für die Antworten. Das hat mir das notwendige Verständnis für die letzten Kleinigkeiten gegeben