2009-04-28 35 views
5

Chúng tôi hiểu sự mặc định và thường khuyến khích tổ chức kho svn, trong trường hợp có nhiều dự án, là một cái gì đó như thế này:Một ý tưởng hay là đặt tất cả các dự án vào cùng một thân cây?

root/projectA/(trunk, branches, tags) 
root/projectB/(trunk, branches, tags) 
... 

dự án của chúng tôi có rất nhiều phụ thuộc lẫn nhau, và đó sẽ đòi hỏi việc sử dụng extense của svn : externals giữa chúng, xem xét chúng tôi không làm dll tham chiếu đến các dự án nội bộ, chúng tôi muốn xem mã nguồn của họ thay vì làm việc với các tệp nhị phân.

Sử dụng bên ngoài quá nhiều, khi phân nhánh, thay đổi đồng bộ hóa, có thể trở thành một trải nghiệm phức tạp và dễ xảy ra lỗi, do đó nhóm không tin tưởng giải pháp này chút nào.

Vì vậy, một thành viên trong nhóm đề xuất điều gì đó mà tất cả chúng ta nghĩ đây có thể là giải pháp tốt hơn: đặt tất cả các dự án vào cùng một thân cây.

Lúc đầu, chúng tôi đã nhận ra một số vấn đề với cách tiếp cận này, nhưng nói chung chúng tôi đồng ý những vấn đề này dựa trên các tình huống đạo đức giả mà rất có thể chúng tôi chưa từng trải nghiệm.

Bạn có thấy một số vấn đề nghiêm trọng mà chúng tôi có thể có với giải pháp này không?

Trả lời

4

Chúng tôi làm điều này tại công ty của chúng tôi và đã có rất nhiều thành công.

Chúng tôi có 3 thư mục cấp cao nhất:

  • thẻ
  • chi nhánh
  • thân

Và sau đó chúng tôi có từng dự án như một thư mục con của những người.

Chúng tôi vẫn chi nhánh ở cấp dự án và vẫn sử dụng svn: externals. Nhưng nếu chúng ta có một cây nguồn nhỏ hơn, chúng ta sẽ nhánh ở mức thân cây và không sử dụng svn: extenrals.

Thật tuyệt khi có thể có tất cả các thân cây của dự án ở cùng một nơi. Bạn có thể sao lưu nó, bạn có thể kiểm tra tất cả và bạn có tất cả những thứ gần đây nhất với nhau. Bạn không bị mất vị trí duy nhất cho tất cả các chi nhánh hay địa điểm duy nhất cho tất cả các thẻ hoặc vì họ là tất cả trong thư mục con của/chi nhánh/Projectx và/thẻ/Projectx

Vấn đề với svn: externals:

Nếu dự án của bạn không phải là tuyệt vời HUGE thì bạn chỉ có thể phân nhánh toàn bộ thân cây mỗi lần và tránh tất cả các vấn đề với svn: externals.

Vấn đề với svn: externals là khi bạn tạo một chi nhánh, nó không tự động tạo chi nhánh cho mỗi svn: externals cho bạn. Đây là một vấn đề bởi vì sau đó theo thời gian tất cả các chi nhánh cũ của bạn sẽ không thể biên dịch như thân cây của bạn được cập nhật nhiều hơn. Một vấn đề khác là nếu bạn thực hiện một sửa chữa trong bất kỳ chi nhánh để một svn: bên ngoài, tất cả các chi nhánh khác của bạn phá vỡ.

Một vấn đề khác với svn externals là khi bạn làm một svn: log ở cấp cơ sở, bạn không thấy bất kỳ thay đổi nào từ svn externals.

Hy vọng rằng một ngày svn bên ngoài sẽ được cố định để giải quyết các vấn đề trên, nhưng cho đến ngày đó phân nhánh và svn: externals là một cơn ác mộng tuyệt đối.

+0

Tôi đồng ý với điều này. Việc có các dự án trong các kho lưu trữ riêng biệt làm cho việc chia sẻ mã khó hơn và hợp nhất các thay đổi giữa các sản phẩm nếu cần. Làm việc trong các nhánh dự án riêng biệt là sạch hơn vì bạn có thể làm việc độc lập nhưng vẫn đẩy những thay đổi xuống thân cây. –

+0

Đồng ý; chúng tôi có một repo riêng biệt cho từng dự án và nó gây ra vấn đề. Chúng tôi đã thử nghiệm với nhiều dự án cho mỗi repo và nó đã hoạt động tốt hơn; điều chính khiến chúng tôi không thể chuyển sang vĩnh viễn này là quyền. (commit-access-control.pl không phải là rất cấu hình, trong khi bạn có thể kiểm soát kho riêng biệt bằng cách sử dụng một mô-đun LDAP với apache hoặc tương tự. Chúng tôi cũng có thể chọn lọc chỉ phơi bày kho lưu trữ nhất định để truy cập ngoại vi. Có lẽ một cách mới hơn/tốt hơn để làm tất cả điều này, nhưng trong thời gian này, đó là lý do tại sao chúng tôi đang sử dụng repos riêng biệt.) – leander

