버전 관리 시스템 - Concurrent Versions System (CVS)-1

버전관리시스템-Concurrent Versions System (CVS)-1

목차

 서론

 CVS로 할수있는 다양한것들

 버전관리 시스템 이란 무엇인가?

 CVS시작하기 - CVS서버설치(서버관리자)

 GNU CVS 의 설치과정

 CVSNT 의 설치과정

 익명 CVS 설정하기

 이메일 통보설정

 윈도우용 CVS서버의 설치

 CVS 클라이언트 설치 ( 사용자 )

 참고  &　도서

일상에서 쉽게 일어나는 일을 한가지 가정해보자.

case1)

사랑하는 여자친구에게 주기위해서 김군은 시를 한편 작성하기로 마음을 먹고 메모장을 열어서 시를 작성했다. 마음에 안드는 구절을 지우고 쓰고, 지우고 쓰면서 일주일내내 시를 쓴다.

그렇게 고심하면서 한편의 시를 완성하고 드디어 상대방에게 보내기로 결정했다.

마지막으로 작성한 내용을 한번 다시 읽어보는 도중에....

맨 처음 적은 내용이 더욱 좋을 것 같다는 생각이 난다.

하지만 그 내용은 아무리 고민해봐도 기억할수가 없다.

내가 이전에 적은 내용은 다시 찾을수가 없는가...

이번에는 실무에서 일어날수있는 실제사례를 생각해보자.

case2)

이번에 회사에서 홈페이지를 개편하기로했다.

홈페이지 개편 담당으로 프로그램은 김모군 디자인은 이모양이 담당하기로 했다.

두사람이 모여서 새로운 시스템에 대해서 설계하고, 각자 맡은바 작업을 진행해 나간다.

홈페이지 개편일 하루전.

프로그래머 김모군은 홈페이지를 점검하다가 치명적인 에러를 발견하고 이를 수정한다.

그날밤 디자이너 이모양은 디자인 수정할 부분을 수정한후에 화일을 ftp로 전송한다.

다음날 홈페이지 오픈일. 프로그래머 김모군이 열심히 수정한 사항은 온데간데 없고

디자이너 이모양이 새로올린 내용뿐이다.

이제 어떻게 해야하나.. 김모군은 고민하다가 결국 방법이 없어서 다시 작업하기로 하고,

홈페이지 오픈일을 연기한다.

case3)

서울에사는 프로그래머 김군은 부산에 사는 친구 최군과 함께 프로그램을 하나 개발하기로 합의했다.

적절한 프로젝트 관리방법을 생각하던 김군과 최군은

이 프로젝트의 소스를 보관하는 장소가 필요하다고 느끼고

둘다 접근할수있는 서버한곳에 소스화일을 공유하기로 했다.

각자 자신의 환경에서 개발한후에 소스를 업데이트 할때에는

수정일_이름 형식으로 디렉토리를 만든후에 그안에 새롭게 수정된 소스를 업로드하고

수정한 내용들을 별도로 기록해 두기로 했다.

프로젝트는 큰문제없이 진행되고 있었지만,

이 둘은 매번 새로운 디렉토리를 만들어서 작업하고

상대방의 최근소스의 변경사항을 검사하고 자신의 소스와 다른부분들을 검사하는 일에 불편함을 느꼈다. 두명의 동시작업도 이렇게 조심해야 할것이 많은데 50명이 작업한다면 어떻게 될까..

더 나은 방법은 없는것인가...

공동프로젝트 관리

회사혹은 학교에서 프로젝트를 진행하다보면, 여러명이서 하나의 프로젝트를 진행하는 경우가 발생할것이다.

이럴경우 보통 모듈별로 개발을 하게 되겠지만, 또한 모듈은 전체 프로젝트에 영향을 미치게 되므로, 자신의 모듈버젼과 전체 프로젝트의 버젼을 컨트롤할수 있어야 한다. 그리고 코드가 충동하게 될경우(서로 같은 부분을 수정함으로써)의 문제를 해결할수 있어야 한다.

이러한 작업은 프로젝트 규모가 작고 개발 참여자 수가 적고, 개발 참여자가 가까운 지역(사무실 같은)에 모두 모여있다면, 한명의 버젼관리자(보통은 팀장)를 두고 그럭저럭 관리가 가능할것이다.

