고급 서브 버전 기술, 무엇을 놓치고 있습니까?

나는 약 9 개월 전에 SVN을 사용하기 시작했으며 가장 적게 말하면 게임 체인저였습니다. 그래도 여전히 조금 잃어버린 것 같습니다. 실제로 응용 프로그램 개발을 강화하기 위해 활용해야 할 것이 훨씬 더 많다고 생각합니다.

예를 들어

변동성 / 주요 변경 사항을 일종의 '하위 리포지토리'또는 다른 것으로 격리 할 수 ​​있기를 원합니다. 주요 변경 사항이 매우 시급한 사소한 버그 수정을 방해하고 있음을 발견했습니다. 불완전하거나 손상된 코드를 푸시하지 않고 간단한 업데이트 하나를 푸시하려면 어떻게해야합니까?

귀하의 예를 설명하기 위해 다음 세 가지 가능성이 있습니다.

1. 단일 파일을 커밋 할 수 있습니다. 저장소에 액세스하기 위해 IDE를 사용하는 경우 커밋하기 전에 단일 파일을 선택하거나 선택 해제 할 수 있습니다. 명령 행에서 svn commit file1 path1/file2 path2file1, path1 / file2 및 path2 아래의 모든 변경 사항을 확약하도록 입력하십시오 .
2. 다른 작업 사본을 만들 수 있습니다. 표준 작업 복사본에서 큰 기능을 작업하고 긴급 버그에 대한 정보를 얻습니다. 저장소를 다른 디렉토리로 체크 아웃하고이 두 번째 작업 사본에서 버그를 수정할 수 있습니다. 버그가 발생한 구성 요소를 가진 서브 디렉토리 만 체크 아웃 할 수도 있습니다. 버그 수정 후 큰 기능에 대한 작업을 수행하지 않고도 두 번째 작업 복사본을 커밋 할 수 있습니다. 편집 : 그 방법은 Anna Lear의 답변에도 설명되어 있습니다.
3. 지형지 물 작업을위한 분기를 만듭니다. 이를 위해 copy 명령을 사용하십시오. 저장소에 표준 레이아웃을 사용하는 경우 (프로젝트 이름이 포함 된 디렉토리 및 이름 트렁크가있는 디렉토리, 태그 및 분기, 프로젝트가 포함 된 트렁크) 다음과 같이 svn-copy-command를 사용하여 분기를 작성할 수 있습니다 svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X. 이제 작업 사본을 새 위치로 전환 할 수 있습니다 : svn switch svn switch svn://hostname/projectname/branches/branch-for-feature-X. 버그 수정 모드로 전환하면 실제 변경 사항을 커밋하고 작업 복사본을 트렁크로 다시 전환하고 버그 및 커밋을 수정 한 다음 작업 복사본을 기능 지점으로 다시 전환하십시오. 기능을 개발할 준비가되면 기능을 트렁크에 다시 병합 할 수 있습니다.

설명 된 간단한 경우에는 보통 # 1 (가장 자주 사용), 때로는 # 2를 사용합니다. 브랜치 (케이스 # 3)로 작업하는 것은 더 복잡 하지만 ( 더 읽기 ) 더 많은 트릭을 허용합니다. 그러나 하위 리포지토리에 대한 설명과 일치하는 분기입니다.

당신의 모범 외에는 말할 수 없습니다. Subversion에는 많은 것들이 있지만 이미 사용하고있는 프로젝트와 프로젝트에 무엇이 필요한지 잘 모르겠습니다. SVN에 대한 자세한 내용은 SVN-Book을 참조하십시오 . http://svnbook.red-bean.com/

하나의 사본을 가져 와서 변경하지 않고 다른 샌드 박스로 코드를 체크 아웃 할 수 있습니다.

따라서 다음과 같은 폴더 구조를 가질 수 있습니다.

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

기타

SVN의 동일한 위치에서 모든 것을 확인할 수 있습니다. 예 : http://mysvnrepo/trunk .

이 방법으로 기능 개발에 영향을주지 않고 버그 수정 샌드 박스에서 커밋 할 수 있지만 svn update버그 수정에 대한 변경 사항을 적용하려면 다른 샌드 박스에서 실행해야합니다 .

Subversion Branches 를 전혀 보지 않았 습니까?

일반적인 기술 중 하나는 필요에 따라 중요한 수정 사항을 적용하여 트렁크를 안정적으로 유지하는 것입니다. 그런 다음 각각의 중요한 새 작업에 대한 분기 를 작성하십시오 . 해당 프로젝트를 수행하는 개발자는 지점을 확인하고 지점에 커밋합니다. 최종 통합의 일부로 분기를 기본 트렁크로 다시 병합 할 때까지 트렁크에 영향을 미치지 않습니다.

또 다른 방법은 트렁크에서 실수로 문제를 일으키는 다른 작업을 피하기 위해 특정 릴리스에 대한 브랜치를 갖는 것입니다. 필요에 따라 '릴리스 지점'을 버그 수정 한 다음 준비가되면 수정 사항을 트렁크로 다시 접을 수 있습니다.

개발자는 트렁크 및 분기와 같이 여러 개의 작업 사본을 체크 아웃하거나 svn switch명령을 사용 하여 트렁크와 특정 분기간에 교환 할 수 있습니다 .

(a) 다른 사람과의 공동 작업을 금지하고 (b) 아직 작동하지 않는 변경 사항을 주 트렁크에 실수로 너무 쉽게 커밋하기 때문에 별도로 체크 아웃하는 '샌드 박스'작업 복사본이 많지 않은 것이 좋습니다.

현재 작업중인 사본의 크기는 10GB이며 50.000 개가 넘는 파일이 있습니다. 다른 브랜치에 대해 여러 사본을 가질 수 있지만 새 사본을 작성하는 데 시간이 걸립니다!

긴급한 버그가 발생하면 일반적으로 모든 변경 사항을 패치에 저장하고 모든 것을 되돌리고 버그를 해결하고 커밋 한 다음 내가 저장 한 패치를 적용합니다. 새로운 작업 복사본을 얻는 것보다 훨씬 쉽고 빠릅니다. 이 작업을 자주 수행해야하는 경우 두 가지 작업 사본이 있습니다. 하나는 장기 변경, 다른 하나는 버그 수정입니다.