Những tệp Eclipse nào phù hợp để đặt dưới sự kiểm soát nguồn, ngoài các nguồn rõ ràng?
Trong dự án của tôi, cụ thể, tôi đang tự hỏi về:
.metadata / *
project-dir / .project
project-dir /. classpath
project-dir / .sinstall / *
Nếu có bất kỳ trong số này mà nó phụ thuộc, xin vui lòng giải thích hướng dẫn của bạn.
Câu trả lời:
Siêu dữ liệu không nên được quản lý trong kiểm soát nguồn. Chúng chứa hầu hết dữ liệu liên quan đến không gian làm việc của bạn .
Ngoại lệ duy nhất là các .launchtệp XML (định nghĩa trình khởi chạy).
Chúng được tìm thấy trong
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
Và chúng nên được sao chép vào thư mục dự án của bạn: Khi dự án của bạn được làm mới, các cấu hình đó sẽ được hiển thị trong hộp thoại "Chạy cấu hình".
Bằng cách đó, các tệp tham số khởi chạy cũng có thể được quản lý vào SCM.
(Cảnh báo: Không bỏ chọn tùy chọn "Xóa cấu hình khi tài nguyên được liên kết bị xóa" trong bảng tùy chọn Chạy / Khởi chạy / Khởi chạy cấu hình : Thông thường, xóa mềm dự án để nhập lại - để buộc tái cấu trúc lại siêu dữ liệu nhật thực. Nhưng tùy chọn này, nếu được chọn, sẽ xóa các tham số khởi chạy chi tiết của bạn!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
phải ở trong SCM của bạn (đặc biệt .projectvà .classpaththeo tài liệu Eclipse ).
Mục tiêu là bất kỳ ai cũng có thể kiểm tra / cập nhật không gian làm việc SCM của mình và nhập dự án Eclipse vào không gian làm việc của Eclipse.
Vì thế, bạn muốn chỉ sử dụng các đường dẫn tương đối trong. Classpath của mình, sử dụng các tài nguyên được liên kết .
Lưu ý: sẽ tốt hơn nếu project-dirtham chiếu đến thư mục dự án "bên ngoài", không phải là thư mục được tạo trong không gian làm việc nhật thực. Bằng cách đó, hai khái niệm (không gian làm việc nhật thực so với không gian làm việc SCM) được phân tách rõ ràng.
Như ipsquiggle đề cập trong bình luận, và như tôi đã nói trong một câu trả lời cũ , bạn thực sự có thể lưu cấu hình khởi chạy dưới dạng tệp được chia sẻ trực tiếp trong thư mục dự án của bạn. Tất cả cấu hình khởi chạy sau đó có thể được phiên bản như các tệp dự án khác.
(Từ bài đăng trên blog Mẹo: Tạo và chia sẻ Cấu hình khởi chạy từ KD)
.projectbị bỏ qua trong thời gian chỉ dành cho không gian làm việc của bạn. Nhưng đừng tước bỏ tất cả những người dùng khác của định nghĩa dự án Eclipse chung mà họ có thể nhanh chóng nhập vào không gian làm việc Eclipse của họ, chỉ vì bạn tình cờ có thêm một định nghĩa chỉ phù hợp với nhu cầu của bạn lúc này.
Tôi hiện đang làm việc trên một dự án nơi chúng tôi có các tệp .project và .cproject dưới sự kiểm soát nguồn. Ý tưởng là các cài đặt liên quan đến đường dẫn thư viện và các chỉ thị liên kết sẽ lan truyền trong toàn đội.
Trong thực tế, nó không hoạt động tốt, hầu như luôn luôn quay trở lại trong trạng thái mâu thuẫn cần được giải mã bên ngoài nhật thực và sau đó dự án đóng lại và mở lại để những thay đổi có hiệu lực.
Tôi không khuyên bạn nên giữ chúng trong kiểm soát nguồn.
Không có gì đáng nói khi các tệp cấu hình CDT không thân thiện với kiểm soát nguồn. Có một lỗi được gửi cho các tệp .cproject thay đổi rất thường xuyên và gây ra xung đột, hãy xem Chia sẻ tệp cdt-project trong kho lưu trữ luôn gây ra xung đột .
Một số dự án, như những dự án sử dụng Maven, muốn tạo các tệp .project dựa trên POM.
Điều đó nói rằng, ngoài điều đó - .metadata KHÔNG nên nằm trong kiểm soát nguồn. Dự án của bạn sẽ phải đưa ra quyết định về việc dự án / cài đặt dự án có làm hay không, dựa trên cách bạn lên kế hoạch quản lý các tiêu chuẩn và như vậy. Nếu bạn có thể tin tưởng một cách trung thực các nhà phát triển của mình để thiết lập môi trường của họ dựa trên tiêu chuẩn và bạn không phải tùy chỉnh bất kỳ điều gì đặc biệt cho bất kỳ dự án nào, thì bạn không cần phải đặt chúng vào. Tôi, tôi khuyên bạn nên định cấu hình cụ thể mọi dự án . Điều này cho phép các nhà phát triển làm việc trên nhiều công cụ của nhiều dự án trong cùng một không gian làm việc mà không phải thay đổi cài đặt mặc định qua lại và nó làm cho các cài đặt rất rõ ràng, ghi đè bất kỳ cài đặt mặc định nào của chúng phù hợp với tiêu chuẩn của dự án.
Chỉ có phần khó khăn là đảm bảo tất cả chúng đều đồng bộ. Nhưng trong hầu hết các trường hợp, bạn có thể sao chép các tệp .sinstall từ dự án này sang dự án khác. Nếu có bất kỳ điều gì bạn đặc biệt không muốn trong kiểm soát nguồn, hãy thực hiện tương đương với cài đặt svn: bỏ qua cho họ, nếu SCM của bạn hỗ trợ.
Tệp. Classpath chắc chắn là một ứng cử viên tốt để kiểm tra scm vì việc cài đặt nó bằng tay có thể rất nhiều công việc và sẽ khó khăn cho các nhà phát triển mới tham gia vào dự án. Đúng là nó có thể được tạo từ các nguồn khác, trong trường hợp đó bạn sẽ kiểm tra nguồn khác.
Đối với cài đặt. Nó phụ thuộc vào cài đặt. Đây là một khu vực màu xám, nhưng một số cài đặt gần như là bắt buộc và thật thuận tiện để có thể kiểm tra một dự án, nhập nó trong Eclipse và có mọi thứ được thiết lập và hoạt động tốt.
Do đó, tại dự án của chúng tôi, chúng tôi duy trì một bản sao của thư mục .sinstall có tên CVS.sinstall và chúng tôi có một nhiệm vụ chống sao chép nó vào .sinstall. Khi bạn nhận được dự án từ CVS, bạn gọi tác vụ ant 'eclipsify' để sao chép các cài đặt mặc định sang thư mục .sinstall mới. Khi bạn định cấu hình các cài đặt cần thiết cho mọi người đang phát triển dự án, bạn hợp nhất các cài đặt đó lại vào thư mục CVS.sinstall và cam kết điều đó với CVS. Cách lưu cài đặt này trong SCM trở thành một quy trình có ý thức. Nó đòi hỏi các nhà phát triển phải hợp nhất các cài đặt đó trở lại các thư mục cài đặt của họ theo thời gian khi các thay đổi lớn được kiểm tra. Nhưng đó là một hệ thống đơn giản hoạt động tốt đáng ngạc nhiên.
Tôi không nói ai trong số họ. Chúng rất có thể chứa thông tin chỉ liên quan đến máy trạm của bạn (Tôi đang nghĩ về các đường dẫn cho thư viện và tất cả). Ngoài ra, nếu ai đó trong nhóm của bạn không sử dụng Eclipse thì sao?
Xem xét:
.classpath
.project
.launch
Những điều này NÊN được kiểm soát phiên bản miễn là bạn sử dụng các đường dẫn liên quan đến dự án. Điều này cho phép các nhà phát triển khác kiểm tra dự án và bắt đầu làm việc ngay lập tức mà không phải trải qua tất cả nỗi đau thiết lập mà các nhà phát triển khác đã trải qua.
Bạn cũng có thể muốn bao gồm .metadata trong kiểm soát phiên bản để các nhà phát triển Eclipse có thể kiểm tra toàn bộ không gian làm việc và được cấu hình sẵn với tất cả các dự án phù hợp, nhưng nó bao gồm rất nhiều thông tin cụ thể của người dùng mà bất cứ ai làm việc trên đó, nó sẽ thay đổi, vì vậy tôi khuyên bạn KHÔNG BAO GỒM .metadata. Thật dễ dàng để xây dựng một không gian làm việc cục bộ chỉ bằng cách nhập tất cả các dự án Eclipse hiện có.
Tôi đã dành quá nhiều giờ để cấu hình cài đặt không gian làm việc nhật thực cho các đồng nghiệp mới (và bản thân tôi). Cuối cùng, điều tôi đã làm là sao chép .metadata của riêng tôi vào máy phát triển mới.
Nếu bạn đang làm việc trong một nhóm, thì tôi nghĩ sau đây là những ứng cử viên rất tốt để kiểm soát phiên bản:
commontab, hãy chọnSave as > shared file. Điều này trực tiếp thả nó trong thư mục dự án, vì vậy nó có thể là SCM với phần còn lại của dự án.