2009-08-12 5 views
48

Chúng ta thường sử dụng Eclipse cho một dự án Java cụ thể, nhưng gần đây tôi đã nhập dự án vào NetBeans để sử dụng các tính năng xây dựng hộp thoại của nó.Các tệp dự án NetBeans nào nên đi vào kiểm soát nguồn?

Vì tôi có thể sẽ quay lại điều này, tôi muốn lưu trữ các tệp dự án NetBeans vào kiểm soát phiên bản. Tuy nhiên, tôi không muốn cam kết các tệp là "của tôi" so với "dự án", tức là các tệp có cài đặt của riêng tôi sẽ xung đột với người dùng khác.

NetBeans tạo cấu trúc sau đây trong vùng dự án cấp cao nhất:.

nbbuild 
nb-build.xml 
nbproject 
    <various files> 
    configs 
    private 

Rõ ràng nbbuild là xây dựng sản lượng, do đó sẽ không đi trong File nb-build.xml dường như có khả năng, cũng như hầu hết nbproject. Tuy nhiên, nbproject/private cho thấy đó là "của tôi". Nhìn trộm "configs", nó không rõ ràng với tôi nếu đó là của tôi hoặc dự án ...

Bất cứ ai cũng có một số hướng dẫn?

Trả lời

47

NetBeans knowledge base article on project files & version control thảo luận về tệp dự án NetBeans, với tư vấn lỏng lẻo về tệp nào là dự án cụ thể (tức là có thể được chia sẻ thông qua kiểm soát phiên bản) và người dùng cụ thể.

Đây là phần nói về kiểm soát phiên bản:

Nếu dự án được kiểm tra ra một hệ thống kiểm soát phiên bản, build (hoặc nbbuild), dist (hoặc nbdist), và nbproject/private thư mục không nên kiểm tra vào hệ thống điều khiển phiên bản đó.

Nếu dự án nằm trong hệ thống kiểm soát phiên bản CVS, Subversion hoặc Mercurial, các tệp "bỏ qua" thích hợp được tạo hoặc cập nhật cho các thư mục này khi dự án được nhập.

Mặc dù nbproject/private cần được bỏ qua, nbproject phải được kiểm tra trong hệ thống kiểm soát phiên bản. nbproject chứa siêu dữ liệu dự án cho phép người dùng khác mở dự án trong NetBeans mà không phải nhập dự án trước.

+4

Mực được cung cấp bị hỏng. Về cơ bản nó làm cho câu trả lời này vô dụng. – Kenneth

+2

Tìm thấy bản sao của liên kết được lưu trữ tại https://web.archive.org/web/20090216193025/http://www.netbeans.org/kb/docs/java/import-eclipse.html. – Nathan2055

+1

Còn về 'nbactions.xml' thì sao? –

2

Không có.

Chỉ tệp nguồn, tập lệnh xây dựng và tài liệu không được tạo tự động (ví dụ: - đầu ra của các công cụ như JavaDoc và Doxygen) phải được kiểm tra vào kho lưu trữ. Không nên kiểm tra các tệp như dự án, tệp nhị phân và tài liệu đã tạo.

Lý do là hai lần. Trước tiên, bạn không muốn ghi đè cài đặt dự án của nhà phát triển khác bằng cài đặt của riêng bạn. Thứ hai, các nhà phát triển khác có thể không sử dụng cùng IDE như bạn (hoặc thậm chí là một IDE), vì vậy đừng cho họ nhiều hơn những gì họ cần để xây dựng (dự án hoặc tài liệu liên quan của nó) hoặc chạy dự án.

+9

Rõ ràng là sẽ không thêm đầu ra xây dựng (bao gồm cả JavaDocs). Nhưng tôi nghi ngờ câu trả lời tốt nhất là "không". Mỗi nhà phát triển sau đó sẽ cần phải thiết lập các thiết lập dự án chung cục bộ, bao gồm những thứ đơn giản như dirs nào là nguồn, hoặc mức JDK nào để xây dựng. Không chia sẻ loại thông tin thiết lập dự án đó sẽ khiến chúng tôi gặp rắc rối. Ví dụ, tôi viết mã làm việc cho 1.6 nhưng dự án của chúng tôi tàu cho 1.5. Tôi cam kết, và phá vỡ xây dựng. –

