한빛출판네트워크

저자: Ben Collins-Sussman, Brian W. Fitzpatrick, C. Michael Pilato, 역 한동훈(traxacun at unitel.co.kr)

원문: http://opensource.oreilly.com/news/subversion_ch01.html

[편집자 노트: 이 기사는 오라일리에서 출간예정인 Version Control with Subversion 1장의 일부분입니다]

버전 컨트롤은 정보의 변경 사항을 관리하는 예술이다. 소프트웨어에 작은 변경을 가하고, 다음날 다시 그 변경사항을 원래대로 복원하는 일에 하루를 보내는 프로그래머들에게 없어서는 안될 도구였다. 그러나 버전 관리 소프트웨어가 소프트웨어 개발에만 쓰이는 것은 아니다. 어디서든지 자주 변경하는 정보를 관리하기 위해 컴퓨터를 사용하는 사람들을 볼 수 있으며, 이런 사람들을 위한 버전 컨트롤이 필요하다. 그리고, 바로 그런 사람들을 위해서 Subversion이 있는 것이다.(또는 등장한 것이다)

1장에서는 Subversion의 주요 기능들을 소개할 것이다. 즉, Subversion이 무엇인지, 무엇을 하는지, 어떻게 Subversion을 얻을 수 있는지에 대해 설명할 것이다.

Subversion이란?

Subversion은 공개 오픈소스 버전 컨트롤 시스템이며, 시간에 따라 파일과 디렉터리를 관리한다. 파일 트리는 한 곳에 집중된 리파지터리(repository, 역주; 흔히 레포지토리로 말하는 것으로 "정보의 저장 장소"라는 의미로 사용된다)에 보관된다. 리파지터리는 보통의 파일 서버와 다를 것이 없지만 파일과 디렉터리에 적용된 모든 변경사항을 기록한다는 점만 다르다. 이를 이용하여 오래된 버전의 데이터를 복구하거나 데이터 변경사항에 대한 과거기록을 열람하는 것도 가능하기 때문에 대부분의 사람들은 버전 컨트롤 시스템을 시간에 따라 기록하는 타임 머신의 일종으로 생각한다.

Subversion은 네트워크에서 리파지터리에 접근할 수 있기 때문에 다른 컴퓨터에서 사용중인 사람들도 리파지터리를 이용할 수 있다. 즉, 여러 사람이 각자의 장소에서 동일한 데이터를 수정하고 관리하는 것이 가능하며 협업이 가능하다. 모든 변경사항이 한 곳에 적용되므로 다른 사람의 진척에 관계없이 작업할 수 있으므로 작업진행도 보다 빨라진다. 모든 작업은 버전으로 관리하기 때문에 다른 사람의 작업을 손상시킬 염려도 없다. ? 만약 변경이 잘못되었다면 단지 변경사항을 원상태로 돌려놓기만 된다.

몇몇 버전 컨트롤 시스템은 소프트웨어 설정 관리(SCM, Software Configuration Management) 시스템으로 사용된다. 이런 시스템은 소스 코드 트리 관리에 특화되어 있으며, 프로그래밍 언어의 구문을 인식기능, 소프트웨어 빌드를 위한 도구 지원과 같은 소프트웨어 개발에 중점을 둔 다양한 기능들을 갖고 있다. 그러나 Subversion은 소프트웨어 개발에 특화된 시스템이 아니다. 이것은 모든 종류의 파일을 관리하기 위한 범용적인 시스템이다. 예를 들어, 개발자는 소스 코드를 관리하기 위해 사용할 수 있으며, 다른 사람들은 쇼핑 목록에서 디지털 비디오에 이르기까지 다양한 것들을 관리하기 위해 사용할 수 있다.(역주: CVS와 같은 기존 버전 관리 시스템은 미디어 파일에 대한 관리기능이 없으며, 바이너리 파일 형태로만 관리할 수 있다)

Subversion의 역사

