2009-06-15 8 views
4

저는 얼마 동안 버전 관리를 위해 StarTeam을 사용했지만 Subversion으로 이동하려고합니다. 나는 Subversion book을 읽었으며 StarTeam에는 Subversion이 갖고 있지 않은 중요한 특징 중 하나가 레이블의 개념입니다. Subversion에는 레이블이 있지만 StarTeam에서는 다른 것을 의미합니다. StarTeam에서는 일련의 파일에 "준비 완료"라는 레이블을 붙인 다음 해당 파일 만 확인하고 특정 릴리스에 포함시킬 수 있습니다. 그런 다음 해당 버전에 포함 된 파일을 나타내는 고정 라벨을 만들 수 있습니다 (Subversion 태그와 유사하지만 디렉토리의 모든 항목이 아닌 특정 수정 버전에 있음).Subversion에서 어떤 파일이 다음 릴리스에 있어야하는지 나타내는 "레이블"을 만듭니다.

Subversion에서 이러한 기능을 사용할 수있는 방법이 있습니까? 태그를 추가 할 리비전을 지정할 수 있지만 코드가 있고 릴리스를하려고하는 상황에서 어떤 일이 일어나고 버그를 찾거나 특정 변경 내용을 포함하지 말아야한다고 결정할 수 있습니다. 저장소와 로컬 작업 복사본을 기반으로 태그를 만들 수 있지만 포함되지 않아야하는 파일의 특정 버전을 확인하고 태그를 만드는 것이 포함됩니다. "레이블"을 작성할 준비가되면 원하지 않는 파일의 헤드 버전에 해당 레이블을 넣지 않을 것입니다. Subversion에서 특정 빌드를 자동으로 지정하는 방법은 없습니다. 이것은 지점에서 새로운 기능을 개발해야하는 것은 아니지만, 개정판이 트렁크 (또는 태그를 만들지 여부)에 포함되어 있지만 포함되지 않아야합니다. 되돌릴 필요가 없을 수도 있습니다. 변경은 적절할 수 있지만 향후 릴리스에서는 현재의 것이 아닙니다. 필요한 정확한 파일 버전으로 특정 버전이없는 경우 리포지토리와 작업 복사본을 수동으로 혼합하여 일치시켜야합니다.

유사한 상황에서, 릴리스의 일부가 아니며 태그 할 필요가없는 Subversion에 파일이 있다면 어떻게 될까요? StarTeam에서는 빌드 준비 레이블을 부착하지 않지만 Subversion에서는 디렉토리의 모든 것처럼 보입니다. 빌드 및 태그에서 이러한 파일을 제외 할 수있는 방법이 있습니까? 이게 뭐야 svndumpfilter exclude은 무엇입니까?

요약하면 특정 파일의 특정 버전 만 태그에 포함하거나 저장소의 특정 버전이거나 저장소의 파일과 작업 복사본을 수동으로 혼합해야 할 수 있습니다 ?

답변

2

문제점을 올바르게 이해하면 릴리스 이전 시점에서 분기하여 처리 할 수 ​​있다고 생각합니다 (예 :이 릴리스에 포함 된 모든 주요 기능이 완료된 시점). 그런 다음 신중하게 관리하십시오 그 "릴리스"브랜치에 병합됩니다. "메인 트렁크"는 새로운 것들을 무료로 제공합니다. 예를 들어, 버그가 확인되면 (a) 메인 트렁크에 고정 된 다음 릴리스 브랜치에 병합할지 여부를 결정할 수 있습니다. 또는 (b) 지점에 고정. 이것은 우리가 따르는 과정이며 아주 잘 작동합니다 (그러나 규율과 정식 프로세스의 일정 금액이 필요합니다).

5

특정 개정판에서 분기하거나 태그를 붙입니다. 분기를 수정하여 해당 분기에 원하는 특정 변경 사항 또는 갱신 사항을 포함시킬 수 있습니다. 일단 브랜치 (branch)를하면, 원하는 브랜치 수만큼 파일을 변경하고 그 브랜치에 대해서만 업데이트 할 수 있습니다. 예, 개별적으로 파일을 이전 버전으로 업데이트 한 다음 분기에 커밋 할 수 있습니다.

1

Subversion은 원본 트리의 전체 버전을 원자 적으로 태그 할 수 있습니다. 찾으려는 기능은 소스 컨트롤과 변경 사항뿐만 아니라 각 티켓에 대해 변경된 파일도 유지하는 티켓 시스템과의 통신이 필요합니다.

Trac은 예를 들어 커밋 로그를 구문 분석합니다 커밋 로그의 # 구문을 사용하여 각 개정판을 임의의 수의 티켓과 연관시킬 수 있습니다.

새 릴리스와 관련된 티켓을 유지 관리하고 델타 릴리스 패키지에 포함 할 파일을 계산하는 모듈이 필요합니다.

1

가장 좋은 방법은 가지를 사용하는 것입니다. 새 릴리스에서 작업하는 방법에 따라 활성 개발에 사용되지 않는 클린 분기를 만들거나 트렁크를 깨끗하게 유지하고 활성 개발을 위해 분기를 사용할 수 있습니다. 그런 다음 완료된 파일과 다음 빌드를 준비 할 때 클린 분기에만 파일 변경 내용을 병합합니다.

예를 들어 트렁크에서 작업 중이며 버전 1.0을 릴리스한다고 가정 해 봅시다. 그런 다음 아무도 만지지 않는 maint-1.0이라는 브랜치를 만듭니다. 우리는 트렁크에서 계속 개발하고 특정 기능을 완료하면 변경된 파일을 maint-1.0 분기로 이동합니다. 두 개의 작업 복사본이 있어야하며 변경된 파일을 복사하기 만하면됩니다. 실제 병합을 수행하면 특정 파일뿐만 아니라 모든 변경 사항을 병합 할 수 있습니다.

결과적으로 maint-1.0 브랜치는 다음 빌드에서 원하는 변경 사항 만 있습니다.

1

나는 다른 대답이 많이 있다고 생각하지만 명시 적으로하기 위해이 상황은 릴리스 분기에서 매우 잘 처리됩니다.

개발 초기에 트렁크에서 분기를 가져 오는 것이 좋습니다 (초기 개정판에서부터 시작하여 모든 항목을 사용자가 분기하는 개정판으로 가져 오는 것이 보통입니다). 그리고 일반 병합 메커니즘을 사용하여 릴리스 트렁크. 나중에 개정판 (또는 수정 세트)이 나쁜 품질로 판명되면 해당 병합을 취소 할 수 있습니다. 병합 추적 (정말 잘하는 거북이)은 무엇이 포함되어 있고 무엇이 남아 있는지 알려주며, 리비전을 건너 뛰고 순서가 맞지 않는 부분을 병합 할 수 있으며 일반적으로 빌드 작업을 수행하는 데 필요한만큼 엉망으로 만들 수 있습니다. 분명히 - 순서를 건너 뛰고 병합하면 충돌을 수동으로 해결해야하기 때문에 더 많은 작업을 생성 할 수 있지만 필요에 따라 사용할 수있는 도구입니다.

필요에 따라 전체 기능 세트가 승격/제거되므로 개별 파일 작업보다 이점이 있습니다. 수동으로 다른 파일에서 변경 사항을 제거하지 않아도됩니다. 그러나 이것은 당신이 정상적인 커밋과 코멘트를 요구합니다. 개발자들이 "금요일 오후에 커밋하기 때문에 모든 것이 안전합니다"라고 약속하지 마십시오.