2012-03-02 5 views
9

Chúng tôi phát triển với Visual Studio 2010 (trong C#) và di chuyển một lúc trước từ SVN sang GIT. Bây giờ chúng tôi cố gắng chia nhỏ kho lưu trữ của chúng tôi (khá lớn - ~ 30.000 tệp) thành nhiều kho lưu trữ git - một cho mỗi giải pháp. Các giải pháp chia sẻ một số dự án, chủ yếu là các thư viện mà chúng tôi phát triển trong nhà và muốn thêm vào từ tất cả các giải pháp.Làm thế nào để đối phó với Git Submodules trong các giải pháp Visual Studio với cách bố trí khác nhau?

Kho lưu trữ mới có bố cục bằng phẳng. Một thư mục con cho mỗi dự án (các dự án chia sẻ là các mô-đun con). Trong repo cũ lớn, các dự án nằm trong một cấu trúc cây.

Sự cố xảy ra với tham chiếu bên ngoài trong các mô-đun con. Trong repos mới, đường dẫn đến một dự án được tham chiếu có thể là "...... libs \ someproject", trong khi trong bố cục mới, đường dẫn chính xác sẽ là ".. \ someproject".

Chúng tôi đã có một số cuộc chiến chỉnh sửa liên quan đến vấn đề này và không quan tâm nhiều hơn.

nướng vừa chín Solutions tôi có thể nghĩ ra:

  • sử dụng "tham khảo Paths" trong ... csproj.user và loại trừ tập tin này từ kiểm soát phiên bản (đã được làm lại cho mỗi nhà phát triển và sau mỗi lần reopsitory dọn dẹp)

  • chi nhánh sử dụng cho từng tình huống và cố gắng dạy cho tất cả mọi người nơi cam kết "thực" nên đi và nơi "với môi trường thay đổi" cam kết nên đi (submodules đã không phải là khái niệm đơn giản nhất ...)

  • nhị phân nhúng thay vì các mô-đun con (nhưng những gì về việc phát triển các thay đổi cho các mô-đun con? còn các phiên bản log4net khác nhau thì sao?)

Có ai biết giải pháp lành mạnh không?

Trả lời

5

Vì bạn đang yêu cầu một giải pháp lành mạnh, tôi chỉ có thể khuyên bạn nên nhìn vào thiết lập dịch vụ NuGet riêng của bạn (nhìn vào http://www.MyGet.org cho cảm hứng)

http://nuget.codeplex.com/

+1

Tôi đoán bạn đang ngụ ý để di chuyển từ bao gồm nguồn để DLL bao gồm với quản lý phụ thuộc hợp lý. Nếu có, nó có vẻ hấp dẫn, nhưng ngay bây giờ chúng tôi phát triển các thư viện được chia sẻ như một phần của các giải pháp kèm theo. Có vẻ là một cách khá nặng nề để giải quyết vấn đề. – plaugg

+0

Nếu, như tôi đã hiểu, họ là các dự án VS riêng biệt, nó không nên đặt ra một vấn đề về tính khả thi, nhưng thực sự nó không phải là hack nhanh chóng mà bạn có thể tìm kiếm ... Nếu bạn lo lắng về gỡ lỗi thì nuget hỗ trợ liên kết với một máy chủ nguồn biểu tượng để duy trì trải nghiệm gỡ lỗi, nhưng nếu có rất nhiều thứ qua lại giữa chính và các dự án hỗ trợ, điều này có thể là một vấn đề. Tôi là một chút do dự w.r.t. thiếu sự tao nhã của các mô đun con git và tôi muốn đề xuất một giải pháp thay thế mà bạn không liệt kê (và hỗ trợ phiên bản!). – Dirk

+0

Tôi hơi buồn vì tùy chọn này không có sẵn khi tôi vẫn làm việc với .NET. Visual Studio nổi tiếng là ngu ngốc khi nói đến phụ thuộc. Cách tiếp cận này có rất nhiều lợi thế. Nhưng điều quan trọng nhất đối với tôi là từ quan điểm của nhà phát triển, các dự án sẽ nhanh hơn để thiết lập, biên dịch và lập trình. Khi tôi kiểm tra một dự án mới, tôi chỉ lấy tất cả các thư viện cần thiết và tôi chỉ phải biên dịch các thư viện dự án để chạy nó. Không chỉ vậy nhưng đi là sự lộn xộn của những tiểu dự án mà làm cho các dự án dễ hiểu hơn nhiều. – SpoBo

1

Sử dụng một mô-đun con để chứa tất cả "thư viện chung". Chỉ một cấp. Nhưng bạn nên di chuyển các thư viện phổ biến như các dịch vụ với các hợp đồng được xác định rõ ràng. Bằng cách này, bạn có thể tăng dần các phiên bản mới mà không mất thời gian. Bằng cách này bạn chỉ có một mô-đun con trong mỗi cái chứa các hợp đồng. Đây có thể là giao diện hoặc tin nhắn.

+0

Có lẽ tôi không hiểu câu trả lời của bạn. Có vẻ như bạn đề xuất bố cục giải pháp. Câu hỏi của tôi không phải là về Giao diện giải pháp, nhưng về cách xử lý các môi trường khác nhau cho các mô-đun con trong các giải pháp khác nhau. – plaugg

+0

Điều này sẽ được xử lý tại các cấp độ Repos. Các dự án submodule nên kế thừa điều đó. Nói cho nhibernate, bạn có một số chức năng phổ biến. Bây giờ bạn muốn sử dụng điều này trong ap cửa sổ dịch vụ và ap web. Bạn cần phải thiết lập luồng ở phía trên. Tương tự cho các cài đặt khác. –

1

Vì vậy, nếu tôi hiểu bạn một cách chính xác, vấn đề là với Visual Studio và không phải với Git? Nếu đúng như vậy, hãy sử dụng cấu trúc cây cũ đã làm việc với Visual Studio. Làm cho các mô đun con của bạn cấu trúc một cấu trúc cây. Vì vậy, đỉnh của cây sẽ là một siêu repo có mô-đun phụ (các chi nhánh) sẽ có submodules của riêng mình, cho đến khi bạn nhận được xuống đến lá của cây của bạn. Nó sẽ là một nỗi đau để thiết lập lúc đầu, nhưng nó chỉ nên làm việc.

2

NẾU bạn đi theo lộ trình quản lý gói, hãy xem xét OpenWrap. Tuy nhiên, việc nhúng các tạo phẩm quản lý gói trong mã nguồn là một ý tưởng tồi. Bạn có thể sử dụng các công cụ như vậy để cập nhật những gì thực sự được lưu trữ trong submodules, nhưng không dựa vào chúng tại thời gian xây dựng. Mong đợi các tệp nhị phân ở đó từ quan điểm của các tập lệnh xây dựng của bạn.

1

Tôi gặp sự cố tương tự khi sử dụng VS 2013.

Tôi muốn sử dụng git-svn thay vì SVN trực tiếp. SVN có một bộ thư mục khổng lồ. Tôi không thể tạo một kho lưu trữ git đơn lẻ có chứa tất cả thư mục thân của chúng tôi. Git-luôn luôn thoát với một lỗi và kho lưu trữ bị hỏng. Tôi đã giải quyết vấn đề bằng cách thực hiện như sau:

  1. Sử dụng git-svn, tôi nhân bản tập con của thư mục khỏi SVN/trunk mà tôi cần bằng cách tạo một kho lưu trữ git cho mỗi thư mục.
  2. Tạo kho lưu trữ git cha mẹ cục bộ chứa tất cả các thư mục git-svn-cloned của tôi.
  3. Mỗi kho git được thêm dưới dạng mô-đun phụ vào kho lưu trữ git cha.

Vấn đề với Visual Studio là nó không nhận ra nhiều dự án bên ngoài dự án chính mà tôi đã mở giải pháp. Giải pháp này nằm trong một thư mục có chứa các tệp duy nhất được Visual Studio nhận diện dưới dạng điều khiển nguồn git.

Tôi đã thử đặt các tùy chọn git để sử dụng thư mục mẹ cấp cao hơn làm vị trí của git-repostitory mà không nhận thấy bất kỳ sự khác biệt nào.

+0

Đừng bận tâm. Tôi chỉ phát hiện ra rằng Visual Studio không hỗ trợ git-submodules. https://connect.microsoft.com/VisualStudio/feedback/details/790028/visual-studio-tools-for-git-cant-see-submodule-changes – Catriel