그러나 조금만 프로젝트가 커지고, 개발참여자 수가 많아지고 개발자가 지역적으로 떨어져 있는 상황에서는 거의 불가능 하다는 걸 알수 있게 될것이다. 특히 인터넷을 통해서 느슨하게 연결된 오픈 프로젝트의 경우 도구를 사용하지 않는 다면 거의 관리가 불가능 할 것이다.

CVS 를 사용하면 이러한 대규모의 프로젝트에서 각 모듈 개발자가 자신의 버젼을 유지하면서 전체 프로젝트에 참여할수 있도록 할수 있다.

실제로 KDE, GNOME, APACHE 서버 등 다양한 프로젝트가 CVS 를 이용해서 프로젝트를 관리하고 있다. 이러한 프로젝트는 규모가 작아도 수십명, 혹은 수백명이 프로젝트를 진행하게 되는데(게다가 지역적으로 멀리 떨어져 있다), CVS가 중간에서 프로젝트가 산으로 가지 않도록 중계해준다. 오픈 프로젝트를 하는데 있어서 CVS는 거의 표준적으로 사용되는 버젼관리 도구이다.

프로젝트백업

CVS 를 사용할경우 자동적으로 프로젝트 백업의 문제까지 해결이 가능하다. CVS 는 중간에 CVS 서버가 있어서, 프로젝트 데이터의 저장소 역할을하며 모든 개발자는 CVS 서버에서 최신의 프로젝트를 다운로드 받아서, 자신의 컴퓨터에서 테스트하고 코딩해서, 이걸 다시 CVS 서버에 업데이트 시키는 방식을 사용하게 된다. 그러므로 실수로 자신의 프로젝트 데이터가 날아간다고 해도 전혀 염려할 필요가 없다. 그냥 서버에서 다시 다운 받기만 하면 된다. 최악의 경우 CVS 서버가 날라갔다고 하더라도 가장 최근의 소스를 가진 개발자가 있을 것이므로 쉽게 복구 가능하다.

또한 CVS는 최신 버젼의 소스코드 뿐만 아니라 과거 버젼의 소스코드에 대한 정보를 가지고 있어서 최근의 몇개 버젼에 문제가 생겼다고 하더라도 쉽게 그이전의 소스코드를 얻어올 수 있다.

데이터동기화

요즘은 회사와 집과의 경계가 많이 허물어 졌다 그러다 보니 회사에서 하는일을 가정에서 하기도 하고, 가정에서 했던 일을 회사로 가져가기도 한다. 그럴경우 회사의 컴터와 가정의 컴터에 있는 데이타의 동기화가 필수적이다. 이런 데이타 동기화를 위해서 "노트북", "PDA" 같은걸 사용할수 있겠지만, 이건 너무 비싸다. ftp 도 사용할수 있겠지만, 이거 잘못 사용하면 데이터가 꼬일수 있다. 또한 상당히 불편하다.

이럴때 CVS 를 사용하면 대단히 편하게 작업이 가능하다. 회사에서 작업을 마치고 CVS 서버에 등록하고, 가정으로 돌아가서 CVS 서버에 등록된 최신의 작업을 받아와서 작업을 하고 다시 CVS 서버에 등록만 하면 되기 때문이다.

 

버전관리 시스템이란 어플리케이션을 개발하면서 작성한 것들의 모든 개정판을 저장해 두는

장소다. 이 모든 개정판을 저장하는 장소를 저장소(repository) 라고 대부분 부른다.

저장소의 구성중 일부는 데이터베이스를 저장소로 쓰고, 몇몇은 일반 파일시스템을 사용하고

몇몇은 둘을 조합해서 쓴다.

옛날에는 버전관리 시스템의 사용자들이 반드시 저장소가 들어있는 컴퓨터에서만 작업해야 했다.

이것은 개발자들이 여러장소에서 작업하기도 힘들고, 여러종류의 컴퓨터나 운영체제로 작업하기도 힘들었으므로 상당히 많은 제약이 있었다. 그결과 요즘 대부분의 버전관리 시스템은 네트워크를 통한 작업을 지원한다. 개발자는 네트워크를 통해 저장소에 접근할수 있고, 저장소는 서버역활을 하며 버전관리도구들이 클라이언트로서 이용된다. 네트워크를 통한 저장소의 이용은 개발자가 어디에 있던지, 모든 프로젝트 코드의 모든 버전에 대해 접근할수 있는 자유를 주며, 경쟁자에게는 우리의 귀중한 소스코드를 보여주지 않을수도 있으며 , 또한 누구나 우리의 프로젝트에 개선사항을 보낼수도 있다

