2010-02-19 19 views
7

Was muss ich neben dem offensichtlichen (src, dist) zu meinem Versionskontrollsystem von einem NetBeans Java Projektverzeichnis hinzufügen? Kann ich das gesamte Build-Verzeichnis löschen? Sollte ich das nbproject-Verzeichnis hinzufügen, während ich an demselben Projekt auf einem anderen Rechner arbeite?NetBeans und Java: Was zur Versionskontrolle hinzufügen?

Ich würde gerne mindestens das Build-Verzeichnis löschen, da die Anwendung nicht kompiliert, bekomme ich Probleme mit Git, da es eine Tonne von Dateien fehlt, die git als entfernt betrachtet.

Antwort

5

Hinweis: Diese Antwort gilt für NB 6.8 (was ich gerade benutze) und wahrscheinlich auch für die meisten 6.x-Versionen, die wahrscheinlich in der freien Natur vorkommen.

Die kurze Antwort: Verwenden Sie den Menüeintrag 'In Repository importieren', um das erste Einchecken durchzuführen. Die IDE wird die Dinge einchecken, die sie für notwendig hält.

Es ist ein bisschen schwer zu finden. Wählen Sie Ihr Projekt im Projekt-Explorer. Öffnen Sie das Menü Team aus der Menüleiste. Sobald Sie darauf klicken, sehen Sie, so etwas wie:

Kenai> 
------ 
CVS> 
Mercurial> 
Subversion> 
______ 

Der Import in Element ist ein Unterelement von CVS/Mergcurial/Subversion.

Wenn Sie Sie den Check-in zu tun ‚von Hand‘ hier begangen werden, ist eine Liste der Dinge, die IDE in der Regel in ein Repository geschoben:

  • src dir (und alle Sub-Dateien und Ordner)
  • Test dir (und alle Unterdateien und Ordner)
  • Verzeichnis nbproject dir (und alle Dateien und Ordner - mit Ausnahme des 'privaten' Ordner und dessen Inhalt)
  • build.xml
  • manifest.mf
+0

Ausgezeichnete Antwort und genau das, was ich gesucht habe. Ich benutze Git, also muss ich sehen, ob dein Tipp damit funktioniert. Wenn ich das gesagt habe, mache ich das lieber von Hand, aber es ist eine gute Idee, mit dem Import-Teil zu beginnen. – Makis

+0

NB hat keine Unterstützung für git 'out of the box' ... Sie werden wahrscheinlich dieses Plugin (http://code.google.com/p/nbgit/) sehen wollen, um zu sehen, ob es nützlich ist. – vkraemer

+0

Ich hatte das bereits auf einem Computer installiert und einfach auf diesem installiert und es sieht so aus, als ob diese Funktion auch mit git verfügbar ist. – Makis

1

Sie Quellcode, Ressourcendateien (Bilder, Konfigurationsdateien, etc) und Build-Skripte (in Netbeans alle Ameisen Build-Dateien) sollten im Repository sein.

Legen Sie das Verzeichnis dist/build nicht dort ab. Es ist im Allgemeinen keine gute Idee, erstellte Artefakte (Klassendateien, das Jar des Projekts usw.) in die Quellcodeverwaltung zu übernehmen.

Das Teilen der Netbeans-Metadaten kann jedoch nützlich sein, wenn Sie an demselben Projekt von verschiedenen Computern aus arbeiten.

+0

Ne vorsichtig bei der Arbeit in einer heterogenen Umgebung mit diesem. Wie Developer A ist auf Mac und Developer B ist auf Windows. Dies könnte zu Problemen führen. – er4z0r

+0

Austausch von Metadaten kann nützlich sein, aber es kann auch ein Schmerz sein, wenn jemand ihre persönlichen Einstellungen ändert und jeder im Team bekommt sie –

+0

Also ... kann ich das gesamte Build/Verzeichnis dann verlassen? Und was sind die Ant-Dateien, die ich hinzufügen sollte? build.xml? – Makis

0

Sie sollten so viel wie möglich unter Versionskontrolle setzen. Die Versionierung von etwas, das sich nicht ändert, hat keine Kosten. Wenn Sie später feststellen, dass Sie einen Zustand, den Sie benötigen, nicht wiederherstellen können, ist das fatal. Speicher ist sehr billig, Textdateien sind sehr klein, die meisten SVM-Speicherdeltas, die in Größe und Geschwindigkeit marginal sind.

Agile Praktiken enthalten auch explizit dies. Neben Quellcode und Projektdateien sollten Sie auch Skripte, Datenbankschemas und -spionate, Konfigurationen, Dokumentationen (!), Testdateien, abhängige Bibliotheken, Todos, die Projektwebseite erstellen ... Natürlich ist es manchmal schwierig, dies beispielsweise zu sagen Ein virtuelles Computer-Image unter Versionskontrolle (binär), reguläre Snapshots könnten dafür geeigneter sein. Aber wenn Sie sich jemals fragen, sollte ich dies unter Versionskontrolle setzen, ist die Antwort fast immer ja, sollten Sie. (Nach dieser Praxis macht es auch einfacher, Entscheidungen über die Versionierung zu treffen.)

+0

Stellen Sie keine Dinge, die durch Ihren Build-Prozess generiert wurden, in das SOURCE CODE-Repository. Es macht es anderen nur schwer, das Projekt zu überprüfen und zu erstellen. Überprüfen Sie die fertigen Builds an einem anderen Ort. –

2

Es gibt eine ähnliche Frage über Eclipse vor einer Weile gestellt, und obwohl einige der Besonderheiten der IDE kann anders sein, das Prinzip, was in Version zu setzen Kontrolle ist gleich.

Grundsätzlich alles, was Sie nicht generieren.

Ausnahmen davon können die abhängigen Gläser sein. Ob Sie sie einschließen oder nicht, hängt davon ab, ob Sie einen gemeinsamen Speicherort für die Bibliothek haben, auf den andere verweisen können oder nicht. Gewöhnlich hatte ich immer Umgebungen mit gemeinsamen Standorten, anstatt sie für jedes Projekt unter Kontrolle zu halten (schließlich, wie oft möchten Sie log4j und all seine Version unter Quellcodeverwaltung speichern). Natürlich verwenden wir jetzt maven, damit das Problem behoben wird (siehe meine Antwort zu Maven und Eclipse in der gleichen Frage, die oben verlinkt ist).

0

Alles benötigt, um das Projekt von Grund auf neu zu erstellen und auszuführen.

Stellen Sie sicher, dass Sie auch Ihr lib-Verzeichnis hinzufügen. Ich hasse es absolut, wenn ich Sachen aus der Versionskontrolle heraushole und alle abhängigen JAR-Dateien nirgends zu finden sind, was mich dazu bringt, weiter zu raten, bis ich alle ClassNotFound-Ausnahmen gelöst habe. Fügen Sie Ihr Build-Verzeichnis oder Ihr Netbeans-Build-Skript nicht hinzu, es sei denn, Sie sind nur an die Ausführung von NetBeans gebunden. Eine weitere Alternative ist das Hinzufügen eines Build-Skripts (nicht Netbeans).

Verwandte Themen