2009-10-04 4 views
14

대부분의 프로젝트는 많은 공통 코드를 사용합니다. 우리는 (마지막으로) 일관된 방식으로 공유 코드를 관리하는 시스템으로 이동하고 있습니다. SVN에서 공유 코드를 별도의 프로젝트로 처리 한 다음이를 외부 참조로 사용합니다. 그러나 라이브러리를 한 사용에서 다른 용도로 이식해야하는 필연적 인 문제로 인해 프로젝트가 개발중인 동안 외부 라이브러리를 개발 지사 또는 트렁크로 지정하는 경향이 있습니다.개발 지점에서 외부로 SVN 체크 아웃 태그 지정

결과적으로 릴리스 또는 내부 마일스톤을 위해 파일에 태그를 지정하는 과정에서 실수를 범했습니다. 가끔 우리는 모든 외부 항목이 먼저 태그가 지정되었는지 확인하지 않고 프로젝트에 태그를 지정합니다. 이 문제를 어떻게 해결할 수 있습니까? 나는 실수의 가능성을 줄이거 나 이와 같은 엉성한 태그를 만든 후 복구/복구하는 방법을 찾고 있습니다. 이상적으로 솔루션은 SVN이 현재 정책을 시행하도록 만드는 방법 일 것이지만, 나는 이와 같은 문제에 대한 모든 경험에 관심이있다.

답변

11

나는 그 문제

  1. 태깅을 자동으로 처리하는 두 가지 전략을 사용합니다. 프로젝트에 태그를 만들기 전에 모든 svn : externals를 수정 된 수정/릴리스 태그로 변경하는 셸 스크립트를 만듭니다.
  2. 에는 기존 태그의 일관성을 검사하는 스크립트가 있습니다. 실제로 외부 태그가 트렁크에 링크되어있는 경우에도 태깅시 상태를 재구성 할 수 있습니다. 태그가 작성된 날짜와 시간을 알기 때문에 해당 지점에서 어떤 트렁크 개정이 활성 상태인지 파악하고 수정할 수도 있습니다 트렁크의 특정 개정판을 가리키는 외부 또는 태그가 작성된 시점의 최신 릴리스를 가리 킵니다.

이 외에도 이러한 경우가 아니라면, 커밋 거부, 태그가 생성되고 있는지의 여부를 확인하는 사전 커밋 훅을 마련하고, 모든 외관 고정 개정 가리 여부있다.

+0

스크립트를 만들 시간이 있다면 옵션 2를 사용하는 것이 더 좋습니다. 이것은 내가 프로젝트에 태그를 지정할 때도 사용하는 옵션입니다. 옵션 1을 사용하면 '외부'저장소 (루트 프로젝트 수정본이 아닌)의 개정 번호를주의해야하며, 여러 저장소에서 외부를 가져 오는 경우 더욱 복잡해집니다. – MOK9

1

진부하게 들리 겠지만, 가장 좋은 방법은 라이브러리의 개발 개발 부분이 아니라는 것입니다. 타사 라이브러리 인 경우 그렇게하지 않으려 고합니다. 자신의 라이브러리로도 그렇게하는 것은 좋지 않습니다.

더 많은 작업이 될 수 있지만 참조 된 라이브러리에서 버그가 발견되면 수정하고 새 릴리스에 태그를 지정하고 프로젝트에서 새 태그를 참조하십시오.

실제로 라이브러리의 개발 분기를 참조해야하는 경우 태그를 수행 할 때를 결정하고 참조 된 모든 외부가 태그 버전임을 확인하는 사전 커밋 (pre-commit) 훅 스크립트를 사용할 수 있습니다. 그러면 스크립트가 그렇지 않은 경우 커밋합니다. 당신이 커밋을 할 때마다 취하는 것은 대단한 타격입니다.

+0

가장 좋은 방법은 라이브러리의 개발 부분을 참조하지 않는 것입니다. 그러나 이것은 동료 직원의 행동을 제어 할 수 없거나 실수가 없다는 것을 보장 할 수 없기 때문에 내가 할 수있는 실질적인 변화가 아닙니다. –

1

우리는 또한 태그에 복사 된 외관을 고정시키고 있지만 아직 서버에서이를 구현하지 않은 정책을 시행하고자합니다.

프리 커밋 후크는 svnlook 명령을 트랜잭션 번호와 함께 사용하여 복사본의 "태그 /"대상을 확인합니다. 히트 (hit)가 발생하면 속성을 검사하고 svn:externals을 검색해야합니다. 정책의 재정의를 허용하는 다른 속성이있을 수 있습니다.

명백한 질문은 서버의 부하와 해당 후크에 사용할 언어입니다. 일반적으로 SVN은 더 나은 Python Ctypes 바인딩이 있습니다. 불행히도 마지막으로 확인한 시간은 Windows에서 사용할 수 없었습니다 (이 대상과 같이 컴파일 할 수 없음). 그러나 pysvn 모듈은이를 수행하기에 충분할 수도 있습니다. 이 언어 외에도 bash 스크립트는 작동 할 수 있지만 지저분 할뿐만 아니라 이식성이 떨어집니다. 아니면 순수한 C ...

1

외부 라이브러리처럼 내부 라이브러리를 다루지 않습니까? Apache Ivy (Maven)의 경우 중앙 저장소 (버전 번호 1.0 또는 SNAPSHOT_20091005)에 라이브러리를 게시하고 표준 Ivy (Maven) 메커니즘을 사용하여 라이브러리를 가져 오기가 쉽습니다.

그런 식으로 SVN 외부의 모든 문제를 제거합니다. 물론 각 프로젝트는 릴리스를 만들기 전에 태그를 사용해야하지만 "릴리스 101"입니다.

+0

동의 - svn 외부는 그들이 가치있는 것보다 더 많은 문제처럼 보입니다. 내가 사용하는 곳을 보았을 때마다, 우리는 그 곳이 없으면 더 좋았을 것입니다. – Peter

1

나는 Martin v. Löwis와 동의하지만, 외부인이 자신의 svn : externals을 정의하는 경우에만 svn : externals에서 수정 번호 만 하드 코딩하면 문제가 있는지를 묻습니다.

개발 리포지토리를 잠그기 때문에 개발 트렁크 외부를 지정된 개정판으로 설정하고 싶지는 않습니다. 또한 재귀 적 외부를 무시할 수 없습니다. 가장 좋은 방법은 재귀 적으로 모든 외부에 태그를 지정하는 것입니다. 이렇게하면 개발을 계속할 수 있지만 모든 태그와 분기를 만들 수 있습니다.

나는이 작업을 수행하지만 난 그게

+6

어디서나이 스크립트를 게시 했습니까? –

3

서브 버전 클라이언트 버전 1.9는 여기에서 원하는 정확히 할 것 같습니다 svn copy에 대한 --pin-externals 옵션이 있습니다 :) 게시하기 전에 조금 그것을 청소하는 스크립트가 있습니다.

이 대답은 freenode IRC 채널 #svndanielsh (Daniel Shahaf)에게 감사드립니다.

관련 문제