.classpath dan .project - periksa ke kontrol versi atau tidak?

Saya menjalankan proyek java open source yang terdiri dari beberapa modul dalam pohon dependensi. Semua modul tersebut adalah subdirektori dalam repositori subversi. Untuk pendatang baru di proyek kami, banyak pekerjaan untuk mengatur semua itu secara manual di eclipse.

Tidak semua developer kami menggunakan eclipse. Namun demikian, kami mempertimbangkan untuk hanya memeriksa file .classpath dan .project untuk membantu pendatang baru memulai. Apakah ini ide yang bagus? Atau akankah itu menyebabkan konflik konstan dalam file-file itu? Adakah cara alternatif untuk membuat proyek mudah disiapkan di eclipse?

Jelas ya, seperti yang saya katakan di " Apakah Anda menyimpan file proyek Anda di bawah kontrol versi? "

"Muat, siapkan, pergi."

Tetapi ... ini sebenarnya hanya berlaku untuk setelan Eclipse3.5 terbaru, di mana jalur build mendukung jalur relatif :

Dan Eclipse3.6 akan lebih baik, karena mendukung jalur relatif untuk variabel jalur di Linked Resources:

(sejak 3.6M5)

Jelas tidak - umumnya ide yang buruk untuk mendistribusikan file proyek melalui subversi. Terutama karena seseorang mungkin memodifikasinya dengan cara yang aneh. Halaman yang bagus dalam dokumentasi proyek adalah ide yang jauh lebih baik. Proyek kami juga memiliki banyak modul dan pengaturan yang kompleks. Kami telah menyiapkan halaman pertemuan yang menjelaskan cara memulai proyek di setiap IDE populer - IntelliJ, Eclipse, NetBeans. File README di Subversion berisi info yang sama.

Saya memilih tidak, tapi itu karena saya biasanya akan menghasilkan file-file ini dari maven

Dalam pengalaman saya, tidak termasuk kasus terbatas di mana pengaturan lokal murni terlibat, semuanya harus dalam kendali sumber. Hukum pengendalian sumber adalah bahwa segala sesuatu yang didorong masuk harus diharapkan bekerja oleh mereka yang menarik diri. Sayangnya, gerhana seringkali menyebabkan hal-hal seperti ini menjadi .classpath:

    <classpathentry kind="con" 
      path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/Java SE 7"/>

Jadi di Mac saya ini berfungsi, dan mungkin seseorang di Mac memiliki JRE yang sama, tetapi ini tidak akan berfungsi untuk orang lain.

Juga, tidak ada cara mudah untuk mengatasi ini. Eclipse akan selalu menambahkannya. Saya INGIN memiliki file .classpath di sana, karena ada beberapa JAR pihak ke-3 di folder lib kami di mana kami peduli tentang pembuatan versi, jadi kami membiarkannya di sana sehingga pengembang baru tidak perlu mendapatkannya . Kami pindah ke sistem terkelola, tetapi masih memiliki dependensi terkelola + tak terkelola yang diperiksa. Ini berarti semua pengembang hanya perlu memastikan dua direktori ada di direktori mereka .classpath. Tetapi lebih baik daripada harus memperbaiki JRE Anda setiap kali Anda menarik dan memiliki perubahan di .classpath Anda setiap kali Anda berkomitmen.

Eclipse melakukan beberapa hal baik lainnya untuk Anda. File .project biasanya akan sama di semua instance, jadi sertakan itu. Tetapi hal terbaik tentang kontrol sumber untuk gerhana adalah pengaturan Konfigurasi Jalankan. Di bawah tab "Umum" di dialog Jalankan Konfigurasi, simpan konfigurasi agar muncul untuk kolega Anda di bawah daftar favorit untuk Debug dan Jalankan. Bagi saya, banyak .launchfile masuk ke .settingsdirektori, jadi kita semua bisa menggunakannya.

Jadi saya katakan: .settingsdirektori masuk ke kontrol sumber untuk konfigurasi peluncuran (kecuali * .prefs)

.classpath tetap keluar

.project masuk.

Saya akan memeriksa file-file ini untuk memulai bagi pengguna baru semudah mungkin. Paling baik pengguna harus memeriksa proyek dan harus dapat menjalankannya tanpa pengetahuan tambahan. Untuk file ini aturannya sama dengan file lainnya dalam proyek: tangani dengan hati-hati. Anda tidak boleh menempatkan jalur absolut di kode sumber, selain itu Anda harus di file konfigurasi.

Jika file diperiksa sedemikian rupa sehingga proyek berjalan dari awal, seharusnya tidak ada banyak kekuatan untuk mengubahnya.

Saya akan merekomendasikan agar Anda memeriksa file ke dalam subversi JIKA mereka tidak berisi jalur absolut dan data lain yang akan mengikatnya secara langsung ke lingkungan pengembang tunggal.

Jika file memang berisi path absolut dan sejenisnya, README akan menjadi pilihan yang lebih baik.

Ya, pastikan Anda memeriksanya, tetapi pastikan Anda mendokumentasikan dependensi jalur apa pun dan menghindari jalur absolut jika memungkinkan.

Jika Anda tidak memeriksanya, maka siapa pun yang memeriksa proyek perlu membuat ulang semua pengaturan tersebut, yang mengganggu dan berpotensi rawan kesalahan.

Beberapa pengaturan kompleks mungkin lebih baik ditangani oleh skrip untuk menghasilkan file-file ini, tetapi biasanya lebih baik untuk hanya memeriksanya.