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.
Eclipse und überflüssige .svn Ornder (von TortoiseSVN)
ich arbeite unter Eclipse und verwende hierzu getrennte Source und Classordner (also wie gehabt: src und bin).
Für mein Repository verwende ich TortoiseSVN, also KEIN Eclipse-Plugin!
TortoiseSVN legt in jeden Ordner, der versionierte Ordner oder Dateien enthält, einen .svn Ordner an, der die Versionierungsinformationen enthält. Wurde seit dem letzten Commit lokal etwas geändert, sieht man im Explorer (ich arbeite unter Windows Vista) auf dem Ordnersymbol ein rotes Ausrufezeichen, anderenfalls einen grünen Haken.
Da Eclipse alle .java-Dateien in einem beliebigen sub-Ordner von src an die korrespondierende Stelle von bin als .class-Datei kopiert, werden neben 1-zu-1 Kopien von anderen Dateien (wie z.B. Textdateien) leider auch die .svn Ordner in den bin Ordner kopiert.
Das hat zu Folge, dass im Windowsexplorer stets der bin-Ordner als geändert markiert wird (rotes Ausrufezeichen), obwohl ich TortoiseSVN mitgeteilt habe, dass dieser Ordner ignoriert werden soll.
Das Problem ist eigentlich völlig klar: Tortoise glaubt, der bin-Ordner hätte sich verändert, weil in diesem ein .svn-Ordner liegt, der sich aber eigentlich auf den src-Ordner bezieht.
Aber wie kann ich dieses Problem lösen? Wie kann ich Eclipse mitteilen, dass es mir diese .svn Ordner bitte NICHT von den src Ordnern zum bin Ordner kopieren soll?
In einem Eclpise-Forum wurde die folgende (leider nicht funktionierende) Antwort gegeben:
Man solle einen Ignore Pattern hinzufügen (Titel der Eclipse-Dokumentation: Creating a global ignore pattern).
Doch wie gesagt: Obwohl ich diesen Pattern angelegt habe, werden die überflüssigen Ordner kopiert... Weiß mir jemand Rat?
Installiere ein Eclipse-Plugin für SVN, du musst das Plugin ja nicht verwenden, aber es wird Eclipse "erklären" wie es mit diesem .svn Ordner umzugehen hat.
Installiere ein Eclipse-Plugin für SVN, du musst das Plugin ja nicht verwenden, aber es wird Eclipse "erklären" wie es mit diesem .svn Ordner umzugehen hat.
Danke für den Tipp.
Ich habe das Plugin erfolgreich installiert (ich kann die SVN Repository Exploring-Perspective öffnen, hat also alles geklappt). Aber dennoch kopiert mir Eclipse die .svn-Ordner...
Andere Ideen? Oder habe ich gar etwas falsch gemacht? Reicht es womöglich nicht aus, das Plugin lediglich zu installieren, um den gewünschten Effekt zu erzielen?
Vergiss die Sache mit Tortoise. Verwende Subversive für die Versionierung in Eclipse. Andere Programme dürfen den Workspace nicht verändern.
Davon abgesehen zerstören verschiedene SVN Clients auf den gleichen Daten sich gegenseitig die Meta Informationen.
Vergiss die Sache mit Tortoise. Verwende Subversive für die Versionierung in Eclipse. Andere Programme dürfen den Workspace nicht verändern.
Davon abgesehen zerstören verschiedene SVN Clients auf den gleichen Daten sich gegenseitig die Meta Informationen.
Hm, ich möchte auf Tortoise allerdings nur ungern verzichten, finde das Programm ziemlich gut und ich möchte innerhalb von Eclipse eigentlich kein Versionierungstool nutzen. Ein wenig Handarbeit (Tortoise im Explorer) finde ich deutlich angenehmer und sicherer (da ich von Hand bestimme, wann was hochgeladen wird, ohne beim Programmieren noch ein Tool im Hintergrund zu haben).
Gibt es also keine Lösung meines ursprünglichen Problems (also Eclipse zu sagen, dass es bestimmte Dateien und Ordner bitte nicht in den bin Ordner kopieren soll)?
Das größte Problem mit einem externen Client wie Tortoise ist, dass wenn du Refactorst(ändern von Paketennamen, Klassennamen, etc pp), keine Historie übernommen wird, sondern schlicht die alten Dateien/Ordner gelöscht werden und neue angelegt werden, ohne nachvollziehbaren Zusammenhang für das SCM.
Deswegen am besten den Client in der IDE nutzen, nur so bleibt man konsistent.
Also gut, ihr habt viele gute Argumente.
Ich denke darüber nach...
Ich hatte mir vorher (um den Tipp von Beni umzusetzen) das Eclipse-SVN Plugin Subclipse installiert.
Ihr sprecht nun hingegen von subversive. Ich gehe davon aus, dass dies ein Alternativplugin ist.
Welches ist zu empfehlen? (Um diese Diskussion hier bald abzuschließen)
Ist relativ. Einige Argumente kann ich folgen, z.B. das es sinnvoll ist wenn man seine Sources innerhalb der IDE verwaltet. Die SVN-Plugins sind recht ausgereift.
Aber: es gibt in einem Projekt noch viele andere Dateien, die versioniert werden und die in meine IDE nichts verloren haben. Dokumenten, Beschreibungen, UML-Diagramme, usw. Ein Tool, dass also unabhäng ist von der IDE macht also schon sinn.
Das Argument, dass Historie verloren geht wenn Verzeichnisse oder Dateien umbenannt werden, ist absoluter unfug. Und das die Clients sich gegenseitug die Meta-Informationen kaputt machen habe ich auch noch nicht erlebt. Wenn ein Client das macht, dann soll er von der Platte runter. Du musst natürlich schon darauf achten, dass die SVN-Clients alle passend zur Version deines Repositories bzw. Working Copy sind.
Ich benutze in meinem aktuellen Projekt parallel Eclipse und IntelliJ IDEA, beide mit entsprechenden SVN-Plugins und außerdem Tortoise "außerhalb" die beiden IDE. Ich hatte bislang noch keine Probleme.
Die Antwort auf deine Ursprungsfrage hast du aber noch nicht bekommen. Ich könnte jetzt ganz ketzerisch sagen, nimm IntelliJ IDEA statt Eclipse, dann hast du das Problem gar nicht ;-)
In Eclipse ist es ein wenig aufwendiger aber es geht trotzdem: Wenn du in den Projekt-Properties im "Java Build Path" unter "Source" schaust und das Source-Verzeichnis aufklappst, dann erscheint u.A. "Excluded". Anklicken und dann auf Edit. In der folgenden Maske neben "Exclusion Patterns" auf Add klicken. Als Pattern gibst du ".svn/**" ein (ohne Quotes). Einmal rebuilden et voila, die .svn-Verzeichnisse sind futsch.
Allerdings musst du das für alle Source-Verzeichnisse in alle Projekten machen. Das geht dann natürlich auch per Search and Replace, direkt in den .classpath-Dateien. Bei 14 .classpath-Files mit je 3 oder 4 Source-Verzeichnisse ist das angenehmer.
Aber: es gibt in einem Projekt noch viele andere Dateien, die versioniert werden und die in meine IDE nichts verloren haben. Dokumenten, Beschreibungen, UML-Diagramme, usw. Ein Tool, dass also unabhäng ist von der IDE macht also schon sinn.
Schon mal die Eclipse Refactoring Tools benutzt um Packete/Klassen umzubennen?
Da dies rein in Eclipse passiert und Tortoise nichts davon mitbekommt ist die Historie in diesem Falle weg, solange kein SVN Plugin in Eclipse dafür benutzt wird. :roll:
Sicherlich macht es keinen Sinn wenn dieses Tool parallel auf den gleichen Dateinen arbeitet wie das Eclipse Plugin.
Abgesehen davon, wenn diese Dateien nicht zum Quellcode gehören, was machen sie dann beim Quellcode inder IDE???
Diese Dateien liegen natürlich in eigene Ordner und in der IDE sehe ich sie nicht. Aber auch diese Dateien wollen aktualisiert werden, also habe ich Tortoise und mache damit ein Update auf dem Projekt-Rootverzeichnis. Damit werden meine sonstige Dateien und auch sämtliche Source-Dateien aktualisiert.
Ich hatte bislang noch keine Probleme.
maki hat gesagt.:
Soso, und deswegen ist jeder der andere Erfahrungen gemacht hat im Unrecht?
Den kleinen Satz hast du aus seinem Zusammenhang gezogen. Ich hatte noch keine Probleme mit Konstellationen wo mehrere (hier 3) unterschiedliche SVN-Clients auf dem selben Working Copy arbeiten. Seit es SVN gibt in viele unterscheidliche Projekte und mit mir sämtliche Kollegen aus den Projektteams.
Warum auch sollte es problematisch sein? Das Format der Metadata liegt fest. Nach wie vor, wenn ein Client das zerschießt, dann ist der Client Buggy und sollte nicht benutzt werden.
Das Argument, dass Historie verloren geht wenn Verzeichnisse oder Dateien umbenannt werden, ist absoluter unfug.
Ach ja?
maki hat gesagt.:
Schon mal die Eclipse Refactoring Tools benutzt um Packete/Klassen umzubennen?
Da dies rein in Eclipse passiert und Tortoise nichts davon mitbekommt ist die Historie in diesem Falle weg, solange kein SVN Plugin in Eclipse dafür benutzt wird. :roll:
Maki, du hast vollkommen recht weil wenn ich mit OS-Mitteln eine Datei umbenenne steht das natürlich nicht in den Metainformationen von SVN und SVN macht daraus ein schlichtes Delete/Add.
Natürlich muss ich, um die Historie zu bewahren, eine Datei mittels SVN-Befehl umbenennen. Dazu kann ich in einer IDE mit einem Plugin arbeiten und mit Tortoise mittels Rechte Maustaste - Tortoise - Rename.
Wenn ich in der Dateiexplorer oder in einer DOS-Shell eine Datei umbenenne, habe ich auch keine Historie.
maki hat gesagt.:
Da dies rein in Eclipse passiert und Tortoise nichts davon mitbekommt ist die Historie in diesem Falle weg
Nur das es nicht Tortoise ist, der das mitbekommen muss. Mit SVN-mitteln umbenennen bedeutet, dass in den Metadaten in dem .SVN-Verzeichnis entsprechende Informationen hinterlegt werden, die beim Commit (egal mit welchem Client) berücksichtigt werden. Es findet immer noch ein Delete/Add statt, nur das beim Add die URL der Ursprungsdatei dazu geschrieben wird.
Hier gibt es eine gute Anleitung, wie man es unter Ganymede einrichtet. Bin neulich darauf gestossen,
verwende aber lieber TortoiseSVN, da ich in SVN nicht nur die eigentlichen Java-Projekte habe, sondern
den ganzen Rest ebenfalls. Alles unter einem gemeinsamen Root-Verzeichnis.