저장소에는 무엇을 넣는가?

이질문에 대한 대답은 또다른 질문으로 대체할수 있다. 저장소에 무엇을 넣을지 결정해야할때 자신에게 이질문을 해보라.

“이것이 없더라도 저장소의 것만 가지고 이 프로그램을 만들수 있는가?”

답이 “안돼“인 경우에는 이것이 저장소에 들어가야한다.

그러므로, 코드가 아닌 프로젝트 산출물도 모두 버전관리 아래에 저장되어야하며, 중요전자우편, 회의기록,웹에서찾은 정보등, 나중에 프로젝트를 이해하는데 필요한것이라면 모두 저장소에 저장해 두는것이 좋다.

작업공간과 파일다루기

네트워크의 저장소에 있는 파일을 작업하기 위해서는 일단 로컬작업공간에 저장소의 화일을 복사해와야 한다. 버전관리 시스템마다 이과정을 부르는 이름은 다르지만 가장 널리 사용되는 용어는 checkout 이다. checkout 을 하면 저장소에 있는 화일을 로컬로 복사해온다는 사실을 기억하자.

그리고나서 자신의 로컬작업공간에서 여러가지 내용을 변경하고 이 내용을 저장소에 저장할때는 commit 이라고 부르며 이때 내가 수정한 화일들은 저장소로 전송된다.

물론 내가 수정을 하는동안에 다른 팀원도 동일하게 수정작업을 하고있으며 그 팀원도 저장소에 화일을 저장하는 작업을 한다. 이때를 관리하기 위해서 엄격한 잠금을 할수도있으며 충돌이라고 알려주는 낙관적인 잠금을 사용할수도 있다. 이부분은 나중에 다시 이야기 하도록 하겠다.

데이터가 어떤구조로 저장되는가

대부분의 버전관리시스템의 가장작은 단위는 파일이다. 하지만 파일은 상당히 작은 단위이고 보통 한프로젝트에는 파일이 몇백개씩 되기 마련이고 회사에는 다양한 프로젝트를 진행하기 마련이다. 때문에 대부분의 버전관리 시스템들은 프로젝트 >　모듈 > 파일 구조로 관리하게 되며 이 모듈의 이름을 통해서 파일집단의 관리를 할수있다. 버전관리 시스템들은 파일들에 대해서 각각에 버전을 부여하기도하고 수정한 시기에따라서 버전을 한꺼번에 붙여서 관리하기도 한다. 여기에서 이야기하는 버전은 프로젝트의 릴리즈 번호와는 다르므로 혼동해서는 안된다. 릴리즈 번호같은 용도로 쓰기위해서 태그를 제공하므로 추후 사용법에대해서 알아보자 

브랜치

개발을 하다보면 중심이되는 개발의 주축이 있고 ,  그 흐름에서 벗어난 개발이 있을수 있는데 이때에 같은 저장소에서 작업을 하는것은 서로에게 방해가 되는 경우가 있다. 새로운 제품의 릴리즈를 출시되는 시점같은 경우에 출시제품의 안정화를 위해서 노력하는 팀과, 새로운 기능을 추가하기 위해서 노력하는 팀이 있는경우가 그렇다.

이때에는 프로젝트를 복사해서 새로운 프로젝트를 만들어서 하는 방법도 있지만 만일 복사해서 새로 시작한 프로젝트중 버그를 발견한경우 기존의 중심개발축이 되던 소스에는 그 수정의 병합이 불가능하다. 이럴경우 버전관리 시스템의 브랜치를 사용하는 것이 효과적이다.

브랜치는 고유한 태그가 붙어서 다른 브랜치와 구별되며 브랜치안에 있는 파일의 버전은 숫자가 추가로 붙는다. 브랜치가 너무 복잡하게 나누어지면 개발자들이 어지러워서 사용이 힘들지만 버전관리시스템의 병합기능을 잘 사용하기 위해서는 브랜치를 알아두는것이 유리하다.

[그림1- CVS 구조도]

이 글에서는 무료로 쓸수있고 가장 널리쓰이고 있는 버전관리도구 CVS에 대해서 이야기 하려고 한다.

이제부터 CVS에 대해서 알아보자

 

사용할수 있는 CVS중 두가지를 설치해 보기로 하자