+0

Khi tôi nhập một dự án với Eclipse, nó không quan trọng đối với tôi để xác định các thư mục nguồn và JDK để xây dựng. Bên cạnh đó, phải có một kịch bản xây dựng mà làm cho tôi, vì tôi có thể không được sử dụng một IDE ở tất cả (nhưng thay vì một trình soạn thảo văn bản - Notepad ++, emacs, vim). Mỗi công việc mà tôi đã từng có mà sử dụng kiểm soát nguồn chỉ cam kết các tập tin nguồn và tài liệu do con người tạo ra cho kho lưu trữ và tôi đã không bao giờ nhìn thấy một vấn đề. –

+5

Tôi không đồng ý với điều này. Tôi nghĩ rằng nó làm cho mọi thứ dễ dàng hơn nhiều nếu tất cả các nhà phát triển trong một dự án đang sử dụng cùng một IDE và phiên bản. Các tệp dự án phải được kiểm tra - nghĩa là mỗi dev không phải nhảy qua các hoops thiết lập môi trường của chúng mỗi lần chúng cần làm việc trên nguồn. Nếu tất cả mọi người kiểm tra dự án và dự án phụ thuộc và JAR vào cùng một vị trí hoặc cấu trúc đường dẫn tương đối thì họ có thể thanh toán và nhấp vào xây dựng trong một bước. Quá nhiều thời gian lãng phí nếu mọi người phải định cấu hình lại dự án và sửa chữa các phụ thuộc bị hỏng tất cả thời gian –

19

Nó chỉ ra rằng cả hai Thomas & Petercardona là chính xác, theo một cách. NetBeans khuyên bạn chỉ nên nhập mã nguồn và/hoặc tài liệu. Oh và thư mục nbproject nhưng không phải là thư mục * nbproject/private **.

Từ NetBeans Knowledge Base article on importing Eclipse projects:

cân nhắc điều khiển phiên bản

Nếu dự án được kiểm tra ra một hệ thống kiểm soát phiên bản , xây dựng (hoặc nbbuild), dist (hoặc nbdist), và không nên kiểm tra các thư mục nbproject/private vào hệ thống kiểm soát phiên bản đó.

Nếu dự án là thuộc CVS, Subversion, hoặc Mercurial hệ thống kiểm soát phiên bản , thích hợp "bỏ qua" các tập tin được tạo ra hoặc cập nhật cho các thư mục khi dự án được nhập khẩu.

Mặc dù nbproject/tin nên bỏ qua, nbproject nên được kiểm tra vào hệ thống kiểm soát phiên bản. nbproject chứa siêu dữ liệu dự án cho phép người dùng khác mở dự án trong NetBeans mà không cần phải nhập dự án trước.

+2

Đó là cùng một liên kết tôi đã đăng ở trên, phải không? Tôi nghĩ có sự phân biệt giữa * chỉ nhập * nguồn và * kiểm tra * các tệp dự án. Như tôi đã đọc nó, trước đây có nghĩa là đưa các tệp vào IDE NetBeans, sau này có nghĩa là đưa tệp vào kiểm soát phiên bản và bao gồm các tệp thiết lập dự án. Câu hỏi của tôi liên quan đến câu hỏi sau. Tôi muốn chia sẻ các tập tin kiểm soát cách xây dựng được sản xuất (vị trí jar tiêu chuẩn, mức jdk), nhưng không kiểm soát những thứ như tùy chọn định dạng, bố cục cửa sổ IDE, v.v. –

2

Như thử nghiệm với Netbeans 6.8, chỉ project.xml, configurations.xml và makefile chính (một trong những tùy biến trong dir mẹ của 'nbproject' dir, với các định nghĩa trước/sau mục tiêu) phải được phân phối thông qua kho. Tất cả các tệp khác sẽ được tự động tạo lại bởi Netbeans (Makefile-impl.ml, Makefile-variables.ml, tất cả các Makefile-$CONF, Package-$CONF.bash). Các 'tư nhân' dir cũng nên được bỏ qua, rõ ràng.