SVN : 버그가있는 버전에서 TAG를 유지하는 것이 유효합니까?

Question

우리 제품 중 하나의 릴리스 버전 (예 : 4.3.0GA)에 대한 TAG를 만들었습니다. 그런 다음 프로덕션 인스턴스에 배포했습니다. 다음 날에는 생산 인스턴스가 완전히 추락하여 절대 사용할 수 없게되었습니다. 우리는 신속하게 버그를 수정하는 새로운 버전을 릴리스합니다. 생산에 사용하십시오.

그런 다음 버그 수정으로 TAG (4.3.0GA)를 업데이트했습니다.

우리는 실수를 만든

제안을 : 그런 다음 우리가 우리 팀 내부의이 토론에 온

---

(예, 우리는 직접 태그 4.3.0GA 저지했다) . 태그는 절대로 업데이트해서는 안됩니다. 실제 버그 수정 4.3.0GA TAG을 초기 상태로 되돌려 야합니다. 그런 다음 버그 수정을 사용하여 4.3.0GASP1이라는 새 태그를 만듭니다. 릴리스 된 모든 버전 (프로덕션에서 하루 만 지속되는 경우에도)에는 저장소에 고유 한 태그가 있어야합니다.

실제 저장소의 태그를 수정하지 마십시오 제안 B. 4.3.0GASP1 버전이 있으면 4.3.0GA 버그 버전으로 누군가 체크 아웃 할 수 있습니다. 태그에는 버기가 아닌 버전 만 포함되어야하며 마지막으로 버기 버전은 하루 동안 프로덕션에 포함됩니다.

당신은 어떻게 생각하십니까? 올바른 자세 (제안 A 또는 B)?

업데이트 : 그런데 Jboss versioning convention을 사용합니다.

Answer 1

글쎄, 왜 안돼. 첫째, 태그는 다른 명명법이있는 단지 하나의 분기입니다. 기술적으로 차이가 없습니다. 차이점은 당신이 그들을 어떻게 대하는가입니다.

태그가 수정되지 않아야합니다.은 수정해야합니다. 이는 귀하와 귀하의 릴리스 절차가 답변 할 수있는 질문입니다. 아무도 당신이 틀렸다는 것을 말할 수 없습니다.

그래서 어떤 것이 가장 적합합니까? 그것은 '올바른'대답입니다.

태그를 전혀 사용하지 않고 트렁크에 출시 된 버전을 남겨두고 로그에 주석을 달았습니다. 출시 된 버전을 수정하지 않기 때문에 최신 코드의 새 버전을 릴리스해야하지만 (우리는 수 백개의 태그를 사용하지 않을 것입니다.) 고객은 이전 버전을 원하지 않습니다. 항상 최신 제품을 구할 수 있습니다.

버전 관리의 모범 사례를 '위반하는 방식'을 볼 수 있지만 멋지게 작동하므로 걱정하지 않아도됩니다. 우리는 우리에게 효과가있는 것을합니다.

편집 : 전체 추적 기능을 사용하려면 태그 위치가 하나 뿐인 태그 분기보다 훨씬 더 많은 기능이 필요합니다. 각 태그의 HEAD 개정판은 신속하게 수정 된 중단 된 릴리스의 경우에 여전히 충분해야합니다. 또한 '릴리스 품질'을 만드는 데 필요한 수정 사항의 추적을 제공 할 수도 있습니다.

dev에서 출시되어 테스트에 들어갔을 때 제품의 태그를 만들 수 있으며, 완전히 끝날 때까지 수정 사항을 적용 할 수 있습니다. 그래서 테스트를위한 브랜치를 가지지 않고 테스트가 완료되면 태그를 만들고 대신 태그 브랜치로 직접 가서 그걸 사용하여 테스트하고 발견 된 작은 버그를 수정하십시오. 테스트가 완료되면 태그 분기가 읽기 전용으로 만들어집니다. 모든 경우에 HEAD 개정판 만이 해당 태그 분기에 사용됩니다. 이 접근법은 때로는 완성 된 개발자가, 안정된 제품을 가지고 있기 때문에 여러 버전을 테스트로 릴리스하는 복잡성을 줄일 수 있습니다.

