Cấu trúc thư mục làm việc cho kho SVN Visual Studio

Question

Tôi vừa giới thiệu SVN trong công ty cho các dự án Visual Studio và tạo một kho lưu trữ trông như thế này ("giải pháp" là giải pháp Visual Studio, chứa các dự án 1..n):

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/... 

Bây giờ, tôi có hai lựa chọn để cấu trúc các thư mục địa phương làm việc:

lựa chọn A: Hãy để kiểm tra người sử dụng mỗi giải pháp riêng biệt sử dụng AnkhSVN, dẫn đến một cấu trúc như thế này:

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/solution3/projectD/... 
/solution4/projectE/... 
      /projectF/... 

hoặc này, nếu tôi nói với người sử dụng để tự tạo một thư mục con customerX:

/solution1/projectA/... 
      /projectB/... 
/solution2/projectC/... 
/customerX/solution3/projectD/... 
/customerX/solution4/projectE/... 
        /projectF/... 

Ưu điểm: Người dùng có thể kiểm chỉ các giải pháp mà ông thực sự cần. Nhược điểm: Mọi giải pháp cần được kiểm tra/cập nhật riêng biệt.

Lựa chọn B: Nói cho người sử dụng để kiểm tra toàn bộ kho lưu trữ sử dụng TortoiseSVN, dẫn đến một cấu trúc đó là chính xác giống như kho:

/solution1/trunk/projectA/... 
       /projectB/... 
/solution2/trunk/projectC/... 
/customerX/solution3/trunk/projectD/... 
      /solution4/trunk/projectE/... 
          /projectF/... 

Ưu điểm: Nó rất dễ dàng để "svn cập nhật tất cả mọi thứ ". Nhược điểm: Người dùng cũng có bản sao cục bộ của tất cả các chi nhánh và thẻ.

---

HỎI: Kể từ khi một số dự án được chia sẻ giữa các giải pháp (giả sử, ví dụ, rằng PROJECTA là một thư viện mà còn được sử dụng bởi solution3), chúng ta cần giải quyết một cấu trúc thư mục, để đảm bảo rằng các đường dẫn tương đối trong các tệp giải pháp là chính xác. Bạn đề nghị tùy chọn nào và tại sao?

---

EDIT: Cảm ơn tất cả các câu trả lời tuyệt vời của bạn, đặc biệt là đề cập đến thiết kế kho lưu trữ tốt. Tôi đã kết thúc cập nhật kho tôi cấu trúc:

/trunk/solution1/projectA/... 
       /projectB/... 
     /solution2/projectC/... 
     /customerX/solution3/projectD/... 
          -svn:external to projectA 
       /solution4/projectE/... 
          /projectF/... 

đảm bảo rằng một nhà phát triển làm việc trên solution3 chỉ nhu cầu kiểm tra solution3 (và không solution1) và giải pháp có thể được kiểm tra ra đối với bất kỳ thư mục tức là thư mục làm việc không cần cấu trúc cố định.

Answer 1

Hehe, điều này có lẽ không phải là rất hữu ích, nhưng ... không phải.:)

Tôi sẽ có trunk ở cấp cao nhất, với các dự án và giải pháp được tổ chức bên dưới cùng với nhau trong cấu trúc phẳng. Sau đó, tôi sẽ sử dụng thuộc tính svn:externals trên các thư mục giải pháp để kéo các dự án thích hợp vào vị trí chính xác trong bản sao làm việc của từng nhà phát triển.

Lý do tôi tổ chức mọi thứ theo cách này là nó mang lại cho bạn những lợi ích từ cả tùy chọn A và tùy chọn B. Vì vậy, nếu nhà phát triển chỉ muốn xem một giải pháp duy nhất, họ được tự do làm như vậy. Tương tự như vậy họ cũng có thể kiểm tra toàn bộ thân cây nếu họ muốn làm điều đó thay vì (và họ có thể làm như vậy mà không nhận được thẻ và các chi nhánh).

Ngoài ra, cách tiếp cận này để có một thân cây đơn giúp bạn dễ dàng gắn thẻ hoặc phân nhánh toàn bộ repo hơn, nếu bạn cần làm điều đó.

Answer 2

Đối với những gì nó có giá trị, chúng tôi sử dụng tùy chọn B.

Chúng tôi cũng sử dụng SVN Rùa chứ không phải là Ankh SVN vì chúng tôi có sự linh hoạt một chút tốt hơn với cấu trúc của kho lưu trữ của chúng tôi nếu nó không gắn liền với cấu trúc thư mục tương tự mà Visual Studio mong đợi. Tôi đã bước đầu kịch liệt phản đối điều này bởi vì tôi thích sự tích hợp IDE mà tôi có với TFS, nhưng sau khi làm việc với nó chỉ trong vài ngày, tôi đã được bán ra rằng sự giao dịch linh hoạt hơn hàng nghìn lần quan trọng hơn sự tích hợp với IDE.

Edit - Thêm

Nó cũng đáng chú ý là trước khi chuyển sang quy trình hiện tại của chúng tôi, chúng tôi vạch ra chính xác cách thức chúng tôi muốn đặt ra TẤT CẢ kiểm soát nguồn của chúng tôi. Chúng tôi mất vài tuần để lên kế hoạch chính xác, phân tích nó đến chết trước khi thực hiện chuyển đổi, nhưng nó đã được trả hết để dễ sử dụng và bảo trì.

