Một kho SVN hay nhiều kho?

Nếu bạn có nhiều dự án không liên quan, bạn có nên đặt chúng vào cùng một kho lưu trữ không?

myRepo/projectA/trunk
myRepo/projectA/tags
myRepo/projectA/branches
myRepo/projectB/trunk
myRepo/projectB/tags
myRepo/projectB/branches

hay bạn sẽ tạo kho lưu trữ mới cho mỗi kho?

myRepoA/trunk
myRepoA/tags
myRepoA/branches
myRepoB/trunk
myRepoB/tags
myRepoB/branches

Ưu và nhược điểm của từng loại là gì? Tất cả những gì tôi hiện có thể nghĩ đến là bạn nhận được các số sửa đổi hỗn hợp (vậy thì sao?) Và bạn không thể sử dụng svn:externalstrừ khi kho lưu trữ thực sự nằm ngoài. (tôi nghĩ?)

Lý do tôi hỏi là vì tôi đang xem xét hợp nhất nhiều repo của mình thành một, vì máy chủ SVN của tôi đã bắt đầu tính phí cho mỗi repo.

Vấn đề đơn lẻ so với nhiều vấn đề phụ thuộc vào sở thích cá nhân hoặc tổ chức.

Quản lý nhiều so với đơn chủ yếu phụ thuộc vào kiểm soát truy cập và bảo trì.

Kiểm soát truy cập cho một kho lưu trữ duy nhất có thể được chứa trong một tệp duy nhất; Nhiều kho lưu trữ có thể yêu cầu nhiều tệp. Việc bảo trì có những vấn đề tương tự - một bản sao lưu lớn hoặc nhiều bản sao lưu nhỏ.

Tôi tự quản lý. Có một kho lưu trữ, nhiều dự án, mỗi dự án có thẻ, thân và nhánh riêng. Nếu một cái quá lớn hoặc tôi cần phải cô lập một cách vật lý mã của khách hàng để họ thoải mái, tôi có thể nhanh chóng và dễ dàng tạo một kho lưu trữ mới.

Gần đây tôi đã tham khảo ý kiến ​​của một công ty tương đối lớn về việc chuyển nhiều hệ thống kiểm soát mã nguồn sang Subversion. Họ có ~ 50 dự án, từ rất nhỏ đến các ứng dụng doanh nghiệp và trang web công ty của họ. Kế hoạch của họ? Bắt đầu với một kho lưu trữ duy nhất, di chuyển sang nhiều kho lưu trữ nếu cần. Quá trình di chuyển gần như hoàn tất và chúng vẫn ở trên một kho lưu trữ duy nhất, không có khiếu nại hoặc vấn đề nào được báo cáo do đây là một kho lưu trữ duy nhất.

Đây không phải là vấn đề nhị phân, đen trắng.

Làm những gì hiệu quả cho bạn - tôi ở vị trí của bạn, tôi sẽ kết hợp các dự án vào một kho lưu trữ duy nhất nhanh nhất có thể khi tôi gõ lệnh, bởi vì chi phí sẽ là một vấn đề chính trong công ty (rất, rất nhỏ) của tôi.

JFTR:

số sửa đổi trong Subversion thực sự không có ý nghĩa bên ngoài kho lưu trữ. Nếu bạn cần những cái tên có ý nghĩa cho một bản sửa đổi, hãy tạo một TAG

Thông điệp cam kết dễ dàng được lọc theo đường dẫn trong kho lưu trữ, vì vậy chỉ đọc những thông báo liên quan đến một dự án cụ thể là một bài tập nhỏ.

Chỉnh sửa: Xem phản hồi của Blade để biết chi tiết về cách sử dụng cấu hình ủy quyền / xác thực duy nhất cho SVN.

Đối với trường hợp cụ thể của bạn, một (1) kho lưu trữ là hoàn hảo. Bạn sẽ tiết kiệm được rất nhiều tiền. Tôi luôn khuyến khích mọi người sử dụng một kho lưu trữ duy nhất. Bởi vì nó tương tự như một hệ thống tệp duy nhất: Nó dễ dàng hơn

