기본적으로 내 질문은 전복의 모범 사례에 관한 것입니다. 나는 Subversion에 매우 익숙하지 않기 때문에 너무 많이 알지 못합니다.별도의 프로젝트를위한 별도의 리포지토리가 필요합니까?
여기 내 질문이 있습니다.
저는 현재 두 프로젝트에서 작업 중이며 둘 다 한 명의 개발자가 작업하고 있으므로 두 프로젝트를 같은 저장소에 저장하거나 각 프로젝트마다 별도의 저장소를 만들어도되는지 궁금합니다. 나는 분리 된 것들을 만드는 것이 훨씬 더 좋은 아이디어라고 생각한다. 깨끗하게 보일 것이고 HD 공간의 관점에서 비용을 지불하지 않을 것이기 때문에 왜 그렇게 걱정할 것인가?
그런 생각을하곤했지만 프로젝트에 사용 된 일부 코드가 다른 저장소 (다른 저장소)에서 유용 할 수 있다는 것을 발견하기 시작한 이래로 모든 것을 단일 저장소에 저장하는 것이 가장 좋습니다. .
흠, 좋은 관찰입니다. 감사. – itsaboutcode
어떻게 든 서로 관련이있는 여러 프로젝트에서 일하는 한 명의 개발자에게, 사실 하나의 큰 저장소로 작업을 시작하는 것이 좋습니다. 쉽게 물건을 전환하고 분기 할 수 있기 때문입니다.
하나 이상의 프로젝트가 나중에 분리 - 예 : 팀이 프로젝트에 착수 할 가능성이있는 경우 - 처음부터 프로젝트를 분리하는 것을 고려하십시오. 그렇게하면 프로젝트 당 깨끗한 버전 기록이 생깁니다. (즉, 다른 프로젝트의 커밋과 섞이지 않은 히스토리. 덤프 도구를 사용하여 언제든지 필터링 할 수 있지만 더 편리하지는 않습니다.)
또한 하나 이상의 작업이 언젠가 오픈 소스가 될 가능성이 높습니다. 오로와 같은 소셜 코딩 사이트가 커밋을 조사하고, 과거에 당신이 만든 실제 커밋을 발견하면 프로젝트의 활동 통계 및 프로필의 전문성을 추가하기 때문에 깨끗한 버전 기록을 보유하게 될 것입니다. 별로 중요하지 않고 어떤 어려운 사실에 대해서도 말하지 않지만 여전히 가지고있는 것이 좋습니다.
브라이언 아그 뉴 (Brian Agnew)는 대답에서 분리를 위해 여러 가지 좋은 추가 점을 제시합니다.
사람들이 리포지토리에서 작업하기 시작하면 path-based authentication in Subversion을 수행 할 수 있으므로 하나의 큰 저장소를 사용하여 작업 할 때 보안 문제가 발생하지 않아야합니다.
그러나 커밋 메시지를 나중에 이해하려면 각 커밋을 관련된 프로젝트로 표시해야합니다.
나는 박리 당 저장소 (라이브러리, 실행, 혹은 라이브러리 나 실행 파일의 밀접하게 관련 세트)쪽으로 경향이있다. 왜 ? 저장소 내 구조와 해당 저장소 내의 각 구성 요소가 어떤 상태에 있는지 걱정할 필요없이 개별적으로 태그를 지정하고 분기 할 수 있습니다.
특정 저장소 (예 : 클라이언트 실행 파일) 만 체크 아웃 할 수 있습니다. 단순히 다른 저장소의 빌드 아티팩트 (라이브러리)를 소비합니다. 이는 팀에서 간단한 관리자에게 유용 할 수 있으며, 팀이 특정 코드 세트를 기업에서 사용하는 전체 코드 세트에 노출시키는 것이 아니라 집중시키는 데 유용 할 수 있습니다 (솔로 개발자가되어 주셔서 감사합니다. 따라서 귀하의 경우에는 적용되지 않을 수 있습니다.) !)
여러 저장소가 관리하기가 저렴합니다. 그것은 분리를 달성하며 이는 (말하자면) 한 저장소가 다른 구성 요소가 사용하는 라이브러리 또는 구성 요소를 작성하는 데 유용합니다.해당 라이브러리/구성 요소에 고유 한 리포지토리가있는 경우 개별적으로 빌드 및 버전을 올리고 빌드 아티팩트를 사용 중이며 사용하지 않아야하는 해당 라이브러리의 하위 구성 요소를 사용하지 않고 있다는 사실을 알고 클라이언트가 사용할 수 있도록 게시 할 수 있습니다 . 하나의 저장소에 모든 것을 넣으면 쉽게 적용 할 수 있을지 확신 할 수 없습니다.
이 문맥에서 "해제 가능"하다고 설명 할 수 있습니까? 당신이 말하는 것은 흥미로운 것 같지만 아직 완전히 이해하지는 못합니다. –
해제 가능 라이브러리, 실행 파일 등이 될 것입니다. –
나는 편집, 환호로 지금 얻습니다. –
내가 그것을 독립적가있는 경우 두 개의 프로젝트를 분리하는 것이 유리하다 생각 :
리포지토리의 루트에 각 프로젝트의 디렉터리를 만들고 그 아래에 trunk/branches/tags를 만들면 각 프로젝트의 로그를 쉽게 쉽게 확인할 수 있습니다. –
맞습니다. 하지만 Trac 같은 프로젝트 관리자 시스템이 어떻게 두 프로젝트를 개별적으로 관리 할 수 있었는지는 알지 못합니다. (로그 및 기타 기능 ...) – Phong
Trac에 대해서는 잘 모르겠지만 작동하지 않을 수 있습니다 –
내가하는 각 프로젝트마다 별도의 리포지토리를 만들고, 내가 만든 모든 라이브러리에 대해 다른 리포지토리를 유지합니다.
제 경우의 유일한 예외는 모든 간단한 루비 스크립트가 단일 저장소에 보관된다는 것입니다.
커밋 주석이 더 이해하기 쉽도록하고 별도의 프로젝트를 유지하는 데 도움이됩니다. 다른 것들 중에서도 (이미 언급 한 바와 같이) 특정 프로젝트에 어떤 일이 발생할 수 있는지 알지 못하기 때문에 별개입니다.
그 드문 경우 소스를 추출해야 할 때,'svnadmin dump'와 dumpfilter로 여전히 할 수 있습니다. –
나는 모든 프로젝트를 하나의 빅 저장소에 가지고 있었지만 약간 혼란 스러웠습니다. 영향을받은 경로 이름을 보지 않고 어떤 메시지가 어떤 프로젝트에 전달되었는지 알 수 없었습니다. 모든 프로젝트에서 커밋을하면 개정 번호가 부풀어 오르고 기술적으로 변경되지 않은 다른 모든 프로젝트의 작업 복사본이 변경됩니다 (변경된 파일이 업데이트되지 않은 경우에도 마찬가지 임).
SVN 서버에서 작업하고 있다면 괜찮을 것입니다. 그러나 이것들은 로컬 디스크의 리포지토리에 불과합니다. 결국 나는 svndumpfilter을 사용하여 이들을 모두 프로젝트 별 저장소로 분리하는 방법을 배웠습니다.
프로젝트간에 코드를 공유하고 싶다면 더 좋은 방법은 svn:externals 속성을 설정하는 방법을 배우는 것입니다. 저장소 내에서 물건을 복사하는 것은 디스크에서 물건을 복사하고 여러 번 확인하는 것보다 낫습니다. 파일의 변경 사항을 사용하는 모든 프로젝트에 파일의 변경 사항을 전파하려면 많은 수작업을해야합니다. svn : externals를 사용하면 다른 저장소를 참조 할 수 있으므로 공유 코드 용 저장소와 각 프로젝트 용 저장소를 만들 수 있습니다.
Common/Util 프로젝트에'svn : externals' 링크를 설정할 때 Common 프로젝트가 안정되면 HEAD 대신에 특정 버전을 사용하는 것이 가장 좋습니다. 기술적으로 오래된 다른 종속성을 피하십시오. 단점은 종속 프로젝트에서 참조를 수동으로 업데이트하는 것입니다. – devstuff
질문이 있으십니까? (중복?) 질문 : http://stackoverflow.com/questions/1761513/multiple-svn-repositories-or-single-company-repository –
감사합니다. Sander Rijken, 질문 닫기. – itsaboutcode
"이기는"대답은 내 자신의 의견입니다. –