tool

Subversion 서버 이관의 기억

gimslab.com 2012. 6. 19. 19:37

VisualSVN 서버를 사용하다가 유닉스 기반의 svnserve 로 이관해야할 일이 있었다.

간단히 정리해 두려고 한다.


기본적으로 VisualSVN이 사용하는 repository의 저장구조와 svnserve의 저장구조가 완전히 동일하기 때문에 별도의 툴 없이 단순히 윈도우 파일 시스템을 압축하여 유닉스에 풀어놓는 것으로 중요한 작업은 모두 종료되었다. 하지만 아쉬웠던 시행 착오가 많이 있었으니.. ㅡ.ㅡ


= 시스템 사양 및 환경 =

좀 더 상세하게 적어보면 기존의 VisualSVN Server는 Windows 2008에 설치가 되어 있었고 5개의 리파지터리를 가지고 운영되고 있었다. 버젼은 VisualSVN 2.1.2 이며 기본적으로 "https://" 를 사용한다.

옮겨갈 신규 SVN은 HP-UX 11.31 버젼을 쓰고 있었고 기본적으로 "svn://" 프로토콜을 지원하는 svnserve를 설치했다. 버젼은 1.7.3. 사실 이전까지는 SVN 서버가 대충 WAS위에서 돌아가거나 아니면 기껏해야 jre 환경정도에 종속 될 줄 알았는데 그게 아니었다. OS의 버젼에 맞는 서버가 필요했다. 작년까지만해도 해당 유닉스에 맞는 svnserve가 없어서 이관을 못하고 있었고, 올해 확인해보니 해당 버젼이 나와서 이관을 하게 되었다.


= 계정 및 권한 설정 파일 이관 =

저장소는 단순히 압축해서 유닉스에 풀기만 하면 되었지만 SVN계정 파일이 VisualSVN 은 별도로 관리하는듯하였다.

VisualSVN은 각 repository 아래 conf 폴더 내에 있는 설정파일을 사용하지는 않는듯 보였고 리파지터리들을 통합해서 하나의 파일에서 관리하고 있었다. 하지만 이 경우 각 리파지터리 내의 conf/svnserve.conf 파일에서 해당 파일의 위치를 지정해줘야할것 같은데 VisualSVN에서는 아무런 지정이 없이도 그렇게 동작하고 있었다.

신규 시스템에서도 마찬가지 여러개의 저장소에 있는 각각의 계정 및 권한 파일을 각각 쓰지 않고 일괄 파일 하나에서 쓰도록 지정하였다.

~/svn/repos/authz

~/svn/repos/passwd

파일에 전체 저장소에 대한 설정을 모두 해두었다.

그리고 각 저장소의 설정 파일에서 위 파일을 가리키도록 수정하였다.

예를 들어

~/svn/repos/repoA/conf/svnserve.conf

파일 내에서 해당 부분을 아래와 같이 지정했다.

password-db = ../../passwd

authz-db = ../../authz


이렇게 하여 여러개의 저장소에 대한 계정과 권한 설정을 한 곳에서 관리할 수 있도록 설정하였다.



= 작업 순서 =

1.신규 SVN 설치 및 테스트(관련 시스템 및 개발자 개발환경 등)

2.신규 SVN에 등록할 사용자 계정 등록

3.신규 서버 주소 및 클라이언트 변경에 대한 공지

4.기존 SVN서버 중지(사전 공지한 시각)

5.데이터 이관

6.이관한 Repository 운영

7.이관 내용 점검



= 사전 고려사항 =

사실 이번에 작업하면서 Hudson에 대한 테스트를 미리 하지 않았다. 당연히 svn:// 프로토콜이 잘 적용되리라 생각하고 간과했었다. 덕분에 이관하는 날 Hudson에서 신규 SVN을 인식하지 못하는 증상때문에 상당히 곤혹스러웠다. 결국 처리하긴했지만(허드슨과 svn 서버가 같은 장비라서 file:/// 프로토콜을 쓰도록 설정하여 해결함, 하지만 허드슨에서 왜 svn:// 프로토콜을 인식못하는지는 아직까지 풀지 못한 숙제)

1.개발자들의 환경

우리 회사에서 표준으로 구성하여 개발자들에게 제공하고 있는 이클립스는 필요한 플러그인을 모두 세팅하여 압축된 상태로 제공하고 있었다. 하지만 이번 일을 계기로 해당 이클립스에 subversive와 subclipse 플러그인이 모두 깔려있었고 "svn://"프로토콜을 사용하는 신규 SVN으로 변경한 이후에는 예상치 못했던 증상들이 발생한다는 사실을 알게됐다. 나는 개인적으로 그냥 최신 인디고를 쓰고 있어서 아무런 문제가 없었기에.. 나중에야 옆의 동료 PC를 보고 이런 문제가 있었다는걸 알게 됨. 결국엔 회사에서 공통으로 쓰는 eclipse 압축배포판의 svn 플러그인을 모두 제거하고 다시 최신의 subclipse를 설치하여 재배포까지 해야했다. (하지만 꼬여있는 SVN플러그인을 삭제하는게 첨에는 그리 쉽지 않았다.)

2.관련 시스템 테스트

허드슨이 "svn://"을 인식 못할줄이야.. 모든 이관작업이 끝나고 예상보다 빨리 퇴근할수 있을것 같다는 생각이 들었으나.. 허드슨을 테스트하는 순간 희망이 무너졌다. 아무리 설정을 바꿔도 신규 SVN에서 업데이트를 받지 못하였다. 결국 허드슨을 최신버젼으로 업그레이드하고 관련 허드슨 플러그인을 이것 저것 해봤지만 실패하였다. 아직도 그 원인을 못밝힌 상태이다. 허드슨이 "svn://"을 인식못하지는 않을것같은데..

어쨌든 퇴근은해야겠고 다시 원복해서 모든 개발자들에게 다시 원래대로 가라고 공지하는 사태는 벌이기 싫었기에 어떻게든 해결책을 찾다가 결국은 "file://" 프로토콜을 써서 해결은 하였다. 다행히 svnserve와 hudson이 같은 장비에서 돌고 있었기때문에 가능하였음.

하여간 SVN을 쓰고 있는 모든 시스템을 미리 점검해봤어야했다.


일단 더 생각이 안나서 마무리..^^