Chúng ta có nên có một kho lưu trữ duy nhất cho tất cả công ty, trong đó có nhiều dự án phát triển hoặc kho lưu trữ cho mỗi dự án không? Bất kỳ ý tưởng về kinh nghiệm/thực hành tốt nhất?Nhiều kho SVN hoặc kho lưu trữ công ty đơn lẻ
Cá nhân tôi chắc chắn sẽ thích kho lưu trữ riêng biệt cho mỗi dự án. Có một số lý do:
Số sửa đổi. Mỗi kho dự án sẽ có trình tự sửa đổi riêng biệt.
Độ chi tiết. Với kho lưu trữ cho mỗi dự án bạn chỉ có thể không thực hiện một cam kết vào các dự án khác nhau có cùng một số sửa đổi. Tôi cho rằng đây là lợi thế hơn, trong khi ai đó sẽ nói rằng đó là một lỗ hổng.
Kích thước lưu trữ. Dự án của bạn lớn đến mức nào? Nó có nhị phân dưới sự kiểm soát nguồn không? Tôi cá là nó có. Do đó, kích thước là quan trọng - mỗi lần sửa đổi tệp nhị phân làm tăng kích thước của kho lưu trữ. Cuối cùng nó trở nên vụng về và rất khó để hỗ trợ. Chính sách chi tiết của lưu trữ tệp nhị phân phải được hỗ trợ và quản trị bổ sung được cung cấp. Đối với tôi, tôi vẫn không thể tìm thấy làm thế nào tôi có thể xóa hoàn toàn tập tin nhị phân (cam kết bởi một số người dùng ngu ngốc) và lịch sử nội dung của nó từ kho lưu trữ. Với kho lưu trữ cho mỗi dự án nó sẽ dễ dàng hơn.
Tổ chức kho lưu trữ bên trong. Tôi thích các kho lưu trữ có cấu trúc, được tổ chức tốt, rất có tổ chức. Có diagram minh họa cách tiếp cận chung (lý tưởng) của quy trình bảo trì kho lưu trữ. Tôi nghĩ bạn sẽ đồng ý rằng nó KHÔNG PHẢI sử dụng 'tất cả các dự án trong một repo'. Ví dụ, cấu trúc ban đầu của tôi về kho (mỗi kho dự án nên có) là:
/project
/trunk
/tags
/builds
/PA
/A
/B
/releases
/AR
/BR
/RC
/ST
/branches
/experimental
/maintenance
/versions
/platforms
/releases
Repo quản lý. 'Kho lưu trữ cho mỗi dự án' có nhiều khả năng hơn trong việc người dùng truy cập cấu hình. Mặc dù nó phức tạp hơn. Nhưng cũng có tính năng hữu ích: you can configure repositories to use the same config file
Repo Support. Tôi thích sao lưu kho một cách riêng biệt. Ai đó nói rằng trong trường hợp này, không thể hợp nhất thông tin từ một repo này sang repo khác. Tại sao trên trái đất bạn sẽ cần điều đó? Các trường hợp khi hợp nhất như vậy là cần thiết cho thấy cách tiếp cận ban đầu để kiểm soát nguồn là sai. Sự tiến hóa của dự án giả định việc tách dự án tiếp theo thành các mô-đun con, chứ không phải theo cách khác. Và tôi biết rằng có cách tiếp cận để làm điều đó.
svn: externals. Phương pháp 'Repository per project' khuyến khích sử dụng svn: externals. Đó là một tình huống lành mạnh khi các phụ thuộc giữa dự án và mô-đun con được thiết lập thông qua các liên kết mềm, mà svn: externals là.
Kết luận. Nếu bạn muốn giữ quyền kiểm soát nguồn đơn giản, hãy sử dụng một kho lưu trữ. Nếu bạn muốn chắc QUYỀN quản lý cấu hình phần mềm:
PS. Nhân tiện, mặc dù tôi làm việc với SVN mọi lúc và tôi thích nó, phương pháp 'kho lưu trữ cho mỗi dự án' là lý do tại sao tôi thấy các hệ thống DCVS hấp dẫn hơn từ quan điểm tổ chức kho lưu trữ. Trong repo DCVS là dự án theo mặc định. Thậm chí không có câu hỏi 'đơn vs nhiều' có thể, nó sẽ chỉ là vô nghĩa.
tần suất bạn thực sự xem xét số sửa đổi? Nếu bạn cần giữ lại một cam kết cụ thể thì việc tạo thẻ sẽ dễ dàng hơn. – Nick
@Nick. Làm thế nào bạn sẽ hợp nhất giữa các phiên bản của mô-đun duy nhất khi bạn không cần phải nhìn thấy những thay đổi trong các phần khác của ứng dụng?Đối với ứng dụng lớn, nó sẽ là mớ hỗn độn. Tôi nghĩ rằng ngay cả khi bạn có repo nhỏ, tốt hơn là phải có sự nhất quán trong số sửa đổi. Tuy nhiên, số sửa đổi không phải là lý do duy nhất có thể thúc đẩy một số để sử dụng kho lưu trữ riêng biệt cho mỗi phương pháp tiếp cận dự án. – altern
Nếu bạn có sự ghép nối giữa các dự án thì tôi sẽ dựa vào một kho lưu trữ duy nhất cho đối số nguyên tử ở trên. Điều này giúp truy xuất nguồn gốc giữa các bản sửa đổi, thẻ, chi nhánh và bản phát hành. Với số hiệu chỉnh sửa, bạn có thể sao chép toàn bộ nguồn của (các) sản phẩm mà bạn biết sẽ hoạt động cùng nhau. –
Nếu bạn đang sử dụng Subversion, bạn có thể có nhiều kho lưu trữ trong cùng một miền với nhiều dự án.
Vì vậy, nó sẽ trông giống như
Project1: svn://svn.company.com/project1
Project2: svn://svn.company.com/project2
Project1 có thể giải quyết vấn đề đang front-end này và chứa tiểu dự án như admin/và web/ project2 sẽ là phụ trợ và chứa các công cụ khác nhau và theo dõi các ứng dụng
Nếu bạn sử dụng một cái gì đó như Git, mỗi kho lưu trữ phải là một dự án duy nhất.
Tôi sẽ có một kho lưu trữ cho dự án, chỉ vì lợi ích của các số sửa đổi cho mỗi dự án. Bạn có thể thiết lập SVN để được phục vụ để tất cả các dự án có thể được truy cập từ một điểm truy cập duy nhất bằng cách sử dụng Apache và DAV SVN (với chỉ thị SVNParentPath).
+1 cho số sửa đổi. Điểm tốt. – phidah
Số sửa đổi không phải là vấn đề lớn, những thứ mà Avi đề cập thực sự là. –
Vì tất cả các nhánh sử dụng số sửa đổi, đối số số sửa đổi là một cá trích đỏ. Không có dự án nào có nhánh sẽ có số phiên bản tuần tự trong thân cây. –
Tôi đã phát hiện ra rằng có một đơn trợ kho lưu trữ Subversion trong:
EDIT: lý do khác:
Tôi khuyên bạn không nên sử dụng kho lưu trữ cho mỗi dự án. Trong một kho lưu trữ subversion duy nhất, bạn có thể di chuyển và sao chép dữ liệu và nó sẽ giữ lại lịch sử của nó. Nếu bạn quyết định rằng một số đoạn mã bắt đầu dưới dạng công cụ phụ trợ đang được hợp nhất vào giao diện người dùng và các mã đó nằm trong các kho lưu trữ khác nhau, đây không phải là thao tác mà lật đổ sẽ biết bất kỳ điều gì. Nó sẽ như thể bạn đã thêm thứ gì đó vào giao diện người dùng từ đâu.Điều này cũng có nghĩa là bạn không thể kết hợp nếu bạn cần tạm thời duy trì hai phiên bản mã có liên quan.
Bạn sẽ lưu ý rằng tất cả các ví dụ trong svn book giả định mọi thứ đều nằm trong một kho lưu trữ.
Có một câu hỏi riêng về việc sử dụng/trunk/project1,/trunk/project2,/branch/project1-r1 hay để sử dụng/project1/trunk,/project1/branches/r1,/project2/trunk. Nói chung, thứ hai dễ theo dõi hơn.
Lý do tốt nhất để không đặt tất cả mọi thứ trong một kho lưu trữ là kiểm soát truy cập khó thực hiện được chi tiết hơn so với mức lưu trữ. Có thể, vâng, nhưng không dễ dàng. Chúng tôi hiện có hai kho chính:
Nhưng ** I ** khuyên bạn không nên sử dụng kho lưu trữ * cho tất cả các dự án * – altern
Quyết định không phải lúc nào cũng rõ ràng. Trong công ty của tôi, chúng tôi đã làm việc trên các dự án hoàn toàn riêng biệt cho các khách hàng khác nhau, trong trường hợp này có một kho lưu trữ riêng biệt cho mỗi dự án là hoàn toàn hợp lý. –
Quyết định cũng có thể dựa trên độ phức tạp của dự án. Nếu bạn đang bắt đầu một nỗ lực rất lớn sẽ được seprarate từ hầu hết mọi thứ khác bạn sẽ làm việc trên, và nó sẽ có một đội ngũ dev lớn làm việc trên nó, nó có thể làm cho tinh thần để cung cấp cho nó một repo riêng biệt.
Đối với các nhóm làm việc trên một số dự án nhỏ hơn cùng một lúc, một kho lưu trữ duy nhất cung cấp một cơ chế đơn giản để quản lý mọi thứ ở một nơi (sao lưu, tìm kiếm, v.v.). Repo trung tâm cũng làm cho kho lưu trữ có vẻ hơi "bê tông" hơn một chút vì nó sẽ không bị loại bỏ sau khi dự án hoàn thành hoặc bị hủy bỏ.
Nó sẽ phụ thuộc vào cách các ứng dụng/dự án phụ thuộc lẫn nhau trong tổ chức, và các mã codebases lớn như thế nào. Do đó, nó tóm tắt cách định nghĩa "dự án" trong tổ chức của bạn. Chia sẻ codebase, thành phần được chia sẻ, nhóm chia sẻ, chu kỳ phát hành được chia sẻ, tất cả có thể ảnh hưởng đến cách lưu trữ của bạn cần được cấu trúc.
Để đơn giản, tôi xác định dự án là có một mã độc lập, thời gian phát hành và/hoặc thuộc một công cụ/ứng dụng.Nếu đây là trường hợp, tôi muốn có một kho lưu trữ cho mỗi dự án. Bằng cách này, có nhiều quyền tự do hơn để xác định và thực thi các hạn chế về chính sách/truy cập cho mỗi dự án.
Nếu tôi có một kho lưu trữ đầy đủ theo thời gian .. Tôi cũng có thể cần phải lo lắng về thời gian kiểm tra không gian làm việc, v.v., đặc biệt nếu mã cho các dự án được trộn lẫn. Nếu một ứng dụng/công cụ/dự án được hoàn thành/tạm hoãn/lỗi thời/di cư, có thể có nhiều quyền kiểm soát hơn đối với các khía cạnh quản trị nếu có sự tách biệt ở cấp dự án.
Việc cấu trúc kho lưu trữ dự án dựa trên nhu cầu duy nhất của nó cũng có thể dễ dàng hơn nếu có một kho lưu trữ cho mỗi dự án. Mỗi dự án có thể có nhu cầu cụ thể, có thể ảnh hưởng đến các chính sách quản lý cấu hình (phân nhánh, gắn thẻ, quy ước đặt tên, bao gồm CI vv) theo sau cho từng dự án. Đây không phải là để nói rằng bạn không thể làm tất cả các thư mục-khôn ngoan trong một kho lưu trữ duy nhất. Bạn có thể. Nó chỉ giữ mọi thứ đơn giản hơn để có sự tách biệt rõ ràng hơn - đó là tất cả.
Bạn có thể xem xét tất cả các yếu tố này để đánh giá chi phí quản trị mà bạn có thể kết thúc, dựa trên thiết lập cụ thể của bạn.
Điều này nói rằng, nếu các dự án có kích thước nhỏ và phụ thuộc lẫn nhau, yêu cầu tham chiếu chéo, theo dõi chéo, di chuyển trong mỗi khác, v.v ... thì tốt hơn với một repo và một thư mục trên mỗi kho lưu trữ.
Rất tốt, câu trả lời sâu sắc cho đến nay, nhưng tôi chỉ muốn thêm hai xu của tôi:
Tôi nghĩ điều đó phụ thuộc vào quy mô dự án của bạn. Chúng tôi đã thử cả hai cách tiếp cận, nhưng cuối cùng đã giải quyết với một kho lưu trữ lớn.
Nhược điểm:
Ưu:
IMHO (và liên quan đến dự án cụ thể của chúng tôi) những ưu điểm vượt trội so với nhược điểm.
Tất cả phụ thuộc vào số lượng dự án bạn có, quy mô tổ chức của bạn, mức độ liên quan của dự án, v.v. Nếu bạn là một phần của một nhóm lớn với một vài chục dự án, một kho lưu trữ cho mỗi dự án sẽ khá khó sử dụng.
Tùy thuộc vào loại công việc mà tổ chức của bạn làm, tùy chọn khác là có một kho lưu trữ cho mỗi khách hàng. Nơi tôi làm việc, chúng tôi hiện có bốn kho lưu trữ - một cho các dự án hoàn toàn bên trong chúng tôi, một cho phần mềm chúng tôi bán và hai dự án hoàn toàn dành riêng cho các khách hàng cụ thể mà chúng tôi sản xuất phần mềm tùy chỉnh chỉ áp dụng cho họ. Đây là một nỗ lực tại giải pháp 'tốt nhất của cả hai thế giới' - chúng tôi không có một kho lưu trữ lớn chứa mọi thứ và có số sửa đổi trong hàng tỷ (tôi phóng đại rõ ràng!), Nhưng cũng không có hàng chục kho lưu trữ nhỏ nằm xung quanh với một dự án trong mỗi dự án.
Đối với tổ chức của tôi, tôi đã đi giữa chừng, tạo một số kho lưu trữ cho các khu vực mã hóa khác nhau. Tôi biết trước rằng mỗi kho chứa các dự án sẽ khá tách biệt với nhau.
tôi đã thực hiện cả hai và trong cả hai trường hợp đôi khi tôi ước gì tôi đã chọn phương pháp khác ...
Tôi đã giải quyết trên một kho lưu trữ là một giải pháp tốt. Lưu ý rằng nếu tôi ở một công ty lớn hơn, tôi sẽ xem xét lại.
Tôi đang làm việc tại một công ty hoạt động cho rất nhiều khách hàng với các quy tắc nghiêm ngặt. Hiện tại chúng tôi có khoảng 130 nhà phát triển. Chúng tôi có một dự án cốt lõi được tùy chỉnh theo từng nhu cầu của khách hàng. Và chúng tôi có một kho lưu trữ svn lớn. Nó sẽ là nỗi đau trong ass nếu chúng ta sẽ phải kiểm tra toàn bộ chi nhánh nhưng chiến lược của chúng tôi là di chuyển các dự án ra khỏi nhánh chung và chỉ để lại công việc cho các lệnh chuyển đổi. :) Cách này mọi thứ có thể được lưu giữ trong một kho lưu trữ duy nhất.
mối quan tâm duy nhất của tôi là chia tách một kho lưu trữ cho nhiều kho nếu cần thiết trong trường hợp outsorcing phần của tác phẩm, hoặc bán một dự án toàn bộ cho đến khi tôi thấy điều này: http://www.mugo.ca/Blog/Splitting-a-Subversion-repository-into-multiple-repositories
Vì vậy, tôi nghĩ rằng công tắc svn giúp giảm bớt các đau của thanh toán dài (một trong những thiết bị chuyển mạch ra chỉ các dự án mong muốn), nhưng chúng tôi có thể có một kho lưu trữ. Nhưng, nếu vẫn còn cần thiết, người ta có thể trích xuất một tập hợp các thành phần để tách kho.
theo kinh nghiệm của tôi, bạn có thể đi một trong hai cách hợp lý. –
Trong tổ chức của chúng tôi, chúng tôi có các dự án _many_ không liên quan, chủ yếu là .NET. Chúng tôi đang cân nhắc việc sử dụng kho lưu trữ ở cấp độ giải pháp. Bằng cách đó, các dự án liên quan sẽ nằm trong cùng một repo và chia sẻ số sửa đổi, nhưng không phải là các dự án không liên quan. Tôi nghĩ rằng những gì nó nên đi xuống là giữ những thứ liên quan với nhau. Nếu tất cả các dự án của bạn có liên quan, thì một repo có ý nghĩa. Nếu không, thì nó không còn ý nghĩa nữa. –