.Sln có nên cam kết kiểm soát nguồn không?

Có phải là phương pháp hay nhất để cam kết tệp .sln với quyền kiểm soát nguồn không? Khi nào thì thích hợp hay không thích hợp để làm như vậy?

Cập nhật Có một số điểm tốt được thực hiện trong các câu trả lời. Cảm ơn vì những câu trả lời!

Tôi nghĩ rằng rõ ràng từ các câu trả lời khác rằng các tệp giải pháp hữu ích và nên được cam kết, ngay cả khi chúng không được sử dụng cho các bản dựng chính thức. Chúng rất tiện dụng cho bất kỳ ai sử dụng các tính năng của Visual Studio như Đi tới Định nghĩa / Khai báo.

Theo mặc định, chúng không chứa đường dẫn tuyệt đối hoặc bất kỳ tạo tác dành riêng cho máy nào khác. (Thật không may, một số công cụ bổ trợ không duy trì đúng thuộc tính này, chẳng hạn như AMD CodeAnalyst.) Nếu bạn cẩn thận sử dụng các đường dẫn tương đối trong các tệp dự án của mình (cả C ++ và C #), chúng sẽ độc lập với máy quá.

Có lẽ câu hỏi hữu ích hơn là: bạn nên loại trừ những tệp nào? Đây là nội dung của tệp .gitignore cho các dự án VS 2008 của tôi:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(Mục nhập cuối cùng chỉ dành cho hồ sơ AMD CodeAnalyst.)

Đối với VS 2010, bạn cũng nên loại trừ những điều sau:

ipch/
*.sdf
*.opensdf

Có - tôi nghĩ nó luôn luôn thích hợp. Cài đặt người dùng cụ thể nằm trong các tệp khác.

Có bạn nên làm điều này. Tệp giải pháp chỉ chứa thông tin về cấu trúc tổng thể của giải pháp của bạn. Thông tin về giải pháp là toàn cầu và có thể phổ biến cho tất cả các nhà phát triển trong dự án của bạn.

Nó không chứa bất kỳ cài đặt người dùng cụ thể nào.

Bạn chắc chắn nên có nó. Bên cạnh những lý do mà những người khác đã đề cập, cần phải thực hiện một bước xây dựng toàn bộ dự án.

Tôi thường đồng ý rằng các tệp giải pháp nên được kiểm tra, tuy nhiên, tại công ty tôi làm việc, chúng tôi đã làm một điều gì đó khác biệt. Chúng tôi có một kho lưu trữ khá lớn và các nhà phát triển làm việc trên các phần khác nhau của hệ thống theo thời gian. Để hỗ trợ cách chúng tôi làm việc, chúng tôi sẽ có một tệp giải pháp lớn hoặc một số tệp nhỏ hơn. Cả hai đều có một vài thiếu sót và yêu cầu các nhà phát triển phải làm việc thủ công. Để tránh điều này, chúng tôi đã tạo một trình cắm thêm xử lý tất cả những điều đó.

Trình cắm thêm cho phép mỗi nhà phát triển kiểm tra một tập hợp con của cây nguồn để làm việc đơn giản bằng cách chọn các dự án có liên quan từ kho lưu trữ. Sau đó, plugin sẽ tạo tệp giải pháp và sửa đổi nhanh các tệp dự án cho giải pháp đã cho. Nó cũng xử lý các tài liệu tham khảo. Nói cách khác, tất cả những gì nhà phát triển phải làm là chọn các dự án thích hợp và sau đó các tệp cần thiết được tạo / sửa đổi. Điều này cũng cho phép chúng tôi tùy chỉnh nhiều cài đặt khác nhau để đảm bảo các tiêu chuẩn của công ty.

Ngoài ra, chúng tôi sử dụng trình cắm này để hỗ trợ các chính sách đăng ký khác nhau, thường ngăn người dùng gửi mã bị lỗi / không tuân thủ đến kho lưu trữ.

Có, những điều bạn nên cam kết là:

• giải pháp (* .sln),
• tệp dự án,
• tất cả các tệp nguồn,
• tệp cấu hình ứng dụng
• xây dựng kịch bản

Những điều bạn không nên phạm phải là:

• tệp tùy chọn người dùng giải pháp (.suo),
• xây dựng các tệp được tạo (ví dụ: sử dụng tập lệnh xây dựng) [Chỉnh sửa:] - chỉ khi tất cả các tập lệnh và công cụ xây dựng cần thiết đều có sẵn dưới sự kiểm soát của phiên bản (để đảm bảo các bản dựng là xác thực trong lịch sử cvs)

Về các tệp được tạo tự động khác, có một chủ đề riêng .

Có, nó phải là một phần của kiểm soát nguồn. Khi bạn thêm / xóa các dự án khỏi ứng dụng của mình, .sln sẽ được cập nhật và sẽ rất tốt nếu bạn có nó dưới sự kiểm soát nguồn. Nó sẽ cho phép bạn lấy lại mã ứng dụng của mình 2 phiên bản và trực tiếp xây dựng (nếu được yêu cầu).

Trong hầu hết các trường hợp, bạn nên cam kết các tệp .sln với quyền kiểm soát nguồn.

Nếu các tệp .sln của bạn được tạo bởi một công cụ khác (chẳng hạn như CMake) thì có thể không thích hợp để đưa chúng vào kiểm soát nguồn.

Có, bạn luôn muốn bao gồm tệp .sln, tệp này bao gồm các liên kết đến tất cả các dự án có trong giải pháp.

Chúng tôi làm vì nó giữ mọi thứ đồng bộ. Tất cả các dự án cần thiết được đặt cùng nhau, và không ai phải lo lắng về việc thiếu một. Máy chủ xây dựng của chúng tôi (Ant Hill Pro) cũng sử dụng sln để tìm ra các dự án sẽ xây dựng cho một bản phát hành.

Chúng tôi thường đặt tất cả các tệp giải pháp của mình trong một thư mục giải pháp. Bằng cách này, chúng tôi tách giải pháp khỏi mã một chút và dễ dàng hơn để chọn ra dự án tôi cần thực hiện.

Trường hợp duy nhất mà bạn thậm chí sẽ xem xét không lưu trữ nó trong kiểm soát nguồn là nếu bạn có một giải pháp lớn với nhiều dự án nằm trong kiểm soát nguồn và bạn muốn tạo một giải pháp nhỏ với một số dự án từ giải pháp chính cho một số yêu cầu thoáng qua riêng tư.

Có - Mọi thứ được sử dụng để tạo ra sản phẩm của bạn phải được kiểm soát nguồn.

Chúng tôi giữ hoặc giải pháp các tệp trong Kiểm soát Phiên bản TFS. Nhưng vì hoặc giải pháp chính thực sự lớn, nên hầu hết các nhà phát triển đều có một giải pháp cá nhân chỉ chứa những gì họ cần. Tệp giải pháp chính chủ yếu được sử dụng bởi máy chủ xây dựng.

.slns là thứ duy nhất chúng tôi không gặp vấn đề trong tfs!