관련되지 않은 여러 프로젝트가있는 경우 동일한 저장소에 두는 것이 좋은 생각입니까?
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을 사용하여 인터페이스합니다. 개정 번호는 전체 리포지토리에 걸쳐 있으며 하나의 프로젝트에만 국한되지는 않지만 단계적으로 진행되지는 않습니다.