본문 바로가기

Papyrus/Troubleshooting

SVN + 아파치 서버 설정 방법

프로젝트의 버전을 관리하는 소프트웨어 중 가장 널리 알려진 것은 마이크로소프트의 소스세이프(Visual SourceSafe)다. 일반 데스크탑 시장에서는 윈도우가 가장 많은 플랫폼을 가지고 있고, 윈도우 플랫폼에서는 비주얼 스튜디오가 이론의 여지가 없는 최고의 개발툴이기 때문에 비주얼 스튜디오와 가장 잘 연동되는 소스세이프가 가장 잘 알려진 것은 당연한 일이다. 그런데, 소스세이프는 몇 가지 부분에서 불만족스럽다. 먼저, 소스세이프는 기본적으로 파일 잠금에 기반한 소스 관리 방식을 채택하고 있다. 소스세이프도 파일 잠금이 아닌 병합 충돌 처리를 지원하기는 하지만, 소스세이프를 사용하는 대부분의 개발팀은 그냥 잠금 방식을 선택한다. 사실, 충돌 처리에 능숙한 개발자가 아닌 이상 애초에 구현 영역을 나누고 작업하는게 훨씬 간단하기 때문이다(코딩 스타일 때문에 각 개발자의 코드를 병합하면 난리가 나는 경우가 많다). 코드 병합 및 프로젝트 가지치기(branching)에 이르면 소스세이프는 만족스럽지 않다.

더구나 소스세이프는 가끔 저장소의 소스 일관성이 지켜지지 않는 경우가 있다. 즉, 저장소로부터 소스를 가져올 때 클라이언트의 작업 코드와 충돌하는 일도 가끔 발생하고, 다른 버전 관리 소프트웨어와 비교해볼 때 느린 속도는 악명 높다. 무엇보다, 저장소 서버가 외부에 있고 http 프로토콜을 써서 접근해야 한다면 소스세이프는 속수무책이다. 이 문제를 해결해주는 플러그인이 존재하지만 대부분 유료다. 사실, 소스세이프는 마이크로소프트 내부에서도 소위 '개밥먹기'를 하지 않는 것으로 알려져 있으며, 비주얼 스튜디오 2010 이후로는 TFS(Team Foundation Server)에 버전 관리 기능이 통합되고 있기 때문에 소스세이프는 완벽하게 사장되고 있는 중이다.

따라서, 굳이 소스세이프를 써야 할 이유가 없다면 서브버전(SVN)을 강력하게 추천한다. 서브버전 역시 클라이언트 / 서버 모델을 사용하여 소스를 관리하는데, 서버를 구성하는 방식에 있어서 소스세이프보다 자유롭다. 또, CVS의 부족한 점을 보완하여 새롭게 만든 차세대 CVS라는 점에서 CVS 사용자들이 쉽게 적응할 수 있다. 소스 병합과 같은 부분에서 소스세이프에 비해 월등한 속도를 보여주며, http 프로토콜을 통해 저장소에 접근하고자 하는 경우 아파치와 매우 잘 연동된다(이제 서브버전은 아파치 프로젝트의 공식 일원이다). 다음은 가장 간단한 서브버전 서버 + 아파치 설치 방법이다.


1. 서브버전과 아파치의 버전을 확인한다. 서브버전 1.6.x와 아파치 2.2.x 버전 조합은 문제가 없다고 알려져 있다. 어떤 것을 먼저 설치해도 상관없다. 아파치를 먼저 설치한 뒤 서브버전 자동 설치를 하는게 제일 편하지만, 수동으로 직접 설치해보는 것을 추천한다.

2. 아파치를 먼저 설치했다면 httpd.conf를 수정한다. Dynamic Shared Object 부분에서, 다음 두 줄의 주석을 해제한다. 아파치를 설치할 때 포트는 8080번으로 하는게 안전하다.

#LoadModule dav_module module/mod_dav.so
#LoadModule dav_fs_module module/mod_dav_fs.so