Answer 2

IMO, A 및 B에는 몇 가지 진실이 있습니다.

이미 알고 계시 겠지만 태그 지정 메커니즘을 통해 특정 마일스톤과 관련된 소스 코드를 식별 할 수 있습니다. 따라서 태그를 쓰는 것은 나쁜 생각입니다. 아마 이것을 방지하기위한 훅/정책은 좋은 생각입니다.

svn이 변경 사항을 기록하고 되돌릴 수 있기 때문에 태그가 혼동/문제로 이어진다면 삭제할 수 있습니다. 그러나 각 태그/릴리스 #에 대한 설명이 포함 된 Wiki 페이지 또는 중앙 스프레드 시트가 도움이 될 수 있습니다 (릴리스 노트). 팀이 지속적인 통합을 수행한다고 가정하면 실제로 올바른 태그를 식별하기 전에 몇 개의 빌드가 태그 될 수 있으므로 원하지 않는 태그를 삭제하면 오버 헤드가 발생할 수 있습니다.

Answer 3

모범 사례의 관점에서, 4.3.0GA 태그가 붙은 분기에 대한 버그 수정을 커밋해야합니다. 그런 다음 고정 지점에서 새 태그를 생성했습니다. 물론 그것은 베스트 프랙티스 측면에서도 태그 발생 이후 일요일부터 6 가지 방법으로 수정 된 트렁크에서 태그를 지정하는 대신 일종의 지점/릴리스 4.3 유지 보수 지점에서 태그를 붙였습니다. 또한 은 태그 지정 개념의 핵심이기 때문에 후속에 대한 버그가있는 태그를 유지해야합니다.

팀의 관점에서 Subversion은 이에 관한 법률이 없으므로 지사는 지점에 불과하므로 원하는대로 할 수 있습니다. 그 상황에서 당신은 리드 프로그래머, 릴리스 매니저 또는 전체 팀, 즉 그 결정을 내리는 사람이 누구인지 정의해야합니다. RCS/VCS/SCM 쓰레기를위한 olicy를 갖는 것은 아마도 사소한 프로젝트에 영리한 것일 것입니다.

---

각 릴리스마다 최소한 두 개의 분기를 만드는 것이 좋습니다.

하나의 지점은 릴리스 한 코드를 유지 관리하기위한 것이고, 다른 하나는 실제로 발표 한 내용의 "태그"에 쓰여지지 않습니다. 사용자가 다운로드 할 수있는 모든 릴리스는 태그를 가지며 릴리스 된 각 주요 버전은 유지 보수 지점을 갖습니다. 커밋이 트렁크에 있고 릴리즈 브랜치에 속해 있다면, SVN 서적과 Google이 당신에게해야 할 일을 알려줍니다. 나는 그것이 체리 선택하고 리베이스를 호출하지만 어디에서 온 당신이 추측 할 수 있습니다

Answer 4

것은 내가 의 측면에 떨어지는 경향) :

IMHO, 태그의 상태를 보여주는 타임 라인 마커해야한다 특정 버전 또는 릴리스의 코드베이스 그 버전이 버그 였더라도 그것은 선적 된 것이었고, 당신이 체크 아웃 할 필요가 있고, 의도적으로이 그 릴리스가 클라이언트, 서버 또는 what-have-you .

누군가가 해당 태그를 체크 아웃하여 버그가있는 코드베이스 버전을 얻을 수 있지만 버그 수정이 많은 태그도 아닙니다. 의 딜레마에 빠져서는 안됩니다. "이 릴리스는 어떻게 버그가 있습니까?"으로 VCS에서 수행하는 작업을 결정하십시오. Subversion 외부에 저장된 릴리스 로그는 잘못된 체크 아웃을 최소화하는 데 도움이됩니다.

나의 엄지 손가락 규칙 : 새 코드가 배송되면 새로운 태그가 사용됩니다.