한가지는 대부분 리눅스 시스템을 설치하면 들어있는 GNU CVS 이고

다른한가지는 CVSNT 라는 것이다. 각각의 다운로드는 아래에서 할수있다.

http://www.gnu.org/software/cvs/manual/html_mono/cvs.html

http://www.cvsnt.com/cvspro/

CVS의 전반적인 진행과정에 대해서 생각해보면

CVS 관리자가 저장소로 사용할 공간을 초기화하고, 각각 사용자들이 사용하도록 환경을 구성해두면

프로젝트에 참여하는 사람들은 새로운 프로젝트를 만들고 그안의 소스를 다운받아 작업하게 된다

작업을 마친후에는 자신의 작업 내용을 저장소에 저장하고,

중간에 다른 개발자의 수정작업이 있었다면 적절하게 고친후 다시 수정하는 것이다.

여러가지 과정중에서 개발자 또는 사용자로서 사용하는데에는

이 CVS의 설치과정은 필요없으며 필요없다고 생각하는 사람은 나중에 다시보아도 좋다

대부분의 리눅스 시스템에는 cvs가 설치되어 있으므로 바로 사용가능하고

만약 rpm -qa|grep cvs 로 나타나지 않는사람은 http://www.gnu.org/software/cvs/

에서 다운로드 받아서 설치하기 바란다.

필자의 경우는

# which cvs 로 확인한 결과 아래와 같이 나타난다

/usr/bin/cvs

저장소에는 앞으로 변경될 파일및 데이터를 저장할수있는 충분한 공간이 있어야한다. 어림잡아서 최종모듈의 3배정도되는 파티션에 저장소를 만들고, 스카티원칙(정확한예측이어려운경우 통상2배를 적용)을 적용해서 예상되는 용량의 2배정도를 고려한다. 바이너리 파일을 저장하고자 한다면 여기에 10을곱한 정도의 용량을 생각해야한다

데비안에서는 makerepos 라는 스크립트가 있으며, man cvsconfig 를 통해서 데비안CVS저장소 자동설정에 대한 설명을 볼수있다. 일반적으로 저장소가 /home/cvs 에 만들기로 했다면 다음과 같이 초기화할 수 있다  여기에 여러 프로젝트가 담기게된다.

1.1.1.1. # cvs -d /home/cvs init

여기서 -d는 저장소의 위치를 나타내며, 마지막의 init가 CVS 명령이다.

물론 이 명령을 사용하기 위해서는 /home에 쓰기 권한을 갖고 있어야 한다.

그러므로 대개의 경우 저장소의 초기화는 root 권한을 가진 씨스템 관리자가 하게 된다.

명령이 실행되고 나면 /home에 CVS란 디렉토리가 생기고, 그 안에는 CVSROOT란 디렉토리가 있을 것이다.

이 CVSROOT 디렉토리는 CVS의 각종 설정 내용을 담고 있는 디렉토리이다.

저장소(/home/cvs)의 파일들을 직접 건드리는 것은 절대로 피해야 한다.

이 파일들을 변경하고 싶다면 cvs 명령을 이용해야 한다.

개발자들이 모두 저장소가 있는 씨스템에서 작업을 하거나, 각자의 기계에서 작업을 하되 ssh이나 rsh을 써서 원격으로 CVS를 사용하는 경우에는 cvs라는 그룹을 만들어주고 cvs를 이용할 계정들은 cvs그룹에 포함시켜주면된다.

1.1.1.1. groupadd cvs

1.1.1.2. vi /etc/group

1.1.1.3. # /etc/group 의 내용

---생략---

chaeya:x:500:

mysql:x:501:

nogroup:x:502:

fubi:x:503:

cvs:x:504:chaeya,fubi

만일 개발자들이 시스템에 계정을 가지고 있지않으며 그냥 CVS전용 계정을 발급해주기 위해서는 다른방법을 사용해야한다.

먼저 cvs로 접속할 포트가 사용가능한지를 확인한다.

1.1.1.4. # cat /etc/services |grep 2401

1.1.1.5. cvspserver      2401/tcp                        # CVS client/server operations

1.1.1.6. cvspserver      2401/udp                        # CVS client/server operations

xinetd를 쓴다면 /etc/xinetd.d에 cvspserver란 이름으로 별도의 파일을 만들어야 한다.
파일 내용은 다음과 같다.