Subversion 태그와 브랜치

Question

누구나 일반적으로 권장되는 것 ('태그'와 '브랜치'라고하는 병렬 디렉토리)보다 하위 버전에서 태그와 브랜치를 관리하기위한 더 나은 기술을 생각해 냈습니까?

Answer 1

브랜치 (Branches)를 가질 때 병렬 디렉터리를 가질 수 있다는 것 외에도 할 수있는 것은 SVN 스위치를 둘 중 하나에서 작업 할 때마다 두 브랜치간에 전환하는 것입니다. 아마도 당신은이 시스템에 대해 당신이 "더 좋게"되기를 원하는 것을 분명히해야하고 사람들은 제안을 할 수있을 것입니다.

Answer 2

분기/태그/etc와 같은 정보를 전달하기 위해 저장소 네임 스페이스를 사용하는 것은 근본적으로 SVN 모델입니다. 원하는 모델이 다른 모델이라면 SVN이 아닌 다른 모델을 원할 것입니다.

SVN에서 CVS 스타일 레이블과 같은 메타 데이터가 부족한 것은 의도적 인 디자인 결정입니다. 트리에서 선택한 분기/태그/프로젝트의 배치가 무엇이든 관계없이 각 용도별로 병렬 디렉토리 집합으로 줄여줍니다. 이제 남은 일은 지점과 태그에 대한 올바른 이름 지정 전략을 선택하는 것입니다.

내가 좋아하는 컨벤션은 전체 중량급 가지와 경량 "나뭇 가지"사이의 분리입니다. 내가 일하는 그룹의 컨벤션은 지점에서 장기간의 개발이 이루어지고 릴리스 엔지니어가 각 지점을 알고 부분적으로 책임이 있지만 모든 엔지니어가 스크래치 공간으로 사용할 짧은 수명의 나뭇 가지를 만들 수 있다는 것입니다. 하나의 체크인에 맞추기에는 너무 큰 문제이지만 릴리스 엔지니어링 지원을 요구할만큼 충분히 큰 문제는 아닙니다. 나뭇 가지는 나뭇 가지와 비슷한 별도의 병렬 '나뭇 가지'디렉토리에 있으며, 명명 규칙에는 나뭇 가지가 다루기 위해 의도 된 버그 ID 번호와 생성자의 사용자 ID가 있습니다.

Answer 3

"트렁크, 태그, 브랜치 및 스트림"전략을 사용합니다.

"트렁크"는 프로덕션 환경에있는 최신 버전이 배치되는 곳입니다.

"태그"는 스트림이 완료되었을 때 "복사 대상"이 발생하는 곳이며 보관 목적으로 스트림의 상태를 저장해야합니다. 또한 특정 지점에서 개발을 계속할 수 있습니다.

"지점"은 주류 개발과 완전히 다른 무언가가 발생할 때입니다. 일반적으로 지점은 매우 드뭅니다.

"스트림"은 우리가 가장 많이 사용하는 것입니다. 개발 스트림은 특정 수정 또는 개발 노력 (예 : 변경 요청 완료)을위한 스트림과 같은 작업 기반의 집중입니다. 스트림은 서로 병합 할 수 있지만 스트림은 svn 전략에 따라 순위가 매겨집니다. 예를 들어, 우리는 cr 릴리스를위한 하나의 스트림과 앱 지원 릴리스를 푸는 다른 스트림을 가지고있었습니다. CR 스트림은 자체 변경 사항 외에도 앱 지원 수정 사항을 통합해야하기 때문에 순위가 높아졌습니다. 상위 순위에있는 스트림은 낮은 스트림 (필요에 따라)이 병합됩니다. 마지막으로 스트림이 생산 준비 상태가됩니다. 태그가 붙은 다음 트렁크에 "복사"되고 이후 추가 스트림의 기본으로 사용됩니다 (일반적으로 태그가 사용 되더라도).

그러나 스트림을 최대한 사용하는 것은 완료하는 데 2 ​​주 미만의 짧은 작업을위한 것입니다. 이러한 스트림은 여러 순위가 높은 스트림으로 신속하게 병합 될 수 있으며 나중에 나중에 다른 높은 순위의 스트림으로 병합됩니다. 예를 들어, 앱 지원이 cr보다 낮기 때문에 모든 앱 지원 빠른 수정을 스트림에 복사 한 다음 작업을 수행 한 다음 앱 지원에 병합 한 다음 cr 스트림에 병합합니다.