상용 응용 프로그램의 새 버전 (버전 4)에서 작업을 시작하려고합니다. Subversion을 사용합니다.
귀하의 경험, 실수 및 성공을 바탕으로 Subversion에서 새 버전을 설정하는 방법을 권장하십니까?
여기에 몇 가지 정보가 있습니다 : 버전 4가 출시 된 후 얼마 동안 버전 3에서 중요 업데이트를 계속 출시하려고합니다. 그러나 새로운 기능의 모든 개발은 버전 4에만 있습니다.
관련이있는 경우 : 나는이 제품의 솔로 개발자이며, 여전히 그럴 수 있습니다.
편집 : SVN의 태그와 분기를 알고 있습니다. 필요한 것은 내 상황에서 태그와 분기를 사용하기위한 최적의 전략이라고 생각합니다.
답변:
당신이하고 싶은 것은 지점을 만드는 것 입니다. 소스 트리에서 분기 (보통 소스 를 릴리스 할 때 소스 의 사본 )처럼 들립니다 . 중요한 업데이트 를 위해이 분기에 커밋하고이 분기 에서 업데이트를 빌드합니다.
지금 커밋 trunk하고있는 것은 거기에 버전 4를 코딩하는 것입니다. 주요 변경 사항이 버전 3으로 커밋되고 버전 4 에서 변경하려는 경우 분기 (v3)에서 트렁크 (v4)로 병합 하여 변경 사항을 트렁크로 가져옵니다.
또한 브랜치와 유사하지만 단일 버전, 일반적으로 버전의 마지막 버전 (또는 첫 번째 버전)에 연결되는 tags를 볼 수 있습니다 .
때에 따라 다르지.
트렁크에 버전 4를 유지하고 V4에서 계속 개발할 수 있습니다. 버전 3은 필요에 따라 업데이트 할 지점입니다. 이 방법의 장점은 V3에서도 V3에서 중요한 문제가 발견 된 경우 브랜치에 걸쳐 파일을 간단히 병합 할 수 있다는 것입니다.
다른 옵션은 V4를위한 완전히 새로운 저장소를 작성하는 것입니다. 이것은 당신에게 새로운 시작을 줄 것입니다. 단점은 변경 기록이 재설정되어 Subversion을 통해 파일을 병합 할 수 없다는 것입니다. 변경 사항을 병합하려면 Beyond Compare와 같은 프로그램을 사용해야합니다.
개인적으로 첫 번째 접근 방식을 고수했습니다. V3 브랜치를 작성하고이 브랜치에서 코드와 업데이트를 유지하십시오. 트렁크에서 새로운 V4 코드를 개발할 수 있습니다.
이 상황에 대한 훌륭한 가이드를 찾았습니다 .
If you want to be able to both develop a newer version (in trunk) and
fix bugs on an older version, what you want is a branch for the older
version. You can fix your bug in the older version's branch, then
make a new tag of that.
Example:
/repo/
project/
trunk/
branches/
tags/
You've developed your software in trunk and are now ready to call it
version 1.0. You make a branch and a tag:
svn cp $REPO/project/trunk $REPO/project/branches/1.x
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.0
/repo/
project/
trunk/
branches/
1.x/
tags/
1.0/
Now you continue to develop in trunk, adding new features, and this
will eventually become version 2.0. But while you're doing this, you
find a bug in 1.0 and need to fix it quick. So you check out branches/
1.x, make the change, test it, and commit it. Then you tag that as 1.1:
svn cp $REPO/project/branches/1.x $REPO/project/tags/1.1
/repo/
project/
trunk/
branches/
1.x/
tags/
1.0/
1.1/
If the bug also exists in trunk, then you need to port your bugfix to
trunk. "svn merge" can help you there.
cd trunk-wc
svn merge -c$R $REPO/project/branches/1.x .
where $R is the revision in which you fixed the bug on the 1.x
branch. Now you test the fix in trunk and then commit it. Now the bug
is fixed in trunk too.
당신이 요구하는 것은 사용할 브랜치 (및 병합) 전략입니다. karthik t 의 포스트를 가지고 그것을 레시피로 가져 가십시오.
배경 지식이 필요하면 다음 자료를 읽으십시오.