다음 두 줄을 새로 추가한다.

LoadModule dav_svn_module module/mod_dav_svn.so
LoadModule authz_svn_module module/mod_authz_svn.so

설정 파일의 가장 끝으로 가서, 다음 항목을 추가한다.

<Location /UrlRepository>
    DAV svn
    SVNPath your svn repository path
</Location>

인증이 필요하다면 아파치의 기본 인증을 사용하는게 가장 간단하다. htpasswd를 사용하여 인증 파일을 생성하고, 서브버전 저장소의 authz 파일을 수정하여 그룹 및 사용자에 대해 프로젝트별 권한을 설정해줘야 한다. 서브버전의 authz 파일은 주석을 읽어보는 것만으로도 간단히 수정할 수 있을 것이다.

3. 서브버전의 bin 폴더에서 mod_dav_svn.so와 mod_authz_svn.so 파일을 아파치의 modules 폴더에 복사한다. 그리고, 서브버전의 bin 폴더를 반드시 Path 환경 변수에 추가한다. 이렇게 하지 않으면 서브버전의 dll들을 아파치의 bin 폴더에 모두 복사해야 한다. TortoiseSVN과 같은 클라이언트를 사용하지 않는다면 서브버전의 명령은 어디서나 사용해야 하기 때문에 환경변수에 추가하는게 필수적이다.

4. 서브버전의 관리자 명령을 사용하여, SVNPath에 기술된 경로에 '반드시 저장소를 생성'한다. http 프로토콜로 접근할 url에는 반드시 저장소가 생성되어 있어야 한다. 그렇지 않다면 웹서버는 대개 500 internal error를 출력할 것이다.

5. 필요하다면 아파치에 SSL과 같은 보안 항목을 더 추가한다.


2번 항목에서, <Location> 항목을 설정할 때 UrlRepository는 http://IP 주소/ 다음의 항목이다. 예를 들어, 외부에서 접근해야 하는 주소가 somewhere.net:8080일 경우, UrlRepository를 /Rep로 정의한다면 외부에서 접근해야 하는 완전한 주소는  http://somewhere.net:8080/Rep가 된다.

마지막 4번 항목은 저장소를 어떻게 관리하느냐 하는 정책과 관련있다. 하나의 저장소에 여러개의 프로젝트를 모두 넣을 수도 있고, 프로젝트 각각마다 개별 저장소를 할당할 수도 있다. 하나의 저장소에 디렉토리를 여러개 생성하는게 저장소의 중복성 제거에서는 가장 좋겠지만, 이렇게 되면 개별 프로젝트의 리비전 관리가 복잡해진다. 저장소를 관리하는 전략은 다음 문서가 좋은 길잡이 역할을 해줄 것이다 : http://svnbook.red-bean.com/en/1.5/svn.reposadmin.planning.html 위의 설정을 모두 마쳤다면 아파치를 재시작한다. 루프백 주소를 사용하여 아파치에 접근했을 때 다음과 같은 화면이 나타났다면, 아파치는 정상적으로 동작하고 있는 것이다. 만약, 아파치가 서버 이름이 완전하게 결정되지 않았다는 에러를 낸다면, httpd.conf의 ServerName 항목의 주석을 제거한다. SVN만 사용한다면 이때의 서버 이름은 큰 의미는 없다.




아파치 + 서브버전 서버 설치의 부담 때문에 서브버전을 기피해왔다면, 서브버전을 다시 한번 검토해보기 바란다. 생각보다 아파치의 서브버전에 대한 설정은 복잡하지 않고, 이로 인해 얻는 이익은 매우 크다. 세부 사항은 아래 링크 항목을 참조하기 바란다. 서브버전에서 제공하는 readme 파일도 아파치와 연동하기 위해 필요한 사항들을 기술하고 있으니 읽어보면 도움이 될 것이다.







Reference
http://svnbook.red-bean.com/
http://blog.jidolstar.com/552
http://codepedia.tistory.com/80