릴리스 분기를 다시 트렁크에 병합하지 않으면 어떤 이점이 있습니까?

Question

TLDR; 우리 팀의 SVN 브랜치 전략은 트렁크에 커밋되지 않습니다. 이것은 안티 패턴처럼 느껴지고, 나는 그 이유를 즉시 설명 할 수 없습니다. 이것이 문제이며 변화를 추진하기에 충분히 큰 문제입니까?

세부 정보 -

내 팀의 합의 된 전략을 분기하여 매월 릴리스 지점을 만드는 것입니다. 릴리즈는 .ear 파일을 배포 할 다른 팀에게 넘김으로써 처리됩니다. - SVN 저장소를 가리 키지 않습니다.

나중에 사용할 수 있도록 각 분기의 생산에 가기 전에 마지막 커밋의 태그를 유지합니다. 우리는 부서진 빌드를 잡기 위해 매일 개발 환경을 구축합니다.

그러나 다음 릴리스를위한 분기를 만들 때 기존 릴리스 분기에서 분기합니다. 그리고 결코 다시 커밋하거나 트렁크와 상호 작용하지 않습니다. 분기 된 릴리스에 대한 모든 분기 후 변경 사항은 이전 릴리스가 완료 될 때까지 병합됩니다.

Trunk 
|\ 
| April 
|  \ 
|  May 
.   \ 
.   June... 
. 
. 

우리는 그들이에 출시 될 전망이다 릴리스로 병합 프로젝트 가지, 문제 했어.

우리는 기능 가지를 사용하지 않기 때문에 롤백 또는 릴리스에서 변경 제거 모든 릴리스 지점은 dev 및 버그 수정 지점이기 때문에 불편합니다.

이외에도이 분기 전략, 저장소에 미치는 영향 또는 기타 위험 요소가있는 기본적인 SVN 기능이 있습니까?

Answer 1

당신이 말했듯이, '릴리스에서 변경 사항을 롤백하거나 변경 사항을 제거하는 것은 불편한 일이지만 여전히 가능합니다.'라고 상상할 수 있습니다.

이 SVN 설치로 새 개발자를 고용하면 많은 시간을 낭비하게됩니다. 그들은이 저장소에 대해 배우고, 기여하고, 문제를 해결하는 데 더 힘들어 할 것입니다. 읽는 코드를 갖는 것이 중요하다는 것과 같은 방식으로, 읽기 가능한 저장소를 갖는 것이 중요합니다.

팀에서 저장소 문제가 발생하면 책, 웹 사이트 및 다른 사람들의 외부 조언을 구하기가 더 어려워집니다.

모든 종류의 타사 소프트웨어를 저장소에 통합하려는 경우 트렁크 사용에 대한 SVN 규칙이 무시 되었기 때문에 어려울 수 있습니다.

리포지토리 조직이 월간 리디렉션에 의해 어색하게 제한되는 것처럼 보입니다. 한 달에 두 개의 코드 롤을해야한다면 어떻게 될까요? 반월 지점을 만드십니까?

팀에 SVN 태그의 개념이 누락되었습니다. 태그는 편집 할 수없는 최종 버전입니다. 이러한 태그에는 일반적으로 Application-1.2.3과 같은 버전 번호가 있습니다. 버전 번호는 정수의 삼중 항입니다 : MAJOR.MINOR.PATCH. 이것은 개발자에게 응용 프로그램의 변경이 얼마나 큰지, 그리고 한 버전이 다른 버전과 얼마나 다른지를 나타냅니다.

이 온라인으로 책을 한 번 봐, 나는 그것이 유용하다고 :
http://svnbook.red-bean.com/en/1.8/svn.basic.html

이유를 전혀 분기되는