+0

Ya tôi sử dụng apache và cấu hình nó theo cách đó, có một thread trên SO về nó http://stackoverflow.com/questions/484499/how-do-i-restricted-apache-svn-access-to-specific-users-ldap-file-based-authentica/484721 # 484721 –

1

Điều bạn đã làm là những gì tôi đã thiết lập tại công ty của mình và nó cũng được tham chiếu là "bố cục rất phổ biến" trong chủ đề svnbook, Strategies for Repository Deployment.

Không có gì sai với nó.

1

để "đặt tất cả các dự án vào cùng một thân cây":

Từ kinh nghiệm của tôi đây không phải là ý tưởng tốt - vì mỗi dự án có thật lịch sử riêng và những thay đổi và thường các dự án đang/sẽ được duy trì bởi các nhà phát triển khác nhau. Điều này có thể dẫn đến xung đột - ngay cả khi bạn tuyên bố, rằng hiện tại các dự án can thiệp rất nhiều. Vậy tại sao bạn không sử dụng các thẻ phổ biến (với các cột mốc như tên) cho tất cả các dự án của bạn để đảm bảo cùng một cơ sở mã và một kịch bản xây dựng, có thể tự động kiểm tra các dự án (trunks)? Đó là công việc nhiều hơn, nhưng như bình thường trong OOP (capsulation) tôi muốn chia các dự án thành các thư mục SVN riêng biệt, quá.

Nhưng: Thu thập một loạt các libs và ứng dụng nhỏ vào một thư mục chung dưới cùng một thân cây không thành vấn đề (xem "ứng dụng" và "công cụ" trong ví dụ của tôi bên dưới) - vì vậy có thể "các dự án nhỏ" có thể ở lại chia sẻ/thân cây lớn.

Dưới đây là ví dụ cấu trúc thư mục của tôi về SVN:

/projects/ 
/projects/CustomerA/ 
/projects/CustomerA/ProjectX/ 
/projects/CustomerA/ProjectX/trunk/ 
/projects/CustomerA/ProjectX/tags/ 
/projects/CustomerA/ProjectX/branches/ 
/thirdparty/ 
/thirdparty/ExtLibY/ 
/thirdparty/ExtLibZ/ 
/tools/ 
/tools/trunk/ 
/tools/tags/ 
/tools/branches/ 
/apps/ 
/apps/trunk/ 
/apps/tags/ 
/apps/branches/ 

Vì vậy, tất cả những thứ bên ngoài được lưu trữ trong/thirdparty/và tất cả internals (các dự án, các công cụ, ứng dụng) có subdirs:

/trunk/ 
/tags/  
/branches/ 

... như được khuyên trong sách Subversion và bài đăng trước đó.

Ngay cả khi điều đó có vẻ hơi nỗ lực ngay từ cái nhìn đầu tiên - nó thực sự đáng giá, đặc biệt khi cơ sở mã của bạn phát triển.

ciao, Chris

+0

Chúng tôi sử dụng cùng một bố cục .. Chúng tôi sử dụng các dự án (nội bộ), sản phẩm (được phân phối) và thư viện (các thành phần được sử dụng lại) làm tên cấp cao nhất. –

1

Bạn có thấy một số vấn đề nghiêm trọng, chúng tôi có thể có với giải pháp này?

  • giải pháp của bạn chỉ hoạt động miễn là bạn có thể đặt tất cả mọi thứ trong một kho lưu trữ đơn .

    Điều này có nghĩa là toàn bộ kho lưu trữ phải vừa với một đĩa đơn (hoặc nhóm lưu trữ) trong tương lai gần. Các cân nhắc tương tự áp dụng cho các tài nguyên máy chủ khác như băng thông mạng I/O và mạng.

    Tách kho lưu trữ sau này sẽ yêu cầu sửa chữa lớn toàn bộ thiết lập của bạn và có thể gây đau đầu khi bạn cần xây dựng lại hoặc phân nhánh phiên bản cũ.

  • giải pháp của bạn chỉ hoạt động nếu bạn không cần phải hạn chế đọc/ghi cho phép trên một cơ sở cho mỗi người dùng

    Nếu bạn cần phải cung cấp cho đọc/ghi cho phép cho PROJECTA, bạn thực sự sẽ phải để cấp quyền cho/trunk/projectA và/branch1/projectA và/branch2/projectA, v.v.

    Phân nhánh sau đó trở thành quy trình trọng lượng nặng đòi hỏi nhiều điều chỉnh quyền. Nói lời tạm biệt với feature branches.

Các vấn đề liên quan