SVN 저장소 하나 또는 여러 개?

관련되지 않은 여러 프로젝트가있는 경우 동일한 저장소에 두는 것이 좋은 생각입니까?

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

아니면 각각에 대해 새 저장소를 만들까요?

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

각각의 장단점은 무엇입니까? 현재 제가 생각할 수있는 것은 수정본 번호가 혼합되어 있고 (그래서 무엇입니까?) svn:externals저장소가 실제로 외부에 있지 않으면 사용할 수 없다는 것 입니다. (내 생각?)

내가 묻는 이유는 SVN 호스트가 리포지토리 당 청구를 시작했기 때문에 여러 리포지토리를 하나로 통합하는 것을 고려하고 있기 때문입니다.

단일 대 다중 문제는 개인 또는 조직의 선호도에 달려 있습니다.

다중 대 단일 관리는 주로 액세스 제어 및 유지 관리로 귀결됩니다.

단일 저장소에 대한 액세스 제어는 단일 파일에 포함될 수 있습니다. 여러 저장소에는 여러 파일이 필요할 수 있습니다. 유지 관리에는 하나의 큰 백업 또는 많은 작은 백업과 같은 유사한 문제가 있습니다.

나는 내 자신을 관리합니다. 하나의 저장소, 여러 프로젝트가 있으며 각각 고유 한 태그, 트렁크 및 분기가 있습니다. 하나가 너무 커지거나 고객의 편의를 위해 고객의 코드를 물리적으로 격리해야하는 경우 새 저장소를 빠르고 쉽게 만들 수 있습니다.

저는 최근에 비교적 큰 회사와 여러 소스 코드 제어 시스템을 Subversion으로 마이그레이션하는 것에 대해 상담했습니다. 그들은 매우 작은 규모에서 엔터프라이즈 응용 프로그램 및 회사 웹 사이트에 이르기까지 약 50 개의 프로젝트를 보유하고 있습니다. 그들의 계획? 단일 저장소로 시작하고 필요한 경우 여러 저장소로 마이그레이션하십시오. 마이그레이션이 거의 완료되었으며 여전히 단일 저장소에 있으며 단일 저장소이기 때문에 불만이나 문제가보고되지 않습니다.

이것은 바이너리, 흑백 문제가 아닙니다.

당신을 위해 일하는 일을하십시오 -내가 당신의 위치에 있다면, 명령을 입력 할 수있는 한 빨리 프로젝트를 단일 저장소로 결합 할 것입니다. 비용이 (매우 작은) 회사에서 주요 고려 사항이 될 것이기 때문입니다.

JFTR :

Subversion의 개정 번호 는 실제로 저장소 외부에서 의미가 없습니다. 개정판에 의미있는 이름이 필요한 경우 TAG를 생성하십시오.

커밋 메시지는 저장소의 경로별로 쉽게 필터링되므로 특정 프로젝트와 관련된 메시지 만 읽는 것은 간단한 작업입니다.

편집 : SVN에 단일 권한 부여 / 인증 구성을 사용하는 방법에 대한 자세한 내용 은 Blade 의 응답을 참조하십시오.

특정 경우에 하나의 저장소가 완벽합니다. 많은 돈을 절약 할 수 있습니다. 저는 항상 사람들이 단일 저장소를 사용하도록 권장합니다. 단일 파일 시스템과 유사하기 때문에 : 더 쉽습니다.

• 코드를 찾을 수있는 단일 장소가 있습니다.
• 단일 권한이 있습니다.
• 하나의 커밋 번호를 갖게됩니다 (3 개의 리포지토리에 분산 된 프로젝트를 빌드하려고 시도한 적이 있습니까?).
• 공용 라이브러리를 더 잘 재사용하고 이러한 libs에서 진행 상황을 추적 할 수 있습니다 (svn : externals는 PITA이며 모든 문제를 해결하지는 않습니다).
• 완전히 다른 항목으로 계획된 프로젝트는 함께 성장하고 기능과 인터페이스를 공유 할 수 있습니다. 이것은 여러 저장소에서 달성하기가 매우 어려울 것입니다.

여러 저장소에 대한 단일 지점이 있습니다. 거대한 저장소를 관리하는 것은 불편합니다. 거대한 저장소를 덤핑 /로드하는 데는 많은 시간이 걸립니다. 그러나 당신이 어떤 관리도하지 않기 때문에 나는 그것이 당신의 관심사가 아닐 것이라고 생각합니다.)

SVN은 더 큰 리포지토리에서 매우 잘 확장되며, 대규모 (> 100GB) 리포지토리에서도 속도 저하가 없습니다.

따라서 단일 저장소로 번거롭지 않습니다. 하지만 정말 repo 레이아웃에 대해 생각해야합니다!

여러 저장소를 사용합니다. 사용자 액세스 문제 외에도 백업 및 복원이 더 쉬워집니다. 그리고 누군가가 당신의 코드 (그리고 그 기록)에 대해 당신에게 지불하고 싶어하는 위치에 있다면, 그들에게 단지 저장소 덤프를주는 것이 더 쉽습니다.

호스팅 제공 업체의 과금 정책 때문에 리포지토리를 통합하는 것은 그다지 좋은 이유가 아니라고 제안합니다.

우리는 단일 저장소를 사용합니다. 내 유일한 관심사는 규모 였지만 ASF의 리포지토리 (700,000 개 수정 및 집계)를 확인한 후 성능이 문제가되지 않을 것이라고 확신했습니다.

