중첩 트렁크/분기/태그를 사용할 수 있습니까? 최근 임베디드 프로젝트에서

Question

, 우리는 다음과 같은 svn의 구조를 사용했다 :

project 
    branches 
    tags 
    trunk 
     electronics 
     software 
      branches 
      tags 
      trunk 

당신이 볼 수 있듯이, 소프트웨어 부분에 대한 중첩 지점/태그/트렁크 디렉토리가있다. 소프트웨어 개발자가 나머지 부분에 대해 걱정하지 않고도 작업 할 수 있기 때문에 이것은 매우 실용적이었습니다.

이 나에게 권리을 보이지 않는 그러나, 때문에 그들이이 체크 아웃하는 경우 다운로드 할 수있는 모든 쓰레기 불편을 할 수있는 여러 분기의 수준 및 계층 구조에서 더 높은 일하는 사람들의 혼동 할 수 있습니다 상단 트렁크 ...

그래서 저는 다음 프로젝트를위한 1 트렁크 전용 저장소를 생각하고 있습니다. 개발자가 소프트웨어가 아닌 것을 원하지 않는다면, 그들은 단지 체크 아웃 project/trunk/software과 project/branches/br-1234/software으로 갈 수 있습니다 등

중첩 트렁크에 대해 어떻게 생각하십니까? 찬성 & 죄송합니다!

사이드 질문으로 : 브랜치/태그는 항상 트렁크 (또는 다른 브랜치)의 복사본이어야합니까? 아니면 트렁크의 하위 디렉터리에 브랜치를 만들 수 있습니까?

Answer 1

중첩 트렁크는 내게 부모 코드와 다른 수명주기를 가진 코드 모음을 표시합니다. 나는이 개념적으로 분리 된 프로젝트를 고려할 것이다. 또한 저장소에는 최상위 프로젝트가 여러 개있을 수 있으므로 각 프로젝트마다 별도의 저장소를 유지 관리해야합니다. 필자는 별도의 저장소 수준 구성 (액세스 가능성, 전송 프로토콜, 인증/권한 부여 (저장소에서 구성 할 수 있음에도 불구하고))이 필요할 때 별도의 저장소를 사용하는 것을 고려합니다.

main_project 
    branches 
    tags 
    trunk 
     electronics 
software 
    branches 
    tags 
    trunk 

은 그럼 당신은 software의 컴파일 된 형태를 포함, 혹은 main_project/trunk 내에서 software/trunk를 가리 키도록 외부 SVN 참조를 사용하는 것을 고려 main_project/trunk에 libs 폴더를 추가 할 수 있습니다 중 하나.

또한 "main_project"는 "electronics"라는 이름이 더 좋을 수도 있습니다.이 경우 "trunk"아래에 여분의 "electronics"폴더가 제거됩니다.

Answer 2

확실히 이상적이지는 않습니다. 매우 혼란 스럽습니다. 지점/태그를 만들기 위해 실제로 많은 저장 공간을 차지하지는 않는다는 점을 감안할 때 이와 같은 구조로 끝낼 이유는별로 없습니다. IMHO 프로젝트 레벨에서만 지원됩니다.

Answer 3

누구에게? 전복의 교황이 없으며, 모든 조직은 최선을 다하는 일을 자유롭게 할 수 있습니다. 그 자유를주는 SVN의 다양성은 좋은 것입니다.

Answer 4

모든 질문에 대한 짧은 대답 : 아니오.

나는 토론 '이 첫 번째이다 "는 애보트 & 코스텔로을 상상 해요 : "나는 트렁크에 병합 ""트렁크? " "통합 지점의 트렁크" "그래서 트렁크가 최신 상태입니까?" "어떤 트렁크입니까?"

새로운 팀원은 이전 경험과 모순되는 계획에 적응하기가 어려울 것입니다. 그들은 내부 문서를 검색하거나 정말 간단해야하는 것에 대해 질문해야합니다.

많은 도구 & 표준이 아닌 레이아웃을 사용하는 경우 IDE가 작동하기가 훨씬 부담 스럽습니다.

트렁크 또는 분기의 하위 집합을 분기/태그 지정하는 것에 대한 두 번째 질문이 더 중요합니다. subversions와 함께 저렴한 복사본을 공간/시간에 대한 이득을 얻을 수 없습니다/하위 집합을 태그로 - 그리고 더 중요한 것은 svn : mergeinfo는 사람들이 최상위 레벨이 아닌 다른 곳에 브랜치/태그 할 때 유용하지 않게됩니다.