• Bạn sẽ có một nơi duy nhất để tìm mã
• Bạn sẽ có một ủy quyền duy nhất
• Bạn sẽ có một số cam kết duy nhất (đã bao giờ cố gắng xây dựng một dự án trải dài trên 3 repo chưa?)
• Tốt hơn bạn có thể sử dụng lại các thư viện phổ biến và theo dõi tiến trình của mình trong các lib này (svn: externals là PITA và sẽ không giải quyết được tất cả các vấn đề)
• Các dự án được lên kế hoạch dưới dạng các hạng mục hoàn toàn khác nhau, có thể phát triển cùng nhau và chia sẻ các chức năng và giao diện. Điều này sẽ rất khó đạt được trong nhiều repo.

Có một điểm duy nhất cho nhiều kho lưu trữ: việc quản lý các kho lưu trữ lớn là không thoải mái. Bán phá giá / tải các kho lớn mất rất nhiều thời gian. Nhưng vì bạn không làm bất kỳ công việc quản lý nào, tôi nghĩ đó sẽ không phải là mối quan tâm của bạn;)

SVN mở rộng rất tốt với các kho lưu trữ lớn hơn, không có hiện tượng chậm lại ngay cả trên các kho lưu trữ khổng lồ (> 100GB).

Vì vậy, bạn sẽ ít gặp rắc rối hơn với một kho lưu trữ duy nhất. Nhưng bạn thực sự nên nghĩ về cách bố trí repo!

Tôi sẽ sử dụng nhiều kho lưu trữ. Ngoài vấn đề về quyền truy cập của người dùng, nó còn giúp việc sao lưu và khôi phục dễ dàng hơn. Và nếu bạn thấy mình ở một vị trí mà ai đó muốn trả tiền cho bạn cho mã của bạn (và lịch sử của nó), thì việc cung cấp cho họ chỉ là một kết xuất kho lưu trữ sẽ dễ dàng hơn.

Tôi đề nghị rằng việc hợp nhất kho lưu trữ chỉ vì chính sách tính phí của nhà cung cấp dịch vụ lưu trữ của bạn không phải là một lý do chính đáng.

Chúng tôi sử dụng một kho lưu trữ duy nhất. Mối quan tâm duy nhất của tôi là quy mô, nhưng sau khi xem kho lưu trữ của ASF (700 nghìn bản sửa đổi và tiếp tục tăng), tôi khá tin rằng hiệu suất sẽ không phải là vấn đề.

Các dự án của chúng tôi là tất cả các mô-đun lồng vào nhau có liên quan, khác nhau tạo thành một tập hợp các phụ thuộc cho bất kỳ ứng dụng nhất định nào. Vì lý do này, một kho lưu trữ duy nhất là lý tưởng. Bạn có thể muốn các thân / nhánh / thẻ riêng biệt cho từng dự án, nhưng bạn vẫn có thể thực hiện một thay đổi trên toàn bộ cơ sở mã của mình trong một bản sửa đổi. Điều này thật tuyệt vời để tái cấu trúc.

Lưu ý rằng khi đưa ra quyết định của bạn, nhiều kho lưu trữ SVN có thể chia sẻ cùng một tệp cấu hình.

Ví dụ (lấy từ liên kết trên):

Trong vỏ bọc:

$ svn-admin create /var/svn/repos1
$ svn-admin create /var/svn/repos2
$ svn-admin create /var/svn/repos3

Tệp: /var/svn/repos1/conf/svnserve.conf

[general]
anon-access = none # or read or write
auth-access = write
password-db = /var/svn/conf/passwd
authz-db = /var/svn/conf/authz
realm = Repos1 SVN Repository

Tệp: / var / svn / conf / authz

[groups]
group_repos1_read = user1, user2
group_repos1_write = user3, user4
group_repos2_read = user1, user4