우리의 프로젝트는 모든 관련 앱에 대한 종속성 집합을 형성하는 서로 다른 연동 모듈입니다. 이러한 이유로 단일 저장소가 이상적입니다. 각 프로젝트에 대해 별도의 트렁크 / 분기 / 태그를 원할 수 있지만 단일 개정 내에서 전체 코드베이스에 대한 변경 사항을 원자 적으로 커밋 할 수 있습니다. 이것은 리팩토링에 아주 좋습니다.

결정을 내릴 때 많은 SVN 저장소가 동일한 구성 파일을 공유 할 수 있습니다.

예 (위 링크에서 가져옴) :

쉘에서 :

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

파일 : /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

파일 : / 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

별도의 리포지토리를 생성 합니다 ... 왜? 리비전 번호와 커밋 메시지는 하나의 저장소에만 관련없는 프로젝트가 많은 경우 의미가 없습니다. 단기간에 큰 혼란이 될 것입니다 ....

우리는 소규모 소프트웨어 회사이며 모든 개발에 단일 저장소를 사용합니다. 트리는 다음과 같습니다.

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

아이디어는 우리가 클라이언트와 내부 작업을 동일한 저장소에 두는 것이었지만 결국 우리 회사를 "클라이언트"로 만들었습니다.

이것은 우리에게 정말 잘 작동했으며 Trac을 사용하여 인터페이스합니다. 개정 번호는 전체 리포지토리에 걸쳐 있으며 하나의 프로젝트에만 국한되지는 않지만 단계적으로 진행되지는 않습니다.

개인적으로 각각에 대해 새 저장소를 만들 것입니다. 이는 체크 아웃 프로세스를 훨씬 더 간단하게 유지하고 적어도 사용자 액세스 및 백업과 관련하여 전체 관리를 더 쉽게 만듭니다. 또한 전역 버전 번호 문제를 방지하므로 버전 번호는 모든 프로젝트에서 의미가 있습니다.

그래도 git을 사용해야합니다;)

고려해야 할 추가 사항은 여러 저장소를 사용하면 통합 로깅 (svn log 명령) 기능을 잃어 버릴 수 있다는 사실입니다. 이것만으로도 단일 저장소를 선택하는 좋은 이유가됩니다.

TortuiseSvn을 사용하고 "Show Log"옵션이 필수 도구라는 것을 알았습니다. 귀하의 프로젝트는 관련이 없지만 중앙 집중식 글로벌 교차 프로젝트 정보 (경로, 버그 ID, 메시지 등 ...)가 항상 유용하다는 것을 알게 될 것입니다.

SVN과 통합되는 trac과 같은 도구를 사용할 계획이거나 사용하려는 경우 프로젝트 당 하나의 저장소를 사용하는 것이 더 합리적입니다.

파일 공유에 대한 Blade의 제안과 유사하게 여기에 약간 더 쉽지만 덜 유연한 솔루션이 있습니다. 나는 다음과 같이 우리를 설정했습니다.

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

"bin"에는 빈 저장소를 만드는 모든 설정 작업을 수행하는 svn-create.sh라는 스크립트가 있습니다. 또한 백업 스크립트를 거기에 보관합니다.

"repository_files"에서는 모든 저장소가 sym 링크를 가지고있는 공통 "conf"및 "hooks"디렉토리를 유지합니다. 그런 다음 파일 집합이 하나뿐입니다. 그러나 링크를 끊지 않고 세분화 된 프로젝트 별 액세스 권한을 제거합니다. 내가 이것을 설정 한 곳은 문제가되지 않았습니다.

마지막으로, svnroot에있는 모든 것을 무시하고 / var / svn 메인 디렉토리를 소스 제어하에 둡니다. 이렇게하면 저장소 파일과 스크립트도 소스 제어를받습니다.

#!/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)"

단일 리포지토리를 사용하는 mlambie와 유사하지만 폴더 구조를 사용하여 특정 유형의 프로젝트로 쉽게 확대 / 축소 할 수 있습니다. 웹 html 기반 프로젝트 대 cs (C #) 대 sql (SQL 작성 / 실행 스크립트) 대 xyz ( afl (AmiBroker Formula Language) 또는 ts (TradeStation))와 같은 도메인 별 언어 :

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

기본 브랜치로 취급하므로 브랜치 내에 트렁크가 있습니다. 유일한 고통은 ProjectName / branches | tags 구조를 구축하는 데 필요한 다른 프로젝트를 빠르게 만들고 싶을 때입니다. 특정 앱 설정 파일을 다른 사람들과 쉽게 공유 할 수 있도록 저장소에 보관하기 위해 앱 설정을 단순히 사용합니다 (이 폴더 구조에서 ClientName을 VendorName으로, ProjectName을 AppName으로 대체합니다. 그리고 branch | tags는 다른 전공에 걸쳐 설정에 태그를 지정하는 데 유용 할 수 있습니다. 공급 업체 제품의 버전도).

내 구조에 대한 의견에 오신 것을 환영합니다. 최근에 이것을 이것으로 변경했고 지금까지 꽤 행복했지만 때로는 프로젝트별로 branch | tags 구조를 유지하는 것이 부담 스럽습니다. 특히 프로젝트가 단순히 다른 프로젝트를 단위 테스트하기위한 프로젝트 설정 인 경우 더욱 그렇습니다.

내 제안은 하나입니다. 각각에 다른 사용자가 액세스하지 않는 한 여러 사용자를 사용한다고 말하고 싶습니다.

그러나 다시 말하지만 그것은 다중을 사용하는 좋은 이유가 아닙니다.