여기에 의견을 구합니다. 다음은 SVN 특정 질문 또는 더 일반적인 버전 제어 질문으로 간주 될 수 있습니다.태그에서 분기
프로젝트의 소스는 아마도 유지 보수 작업을 위해, 릴리스에 해당하는 지점에서 분기 할 경우, 그것은 바람직하다 :
태그에서(A) 지점, 또는
(b) 태그가 복사하는 노드 (예 : 트렁크)에서 분기?
이러한 두 가지 접근 방식의 장단점은 무엇입니까? 그것은 전혀 중요합니까?
감사합니다. 내 자신의 질문에 대한 부분적인 대답에
나는 (svn 1.5+가 서버와 클라이언트 측에 있다고 가정 할 때) svn의 병합 추적을 사용하여 쉽게 트렁크에 병합을 넘겨 줄 수 있기 때문에 (b) 제안 할 것입니다. 기술 (a)를 사용했다면, 병합을 직접 관리해야합니다. 동일한 분기에서 다중 병합을 수행하지 않는다고 가정하면 나쁘지 않습니다. 패치로 평소와 같이 태그에서 브랜치를 만드는 것을 고려하고 있다면 트렁크에 패치를 다시 가져 오기 위해 트렁크 라인에 두 번 이상 병합해야 할 필요가있을 것입니다.
태그는 소스 코드에서 특정 마일스톤을 신속하게 구축하기위한 목적으로 특정 코드 행 (트렁크 또는 분기)의 마일스톤을 제때 또는 "스냅 샷"으로 표시하는 데 선호되는 방법입니다 이정표 또는 이정표를 쉽게 구분할 수 있습니다. 그것 이외에, 모든 일은 간선과 분지 사이에서 행해졌. 이미 언급했듯이 svn log을 사용하여 쉽게 복사 된 태그의 버전/소스를 쉽게 찾을 수 있습니다. 예를 들어 svn log --stop-on-copy -v tags/yourtag은 최신 사본 버전을 출력의 끝에 넣습니다. 이를 통해 개정판에서 태그가 작성된 활성 코드 행을 분기 할 수 있습니다.
:
(A) 지점의 장점은 더 분명 특정 릴리스와 관련된 또는 후보자에게 공개되고있다
(b)는 트렁크 개정의 장점이있다
어느 쪽이든간에, 트렁크에서 태그를 찾는 것보다는 태그에서 트렁크로 들어가는 것이 더 쉬울 지 모르지만 어느 쪽이든 하나를 설정할 수 있습니다. 따라서 이와 관련하여 (a)가 바람직하다.
또한 : 지점 유지 보수를 다시 트렁크에 병합 할 때, (b) 더 자연스러운 옵션 인 것 같습니다.
추가 의견, 생각 또는 링크를 환영합니다.
필자는 나중에 주 프로젝트를 추가하고 패치하고 (b) 이동하려는 경우 (a) 경로를 선택했다.
(a)를 사용하여 병합을 직접 관리 할 필요가 없습니다. mergeinfo를 사용하여 분기에서 트렁크로 명령을 병합 할 수 있습니다. 유일한 '문제'는 트렁크의 mergeinfo에 브랜치 개정 정보 외에 작성중인 리비전과 함께 태그 URL이 포함되어 있다는 것입니다. 그것은 아마도 당신이 원하는 것이 아닙니다. 반면에, 그것은 중요한 문제로 간주되지 않을 수도 있습니다. [나는 재 통합을 실험하지 않았다. ] 보통의 병합뿐입니다.] 나에게, (b) 일을하는 올바른 방법처럼 느껴지지만, 나는 여전히 (a)가 사실 그렇게 잘못되었다는 것을 강하게 확신하지 못합니다. – Rhubbarb