### Global Right for all repositories ###
[/]
### Could be a superadmin or something else ###
user5 = rw

### Global Rights for one repository (e.g. repos1) ###
[repos1:/]
@group_repos1_read = r
@group_repos1_write = rw

### Repository folder specific rights (e.g. the trunk folder) ###
[repos1:/trunk]
user1 = rw

### And soon for the other repositories ###
[repos2:/]
@group_repos2_read = r
user3 = rw

Tôi sẽ tạo các kho lưu trữ riêng biệt ... Tại sao? Các số sửa đổi và thông báo cam kết sẽ không có ý nghĩa gì nếu bạn có rất nhiều dự án không liên quan chỉ trong một kho lưu trữ, chắc chắn nó sẽ là một mớ hỗn độn lớn trong ngắn hạn ....

Chúng tôi là một công ty phần mềm nhỏ và chúng tôi sử dụng một kho lưu trữ duy nhất cho tất cả quá trình phát triển của mình. Cây trông như thế này:

/client/<clientname>/<project>/<trunk, branches, tags>

Ý tưởng là chúng tôi sẽ có khách hàng và công việc nội bộ trong cùng một repo, nhưng cuối cùng chúng tôi đã để công ty của chúng tôi là "khách hàng" của chính nó.

Điều này thực sự hiệu quả đối với chúng tôi và chúng tôi sử dụng Trac để giao tiếp với nó. Số lượng bản sửa đổi là trên toàn bộ repo và không cụ thể cho một dự án, nhưng điều đó không phân biệt chúng ta.

Cá nhân, tôi sẽ tạo kho lưu trữ mới cho mỗi kho. Nó giữ cho quá trình thanh toán đơn giản hơn nhiều và làm cho việc quản trị trên toàn bộ dễ dàng hơn, ít nhất là liên quan đến quyền truy cập và sao lưu của người dùng. Ngoài ra, nó tránh được vấn đề số phiên bản toàn cầu, vì vậy số phiên bản có ý nghĩa trên tất cả các dự án.

Tuy nhiên, thực sự thì bạn chỉ nên sử dụng git;)

Một điều bổ sung cần xem xét là thực tế là việc sử dụng nhiều kho lưu trữ khiến bạn mất khả năng ghi nhật ký thống nhất (lệnh svn log), điều này sẽ là lý do chính đáng để chọn một kho lưu trữ duy nhất.

Tôi sử dụng TortuiseSvn và thấy rằng tùy chọn "Hiển thị Nhật ký" là một công cụ bắt buộc. mặc dù các dự án của bạn không liên quan, tôi chắc chắn rằng bạn sẽ thấy rằng việc có một thông tin tập trung về các dự án chéo toàn cầu (đường dẫn, id lỗi, thông báo, v.v.) luôn hữu ích.

Nếu bạn định hoặc sử dụng công cụ như trac wich tích hợp với SVN, bạn nên sử dụng một repo cho mỗi dự án sẽ hợp lý hơn.

Tương tự như đề xuất của Blade về việc chia sẻ tệp, đây là một giải pháp dễ dàng hơn một chút nhưng kém linh hoạt hơn. Tôi thiết lập của chúng tôi như vậy:

• / var / svn /
• / var / svn / bin
• / var / svn / repository_files
• / var / svn / svnroot
• / var / svn / svnroot / repos1
• / var / svn / svnroot / repos2
• ...

Trong "bin", tôi giữ một tập lệnh có tên là svn-create.sh sẽ thực hiện tất cả các công việc thiết lập tạo một kho lưu trữ trống. Tôi cũng giữ kịch bản sao lưu ở đó.

Trong "repository_files", tôi giữ các thư mục "conf" và "hooks" chung mà tất cả các kho đều có liên kết sym tới. Sau đó, chỉ có một bộ tệp. Tuy nhiên, điều này sẽ loại bỏ khả năng có quyền truy cập chi tiết theo từng dự án mà không phá vỡ các liên kết. Đó không phải là mối quan tâm khi tôi thiết lập nó.