Chúng tôi có một cấu trúc tổng thể như sau:

\ Web Apps nội

\ Internet Web Apps

\ WinForms Corporate Apps

\ Widows Corporate Services

\ Vị trí bán lẻ WinForms Apps

\ Services Location bán lẻ

\ Shared

\ file Cross-Platform Solution.

Mỗi thư mục chính chứa nhiều dự án và giải pháp khác nhau. Chúng có các nhánh, thẻ và thân của riêng chúng. Vì vậy, ví dụ, nếu chúng ta có một công cụ tìm cửa hàng Internet, nó có thể là trong

\Internet\<our company name>.com\Store Finder\Trunk 

Phần quan trọng của việc này là chia sẻ, vì điều này có chứa mã được sử dụng trong tất cả các ngành khác. Lý do mà việc tích hợp IDE không hiệu quả với chúng ta là chúng ta sẽ cần một giải pháp ở mức root để thực hiện điều này. Thay vào đó, chúng ta có các tệp Sln của chúng ta khi thích hợp và vì tất cả chúng ta có một bản sao đầy đủ của kho lưu trữ, chúng ta có thể đảm bảo rằng các đường dẫn tương đối đến bất kỳ dự án nào trong thư mục \ Shared giống nhau trên tất cả PC của nhà phát triển.

Tôi đã cung cấp ở trên, không cho bạn biết cách cấu trúc mã của bạn, nhưng chỉ để cung cấp cho bạn ý tưởng và nhấn mạnh tầm quan trọng của kế hoạch trước khi tiếp tục.

Bạn cần dành chút thời gian đặt câu hỏi như "Nếu tôi đặt câu hỏi như Y, tôi có thể thực hiện X không?". Tình huống của bạn sẽ là duy nhất cho nhóm và công ty của bạn.

Answer 3

Tùy chọn A - bạn không muốn kéo toàn bộ kho xuống (tất cả các thẻ và nhánh) mọi lúc và nó sẽ khuyến khích người dùng của bạn nghĩ về toàn bộ kho lưu trữ như một thực thể duy nhất mà nó không thực sự - bạn muốn họ suy nghĩ về các giải pháp và gắn thẻ/phân nhánh trong ngữ cảnh đó.

Bạn giải quyết các dự án được chia sẻ bằng cách tham chiếu chúng dưới dạng bên ngoài trong "gốc" của các giải pháp thích hợp. Điều này có nghĩa là bạn có thể có cùng một dự án xuất hiện nhiều lần trên HDD của bạn nhưng điều đó có thể quản lý được.

Có nhiều hơn một chút teeny về đề tài này ở đây: HowTo: Reference external SLN files with TeamCity

Answer 4

Tôi sẽ mạnh mẽ thứ hai Phil Booths giải pháp sử dụng cấu trúc thư mục phẳng và sử dụng thuộc tính svn:externals trong bao gồm các dự án được chia sẻ.

Lý do chính là điều này cho phép bạn tự do tách rời cách các dự án khách hàng khác nhau sử dụng dự án được chia sẻ, chẳng hạn như thư viện, được cập nhật. Với cấu trúc được đề xuất của bạn, chỉ có một bản sao của dự án thư viện được sử dụng bởi tất cả các dự án khách hàng khác: do đó tất cả các dự án sử dụng dự án được chia sẻ phải xem cùng một phiên bản. Điều này không phải lúc nào cũng mong muốn.

Đôi khi, các thay đổi đối với thư viện được chia sẻ sẽ yêu cầu các thay đổi tương ứng trong mã máy khách sử dụng thư viện đó. Với cấu trúc được đề xuất của bạn, thay đổi như vậy sẽ yêu cầu bạn cập nhật tất cả các dự án khách hàng của thư viện cùng một lúc hoặc sống với thực tế là nhiều dự án khách hàng có thể bị hỏng.

Sử dụng svn:externals cho từng dự án khách hàng sử dụng thư viện, nghĩa là mỗi khách hàng sẽ có bản sao thư viện riêng trong bản sao làm việc (nhưng không gian đĩa rẻ). Tuy nhiên, vẫn còn một bản sao của dự án thư viện trong kho lưu trữ (các dự án của khách hàng chỉ cần cập nhật một phiên bản khác của nó. cập nhật svn:externals tài sản) để sử dụng một phiên bản mới hơn

Nói tóm lại:.

Trong bố trí đề xuất của bạn:. cam kết một sự thay đổi để một dự án thư viện thay đổi ngay lập tức tất cả các dự án có sử dụng thư viện Tất cả các dự án khách hàng được cập nhật thư viện, cho dù họ có muốn hay không.

Với svn:externals, cam kết thay đổi đối với dự án thư viện chỉ ảnh hưởng đến libr dự án ary một mình. Mỗi dự án khách hàng yêu cầu một cam kết bổ sung để cập nhật thuộc tính svn:externals để tham khảo phiên bản mới hơn của thư viện (có thể được cam kết cùng với các thay đổi tương ứng với mã của khách hàng projec). Tất cả các dự án của khách hàng đều có thể cập nhật thư viện, nhưng họ chỉ nhận được chúng khi họ yêu cầu chúng một cách rõ ràng.