svn tag만들 때 svn:externals 리비젼 고정하기

요즘 특정 바이너리를 배포할 때 마다 아래의 과정을 반복하고 있다.

svn tag 생성

1. svn copy trunk tags/version-identifier 로 태그를 생성한다

2. svn:extenrals 로 연결된 외부 의존성[1] 의 revision을 고정한다. 예를 들어 library_AAA svn://some_host/some_dir/trunk/ 인 svn:externals 를, library_AAA –r 1000 svn://some_host/some_dir/trunk/ 하는 식으로 revision 을 고정한다.

만약 이 revision 고정하는 부분을 건너 뛰면, 소스 서버를 따로 쓴다면 모르겠지만(…), 그렇지 않은 경우 나중에 버그 트래킹할 때 귀찮아진다. 태깅된 소스 트리 자체야 버젼이 맞지만, svn:externals 의 revision이 고정되지 않은 경우, 해당 저장소의 최신 버젼(…)을 가져오게 되기 때문에 바이너리와 소스 트리 사이의 버젼이 달라져서 제대로 디버깅하기 힘들다.[2]

변경 사항 리뷰

diff previous_tag current_tag 의 값으로 – 물론 적당한 필터링이 들어가지만 – 뭐가 바뀌었나 다시 한 번 확인하고, svn log 를 참조해서 변경 사항 로그(changelog)를 작성한다. 그리고 나서 커밋.

빌드

msbuild 스크립트로 전체 바이너리 빌드 + zip 으로 압축 + 적당한 버젼 정보를 넣은 압축 파일 생성한 후, changelog와 함께 전달하면 끝.

하다보니…

사실 별로 복잡할 것도 없는 작업이다. 변경 사항 리뷰하는 것 이외에는 다 자동화 해도 될 것 같이 보인다. 근데 정작 이게 좀 귀찮은 이유는 svn copy 가 멍청할 정도로 느리다는 것과, svn:externals 를 하나하나 수정해야한다는 점. 이에 대한 대안으로 svn:externals에 리비젼을 자동으로 고정 [3] 시키면서 태깅하는 툴들을 찾아보니 두 가지 툴이 있었다.

하나는 svncopy.pl 이라는 perl 스크립트였지만, 내 환경(Win64 + 한글)에서 비정상 종료하는걸 몇 번 보고나서 GG. 또 하나는 svnxf 라는 .net framework 기반 툴인데, .net framework의 마이너 버젼 문제인지 내 머신에서 제대로 실행이 안됨 Orz.  .net 3.5 깔려있는데 안되고, 이건 redistributable 도 인터넷 연결을 요구해서 폐쇄망에서 작업하는 내 경우엔 그냥 GG.

그래서 그냥 pysvn 을 써서 간단한 python 스크립트를 작성했다. svn copy 후에 svn:externals 를 찾아다니면서 고정되지 않은 경우 revision을 현재 체크아웃된 revision 값으로 바꾼다. 파일 자체는 여기서 받아볼 수 있다.

일단 *nix 환경에서는 잘 돔. 이걸 가지고 회사에서도 한 번 돌려봐야겠다. os.path 로만 패스를 다뤘으니 아마 문제 안생기겠지(…). 문자열 인코딩 문제도 (아마도) 어떻게든 해결할 수 있을테니…

  1. 같은 저장소 안의 특정 디렉토리, 혹은 다른 저장소(의 특정디렉토리)를 간접적으로 가져오도록 설정하는 기능이다. 다른 svn 저장소를 svn 저장소 밑에 링크(?)하기 참고. []
  2. 물론 로그를 뒤져서 svn:externals 의 버젼을 맞춰도 되지만 왜 그런 귀찮은 짓을… []
  3. freezing이라 부르더라? []

Published by

rein

나는 ...

4 thoughts on “svn tag만들 때 svn:externals 리비젼 고정하기”

  1. svn-books 를 뒤져보니 내가 처리하지 않은 svn:externals 의 문법이 더 있다.

    directory-name [-r revision] svn-url

    이런 형식만 처리했는데, 이거 말고

    [-r revision] svn-url directory-name

    형식으로도 쓸 수 있다 -ㅠ-

    저 모호성을 어떻게 처리하지? 그냥 테스트해보고 성공하는가로?

  2. 또 다른 svn:externals의 문제점으로는,

    A -> B -> C 와 같이 nested external 이 걸리면, A -> B에서는 revision번호를 줄 수 있지만..(Rev-E0)

    실제 업데이트할 때 B -> C 에는 A -> B에서 준 revision번호가 상속(?) 되지 않습니다.

    그래서 A ->(Rev-E0) -> B -> (Rev-Head) -> C 가 됩니다.

    덕분에 nested external의 경우에는 아예 external되는 녀석들을 branches로 옮겨놓고 씁니다. orz

  3. Pingback: rein's world

Leave a Reply