Cuối cùng, tôi giữ thư mục chính / var / svn dưới quyền kiểm soát nguồn bỏ qua mọi thứ trong svnroot. Bằng cách đó, các tệp và tập lệnh của kho lưu trữ cũng được kiểm soát nguồn.

#!/bin/bash

# Usage:
# svn-create.sh repository_name

# This will:
# - create a new repository
# - link the necessary commit scripts
# - setup permissions
# - create and commit the initial directory structure
# - clean up after itself

if [ "empty" = ${1}"empty" ] ; then
  echo "Usage:"
  echo "    ${0} repository_name"
  exit
fi

SVN_HOME=/svn
SVN_ROOT=${SVN_HOME}/svnroot
SVN_COMMON_FILES=${SVN_HOME}/repository_files
NEW_DIR=${SVN_ROOT}/${1}
TMP_DIR=/tmp/${1}_$$

echo "Creating repository: ${1}"

# Create the repository
svnadmin create ${NEW_DIR}

# Copy/Link the hook scripts
cd ${NEW_DIR}
rm -rf hooks
ln -s ${SVN_COMMON_FILES}/hooks hooks

# Setup the user configuration
cd ${NEW_DIR}
rm -rf conf
ln -s ${SVN_COMMON_FILES}/conf conf

# Checkout the newly created project
svn co file://${NEW_DIR} ${TMP_DIR}

# Create the initial directory structure
cd ${TMP_DIR}
mkdir trunk
mkdir tags
mkdir branches

# Schedule the directories addition to the repository
svn add trunk tags branches

# Check in the changes
svn ci -m "Initial Setup"

# Delete the temporary working copy
cd /
rm -rf ${TMP_DIR}

# That's it!
echo "Repository ${1} created. (most likely)"

Tương tự như mlambie's sử dụng một repo duy nhất, nhưng đã đi xa hơn một chút với cấu trúc thư mục để dễ dàng thu phóng đến loại dự án cụ thể - các dự án dựa trên html web so với cs (C #) so với sql (SQL tạo / thực thi tập lệnh) so với xyz ( Các ngôn ngữ dành riêng cho miền như afl (AmiBroker Formula Language) hoặc ts (TradeStation)):

/<src|lib>/<app-settings|afl|cs|js|iphone|sql|ts|web>/<ClientName>/<ProjectName>/<branches|tags>

Lưu ý, tôi có thân cây sống trong các nhánh vì tôi coi nó như một nhánh mặc định. Đôi khi, điều khó khăn duy nhất là khi bạn muốn tạo nhanh một dự án khác, bạn cần phải xây dựng cấu trúc thẻ ProjectName / branch |. Tôi sử dụng cài đặt ứng dụng chỉ đơn giản là nơi lưu giữ các tệp cài đặt Ứng dụng cụ thể trong repo để có thể dễ dàng chia sẻ cho người khác (và thay thế ClientName thành VendorName và ProjectName thành AppName trong cấu trúc thư mục này; và các thẻ nhánh | có thể hữu ích để gắn thẻ cài đặt trên các mục chính khác nhau phiên bản của sản phẩm của nhà cung cấp quá).

Chào mừng bạn đến với bất kỳ nhận xét nào về cấu trúc của tôi - gần đây tôi đã thay đổi nó thành cấu trúc này và cho đến nay khá vui nhưng đôi khi cảm thấy thật khó khăn khi phải duy trì các cấu trúc thẻ branch | cho mỗi dự án - đặc biệt nếu dự án chỉ là một thiết lập dự án đơn giản để Unit Test một dự án khác.

Đề nghị của tôi là một. Trừ khi bạn có những người dùng khác nhau truy cập từng người, thì tôi muốn nói rằng hãy sử dụng nhiều.

Nhưng một lần nữa, đó không phải là lý do chính đáng để sử dụng nhiều.