2000년 초에 CollabNet, Inc.(http://www.collab.net/)에서 CVS를 대체할 소프트웨어를 작성할 개발자를 찾기 시작했다. CollabNet은 SourceCast라는 협업을 위한 소프트웨어를 개발하는 곳이며, SourceCast의 컴포넌트 중에 하나가 버전 컨트롤이었다. SourceCast는 초기에 버전 컨트롤 시스템으로 CVS를 사용했지만 CVS의 한계는 제품 초기부터 명확했으며 결국 CollabNet은 보다 나은 것을 찾아야 했다. 불행히도 오픈소스 세계에서 공개 라이선스(Free License)중에 보다 나은 것이 없다는 이유로 CVS는 거의 표준이 되었다. 그래서 CollabNet은 CVS의 기본 아이디어는 이어가면서 CVS의 버그와 잘못된기능들을 제거한 새로운 버전 컨트롤 시스템을 처음부터 작성하기로 결정하였다.

2000년 2월에 CollabNet은 Open Source Development with CVS(Coriolis, 1999)의 저자인 Karl Fogel과 접촉하여 새로운 프로젝트에 대한 일을 제안했다. 우연하게도 그 시기에 Karl은 그의 친구 Jim Blandy와 함께 새로운 버전 컨트롤 시스템에 대한 디자인을 논의하고 있었다. 1995년에 이들 두 사람은 CVS에 대한 기술 지원을 제공하는 Cyclic Software를 설립했으며, 회사를 팔아버린후에도 여전히 직업적으로 CVS를 사용하고 있었다. CVS에 대한 실망으로 Jim은 버전을 부여한 데이터를 관리하기 위한 보다 나은 방법에 대해 생각하였으며 Subversion이라는 이름 뿐만 아니라 Subversion 리파지터리의 기본적인 설계까지도 하게 된다. CollabNet이 접촉했을 때 Karl은 바로 프로젝트에서 일할 것을 동의하게 되며, Jim이 일하고 있는 레드햇(RedHat) 소프트웨어는 이 프로젝트를 위해 무기한으로 기부하게 된다. CollabNet은 Karl과 Ben Collins-Sussman을 고용했으며, 세부 설계는 5월에 시작했다. CollabNet의 Brian Behlendorf(브라이언 베렌도르프)와 Jason Robbins, Greg Stein(당시 WebDac/DeltaV 스펙 프로세스 과정에 독립 개발자로 일하고 있었다)의 도움으로 Subversion은 빠르게 개발자 커뮤니티를 끌어들였으며, CVS에 대해 비슷한 실망을 느꼈던 많은 사람들로부터 환영받았다.

초기 디자인 팀은 단순한 목표만을 정했다. 버전 컨트롤 방법에 있어서 새로운 것을 도입하는 것을 원하지 않았으며, CVS에 대한 수정만을 원했기 때문에 Subversion도 CVS의 기능을 따르며, CVS의 개발 모델을 보존하지만 결점까지 옮겨오지는 않았다. 그렇다고 이것이 CVS의 축소판을 의미하는 것은 아니다. 그보다 CVS 사용자가 보다 적은 노력으로 Subversion으로 바꿀 수 있게 하기 위한 것이다.

14개월의 코딩끝에 Subversion은 2001. 8. 31에 소개되었다. 결국, Subversion 개발자들은 Subversion 소스 코드 관리를 위해 사용하던 CVS의 사용을 중지하고 Subversion을 사용하기 시작했다.

CollabNet이 프로젝트를 진행하는 동안 대부분의 작업에 대한 자금을 제공했다.(또한, Subversion 풀타임 개발자들의 월급도 포함). Subversion은 대부분의 오픈소스 프로젝트와 마찬가지로 운영된다: 느슨한 통제, 실력있는 사람의 참여를 장려하기 위한 투명한 규칙들.

CollabNet의 저작권은 Debian Free Software Guidelines을 전적으로 따른다. 즉, 누구나 다운로드하여 수정, 재배포할 수 있으며, 이 과정에 CollabNet으로부터의 허가나 다른 누구의 허가도 필요없다.

Subversion의 특징

Subversion의 기능을 논할 때 표를 사용하는 것은 CVS의 디자인을 어떻게 향상시켰는가 하는 관점에서 유용하다. 그러나 CVS에 익숙하지 않다면 이런 기능들을 모두 이해할 수 없을 것이다. 마찬가지로 버전 컨트롤에 대해 생소하다면 1장과 2장까지는 눈으로 훑어보는 것으로 만족해야할 것이다. 1장과 2장에서는 버전 컨트롤 시스템의 일반적인 특징에 대한 소개만 나와있다.

Subversion의 기능들:

디렉터리 버전관리(Directory versioning)

CVS는 각각의 파일에 대해서만 히스토리를 관리하지만 Subversion은 가상 버전관리 파일 시스템(Virtual Versioned filesystem)을 구현하여 시간에 따른 모든 디렉터리 트리의 변경사항을 추적한다. 파일과 디렉터리 모두 버전으로 관리된다.

진정한 버전 히스토리(True version history)

CVS는 파일에 대한 버전 관리만 할 수 있기 때문에 파일의 복사, 이름변경이나 디렉터리에 있는 내용의 변경등은 제공되지 않는다. 뿐만아니라 CVS에서는 버전부여된 파일을 이름이 같은 다른 파일로 대체할 수 없으며, 대체하게 되면 기존의 버전 히스토리를 이어받게 된다. Subversion에서는 파일과 디렉터리 모두 추가, 삭제, 복사, 이름변경을 할 수 있으며, 새로 추가된 모든 파일은 고유의 히스토리를 갖는다.

최소단위 적용(Atomic commits, 역주: commit(커밋)은 변경사항 적용으로 옮길 수 있다)

모든 변경사항을 리파지터리에 전부 저장할 수도 있으며, 그렇지 않을 수도 있다. 이와 같은 방식을 사용하면 개발자가 논리단위로 변경사항을 구성하고 적용할 수 있으며, 일부만 변경하여 리파지터리에 저장했을 때 발생할 수 있는 문제들을 예방할 수 있다.

메타데이터 버전관리(Versioned metadata)

모든 파일과 디렉터리는 속성 키와 값을 가지므로 원하는 키/값을 생성하여 저장할 수 있다. 속성도 파일의 내용과 마찬가지로 시간에 따라 버전관리가 된다.

네트워크 레이어 선택

Subversion은 리파지터리 액세스를 위해 별도의 추상화된 표기법을 이용하여 새로운 네트워크 메커니즘 구현을 쉽게 해준다. Subversion은 아파치 HTTP 서버에 확장 모듈로 추가할 수 있으며, 이로인해 안정성과 상호운용성에 있어서 큰 이점을 갖는다. 기존 웹 서버의 인증, 압축기능 등을 그대로 사용할 수 있다. 게다가 가볍고, 독립실행이 가능한 Subversion 서버 프로세스를 이용할 수도 있다. 독립실행 서버는 SSH를 이용해서 쉽게 이용할 수 있는 고유의 프로토콜을 사용한다.

일관된 데이터 처리

Subversion은 사람이 읽을 수 있는 텍스트 파일과 사람이 읽을 수 없는 바이너리 파일에 모두 사용할 수 있는 바이너리 식별 알고리즘(Binary Differencing Algorithm)을 사용하여 파일의 변경사항을 찾아낸다. 두 가지 유형의 파일 모두 압축하여 리파지터리에 저장되며, 변경사항은 네트워크상에서 양방향으로 전송된다.

효율적인 트리 분할과 태그 명명(Efficient branching and tagging)

트리 분할과 태깅에 따른 비용은 프로젝트 크기에 비례하는 것은 아니다. Subversion은 하드 링크(hard-link)와 비슷한 방법을 사용하여 프로젝트를 복사하는 것으로 트리 분할과 태그를 생성한다. 따라서, 트리 분할과 태그 작업은 매우 작은 공간과 시간만 사용한다.
(역주: 소스 코드 트리는 1.0에서 1.1, 1.2, 1.3과 같이 하위 버전으로 나뉘어 작업을 하게 되며, 각 하위 버전에 따른 트리 구조도 다르게 된다. 이처럼 새로운 하위 버전으로 나뉘어가는 과정을 트리 구조로 그리면 "가지가 뻗어가는 모습"을 닮았으며 이를 branch라고 한다. 굳이 번역하면 "가지치기"라고 할 수 있으나 보통 이것을 "소스 코드 트리 분할"이라고 하며, 간단히 브랜치라고도 한다. 그러나 "브챈치"보다 "소스 코드 트리 분할"이 머리속에 더 감각적으로 들어올 것이다.
태그 명명(tagging)은 각 파일마다 다른 버전을 가질텐데 버전 1.0 출시에 사용된 소스 코드와 버전 2.0 출시에 사용된 버전에 사용된 각 파일에 대해서 RELEASE_1_0과 RELEASE_2_0이라는 태그를 부여한다면 언제든지 이들 태그를 사용하여 1.0 출시에 사용된 소스 코드를 받아올 수 있으며, 2.0 출시에 사용된 소스 코드를 받아올 수 있다. 만약 태그 작업이 없다면 항상 리파지터리에서 최신 버전의 소스만 받아오거나 과거의 파일을 버전별로 일일이 가져와야 한다.)

Hackability

Subversion은 시대에 뒤쳐진 관습을 따르지 않는다. 즉, 잘 정의된 API로 구성된 공유 C 라이브러리로 구현했으므로 유지보수하기 쉬우며 다른 응용 프로그램이나 언어에서도 사용할 수 있다.

Subversion의 구조

그림 1-1은 Subversion의 디자인을 설명하고 있다.


그림에서 맨 끝에는 버전별 데이터를 저장하는 Subversion 리파지터리가 있으며, 다른 반대편 끝에는 Subversion 클라이언트 프로그램이 있다. 클라이언트 프로그램은 버전별 데이터의 로컬 복제본(이를, Working Copies(작업 사본)을 이라한다)을 관리한다. 이 두 사이에는 다양한 RA(Repository Access) 계층을 통해 다양한 경로가 존재한다. 몇몇 경로는 컴퓨터 네트워크를 거쳐서 리파지터리에 액세스하며, 다른 경로는 네트워크 서버에 액세스한다. 다른 것들은 네트워크를 모두 무시하고, 직접 리파지터리에 액세스한다.

Subversion 설치

Subversion은 APR(Apache Portable Runtime library)이라 부르는 Portability 레이어에 구축된다. 즉, 아파치 httpd 서버가 실행되는 운영체제라면 어디서든 Subversion이 동작한다는 것을 의미한다. 다시말해, 윈도우, 리눅스, BSD 계열의 운영 체제들, Mac OS X, Netware등에서 동작한다.

Subversion을 사용하는 가장 쉬운 방법은 운영체제에 맞게 빌드된 바이너리 패키지를 다운받는 것이다. Subversion 사이트에서 패키지를 다운받을 수 있다. 이 사이트는 마이크로소프트 운영 체제를 위한 설치 패치지도 제공한다. Unix 계열 운영체제에서 실행하려면, 각 운영체제의 패키지 배포 시스템(RPM, DEB, Ports Tree 등)에 해당하는 패키지를 받으면 된다.

다른 방법은 소스 코드를 다운 받아 직접 Subversion을 빌드하는 것이다. Subversion 사이트에서 최신 소스 코드를 다운받는다. 압축을 풀고 INSTALL 파일에 있는 지시사항에 따라 빌드하면 된다. 제공되는 소스 패키지는 원격 리파지터리와 통신할 수 있는 명령줄 클라이언트를 포함한 모든 것을 포함하고 있다.(특히 arp, arp-util, neon 라이브러리). 그러나 Subversion의 부가기능들은 다양한 의존성을 갖고 있다. 예를 들어, 버클리 DB와 아파치 httpd가 대표적이다. 빌드를 완료하려면 INSTALL 파일에 명시된 모든 패키지가 시스템에 설치되어 있는지 확인해야 한다. Subversion을 직접 작업하고 싶다면 클라이언트 프로그램을 사용하여 가장 최신의 소스 코드를 받을 수 있다. 이에 대해서는 "Get the Source Code" 문서를 참고하기 바란다.

Subversion의 컴포넌트

Subversion은 수많은 컴포넌트로 구성되어있다. 다음은 이들 컴포넌트의 간단한 개요다. 여기에는 간단한 설명만 있다고 걱정할 것은 없다. 책에서 수십페이지에 걸쳐서 자세히 설명하고 있다.

svn

명령줄 클라이언트 프로그램

svnversion

작업 사본의 상태를 보기 위한 프로그램

svnlook

Subversion 리파지터리를 조회하기 위한 도구

svnadmin

Subversion 리파지터리를 생성, 최적화 또는 수정하기 위한 도구

svndumpfilter

Subversion 리파지터리 덤프파일 포맷 스트림을 필터링하기 위한 프로그램

mod_dav_svn

아파치 HTTP 서버를 위한 플러그인 모듈. 네트워크에서 리파지터리를 다른 사람들도 사용할 수 있게 해준다.

svnserve

독립실행 서버 프로그램으로 데몬 프로세스로 실행하거나 SSH에 의해 호출되는 형태로 이용가능하다. 리파지터리를 네트워크상의 다른 사람들이 이용할 수 있게 해준다.

Subversion이 올바르게 설치되었다면 시작할 준비를 해야한다. 다음에 2개 장에 걸쳐서 Subversion의 명령줄 클라이언트 프로그램 svn의 사용법을 살펴볼 것이다.