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

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

---

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

---

We are a small software company and we use a single repo for all of our development. The tree looks like this:

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

The idea was that we would have client and internal work in the same repo, but we ended up having our company as a "client" of itself.

This has worked really well for us, and we use Trac to interface to it. Revision numbers are across the whole repo and not specific to one project, but that doesn't phase us.

---

Personally, I'd create new repositories for each. It keeps the check out process much simpler and makes administration on the whole easier, at least with regards to user access and backups. Also, it avoids the global version number problem, so the version number is meaningful on all projects.

Really though, you should just use git ;)

---

one additional thing to consider is the fact that using multiple repositories cause you to loose the ability to have unified logging(svn log command) this alone will be good reason for choosing single repository.

I use TortuiseSvn and found that the "Show Log" option is a mandatory tool. although your projects are unrelated, I'm sure that you will find that having a centralized global cross-projects information (paths, bug ids, messages and so on....) is always useful.

---

If you plan to or use tool like trac wich integrate with SVN, it makes more sense to use one repo per project.

---

Similar to Blade's suggestion about sharing files, here is a slightly easier, yet less flexible solution. I setup ours like so:

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

In "bin", I keep a script called svn-create.sh which will do all of the setup work of creating an empty repository. I also keep the backup script there.

In "repository_files", I keep common "conf" and "hooks" directories that all of the repositories have sym links to. Then, there's only one set of files. This does eliminate the ability to have granular, per-project access without breaking the links, though. That was not a concern where I set this up.

Last, I keep the main directory /var/svn under source control ignoring everything in svnroot. That way the repository files and scripts are under source control as well.

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

---

My suggestion is one. Unless you have different users accessing each one, then I'd say use multiple.

But again, even that's not a good reason to use multiple.

---

Similar to mlambie's of using a single repo, but went bit further with the folder structure to easily zoom to particular type of projects - web html based projects vs. cs (C#) vs. sql (SQL create/execute scripts) vs. xyz (Domain Specific Languages like afl (AmiBroker Formula Language) or ts (TradeStation)):

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

Note, I have trunk live within branches as I treat it as the default branch. The only pain sometimes is when you want to quickly create another project you need to build out the ProjectName/branches|tags structure. I use app-settings simply as place to keep specific Apps settings files in repo so easily shareable to others (and substitute ClientName to VendorName and ProjectName to AppName in this folder structure; and the branches|tags can be useful to tag settings across different major versions of vendor products too).

Welcome to any comments on my structure - I recently changed it to this and so far pretty happy but sometimes find it burdensome to maintain branches|tags structures per project - particularly if the project is simply a project setup simply to Unit Test another project.

참고URL : https://stackoverflow.com/questions/252459/one-svn-repository-or-many