분기 및 트렁크의 적절한 SVN 사용

Question

내 SVN 프로젝트의 트렁크 및 분기의 적절한 사용에 관한 질문이 있습니다. 팀의 프로젝트를 위해 우리는 매년 3 개의 메이저 릴리스를 만들고 때로는 마이너 릴리스 또는 2를 만듭니다. 어느 시점이든 우리는 2 ~ 3 건의 적극적인 개발을 진행할 수 있습니다.

/branches/project1/2009.01
/branches/project1/2009.06
/branches/project1/2009.09
/branches/project1/2009.10

: 우리는 같은 구조 지점에서 모든 개발을하고있다

현재까지 다음 릴리스에 대한 분기를 만들 준비가 될 때마다 현재 분기의 변경 사항을 트렁크에 병합 한 다음 트렁크에서 새 분기를 만듭니다. 그런 다음 트렁크를 통해 병합하여 이전 릴리스 분기에 대한 버그 수정을 통해 최신 dev 브랜치를 수동으로 최신 상태로 유지합니다. 트렁크에 대한 개발이나 커밋이 수행되지 않습니다 (병합 커밋 제외). 이제 트렁크가 필요한 것조차 궁금합니다. 이전 릴리스 분기에서 직접 다음 릴리스 분기를 직접 작성하고 한 분기에서 다음 분기까지 버그 수정 사항을 직접 병합하는 것이 잘못된 것입니다. 트렁크에서 프로젝트를 삭제해도 될까요?

모든 SVN 베스트 프랙티스는 개발을 위해 트렁크를 사용함을 나타내는 것처럼 보이지만 한 번에 2 ~ 3 개의 릴리스에서 작업 할 수 있으므로 각 릴리스마다 별도의 분기를 사용하는 것이 훨씬 쉬워 보입니다. 내 SVN 사용에 기술적 인 문제가 있습니까? 제안?

감사합니다.

Answer 1

나는 일하는 방식에 전혀 문제가 없다고 생각합니다. 그것은 당신과 당신의 팀을 위해 작동한다면 그것은 훌륭합니다. 트렁크를 유지하는 것의 한 가지 장점은 각 신제품이 이전 제품 분기에 걸려있는 더 지저분한 상황으로 끝나기보다는 모든 지사가 트렁크에서 벗어난다는 것입니다. 리비전 그래프를 그릴 경우 매우 복잡해집니다.

Answer 2

나는 the_mandriill에 동의한다. 당신이하고있는 것에는 아무런 문제가 없지만, 더 잘할 수 있는지 항상 질문하는 것은 잘못된 것이 없다.

cmcrossroads이라는 훌륭한 기사가 있는데, 이는 코드 관리의 다양한 방법에 대한 충분한 아이디어를 제공 할 것입니다.

k

Answer 3

근무 방식이 괜찮습니다. 현재 모든 것이 트렁크를 거치므로 모든 것이 어디에 있는지 알 수있는 단일 참조 지점이 있습니다. 트렁크를 사용하지 않을 때의 문제점은 버그가 어디로 갔는지에 대한 확실한 지식을 얻는 것입니다. 트렁크의 경우 문제는 선형입니다. 트렁크가 없으면 모든 지점을 다른 모든 지점과 비교하여 그 지점의 내용을 확인해야하므로 지수가됩니다.

개인적으로 릴리스 브랜치에서 코드가 생성되는 것을보고 싶지 않습니다. 먼저 dev 브랜치에서 수정 한 다음 트렁크를 통해 릴리스 분기에 병합하십시오. 때로는 이것이 실용적이지는 않지만 병합 기록은 언제나 그렇게 보이게하기 위해 언제든지 손을 대볼 수 있습니다. 일반적으로 dev 브랜치, 트렁크, 릴리즈를 통한 견고한 코드 흐름은 이해할 수 있습니다.

그 이유는 모든 수정에 트렁크 개정 번호를 할당하고 트렁크에 대한 각 릴리스의 병합 기록을 검사하여 해당 수정을 추적 할 수 있기 때문입니다. 이것을 수정하여 어떤 수정 프로그램이 릴리스되었는지 정확하게 확인할 수도 있습니다. (예를 들어, 내 대답 here 참조).

수정본이 릴리스 지점에서 비롯된 경우, 이러한 종류의 비교는 훨씬 어려워집니다. 비록 내가 생각할지라도 여전히 가능하다. 그러나 트렁크가 없다면 각 릴리스를 서로 비교해야하며 훨씬 더 어려운 제안이됩니다.