1) 지식 창고는 본인이 작성한 콘텐츠(팁/노하우/리소스/강좌 등)을 무료 혹은 가상화폐인 납포인트를 통해 공유하는 공간입니다.
2) 본인이 작성한 콘텐츠에 대해서만 지식 창고에 등록할 수 있으며, 저작권에 위배되는 콘텐츠는 사전경고 없이 삭제될 수 있습니다.
3) 콘텐츠 구매 및 첨부파일 다운로드는 회원그룹 '연구원' 이상 가능하오니, 경험치를 쌓아 진급한 후에 이용 부탁드립니다.
4) 무료 콘텐츠의 본문은 구매절차 없이 즉시 이용할 수 있으며, 판매 납포인트가 있는 콘텐츠는 구매 후 이용할 수 있습니다.
5) 콘텐츠 판매에 따른 납포인트 수익은 지정한 비율(50%)에 따라 판매자에게 지급하며, 납포인트 수익을 통해 진급을 빨리할 수 있습니다.
6) 구매 후 평가를 하면 구매 납포인트의 20%를 돌려 드립니다.
판매자 | 아크마 | 판매 납포인트 | 무료 | 평점 | 0점 / 총 0명 참여 |
---|
# cvs tag TEST_REL_1이제 이 프로젝트는 TEST_REL_1 이라는 꼬리표(tag)가 붙게 된다. 프로젝트 진행중 TEST_REL_1 꼬리표가 붙은 프로젝트를 가져오길 원한다면 아래와 같이 하면 된다.
# cvs co -rTEST_REL_1 myprogdir이제 myprogdir에 TEST_REL_1의 snapshot 프로젝트가 생성이 되었다.
dreamyun@yahoo.co.kr
고친 과정 | ||
---|---|---|
고침 1.0 | 2005년 6월 9일 13시 | |
바이너리 파일 추가 방법, 디렉토리 upload 방법, 오타 수정 | ||
고침 0.9 | 2003년 10월 20일 21시 | |
익명 CVS 설정 추가, diff관련 옵션 설명 추가 | ||
고침 0.8 | 2003년 8월 11일 23시 | |
최초 문서 작성 |
과거는 컴퓨터 시스템의 능력이 매우 제한적이였고 사용하는 유저 역시 제한적이거나 지극히 개인적인 용도로 사용하는 경우가 대부분 이였다. 때문에 소프트웨어역시 비교적 단순했으며 단지 한두명의 개발자 투입만으로도 꽤나 쓸만한 애플리케이션이 만들어지기도 했다.
도스 시절부터 컴퓨터를 다루어왔던 유저라면 "누구누구의 어떤 프로그램" 이라는 얘기를 많이 들어 보았을 것이다. 지금은 사정이 달라져서 아주 간단한 프로그램이 아니고서는 혼자 개발해서 그럭저럭 인지도 있는 프로그램을 만든다는것 자체가 매우 힘들어졌다.
요즘은 UI만 제작하는 것도 하나의 작업으로 분류된다. 인터넷이 일반적으로 보급되면서 대부분의 애플리케이션은 C/S환경하에서 작동하게 된다. 개발자는 데이터전송과 처리에 대한 부분까지 신경써야 하며 많은 경우 서버와 클라이언트가 서로 다른 운영체제하에 놓이며, 특히 서버 프로그램의 경우 여러가지의 전혀 달라보이는 운영체제를 지원해야하는 경우도 있다.
이런 이유로 왠만한 규모의 프로젝트라 할지라도 혼자서 개발을 진행한다는건 매우 힘들며, 대부분 팀단위로 프로젝트를 진행을 하게 된다. 이 팀이란건 또 어떤가 같은 사무실에서 같은 시간에 존재하면서 서로 의견교환을 통해서 프로젝트를 진행 시킬 수도 있지만 인터넷이라는 매체를 통해서 전혀 다른 공간에서 전혀 다른 시간대에 프로젝트를 진행 시켜야 하는 경우도 생긴다. 전 세계인이 참여하는 많은 오픈 프로젝트가 그러하다.
이런 경우 하나의 소스코드를 한명 이상이 접근해서 수정할 수 있는데, 프로젝트를 진행하다 보면 소스코드가 엉뚱하게 꼬일 수 있을 것이다. 같은 사무실에서 단지 몇명의 프로그래머가 작업을 한다면, 서로 의견조율을 하거나 처음부터 각각의 모듈만 담당하게 만들어서 어느정도 문제를 해결할 수 있을 거라고 생각할 수도 있을 것이다. 그러나 막상 프로젝트를 진행해보면 이게 결코 말처럼 쉬운일이 아니란걸 알게 될것이다. 프로젝트를 진행하다 보면 이쪽 시스템에서 테스트하고, 저쪽 시스템에서 테스트하고 문제가 생기면 즉각 수정을 하게 되는데, 이러다보면 소스코드가 여기저기 위치하게 되고 결국 어느 소스가 최근 소스코드인지 헷갈리는 사태가 발생하게 된다. 하물며 오픈소스와 같이 수많은 프로그래머가 느슨하게 묶여있는 경우는 더 말할 필요도 없다. 적당한 버젼관리 도구의 사용없이는 프로젝트의 진행자체가 불가능해질 것이다.
이러한 문제의 해결을 위해서 여러도구가 개발되었는데, 그중 하나가 CVS로 현재 가장 널리 사용되고 있는 버젼관리 도구이다.
CVS는 Concurrent Version System 의 줄임말로써 직역 하자면 공동 버젼 시스템, 의역하자면 "공동으로 진행하는 프로젝트의 버젼 관리 시스템" 정도가 될것이다.
CVS는 사용하기에 따라서 여러가지 용도로 사용할수 있다. 이번장에서는 CVS를 이용할수 있는 다양한 상황들에 대해서 알아보도록 하겠다.
회사혹은 학교에서 프로젝트를 진행하다보면, 여러명이서 하나의 프로젝트를 진행하는 경우가 발생할것이다.
이럴경우 보통 모듈별로 개발을 하게 되겠지만, 또한 모듈은 전체 프로젝트에 영향을 미치게 되므로, 자신의 모듈버젼과 전체 프로젝트의 버젼을 컨트롤할수 있어야 한다. 그리고 코드가 충동하게 될경우(서로 같은 부분을 수정함으로써)의 문제를 해결할수 있어야 한다.
이러한 작업은 프로젝트 규모가 작고 개발 참여자 수가 적고, 개발 참여자가 가까운 지역(사무실 같은)에 모두 모여있다면, 한명의 버젼관리자(보통은 팀장)를 두고 그럭저럭 관리가 가능할것이다.
그러나 조금만 프로젝트가 커지고, 개발참여자 수가 많아지고 개발자가 지역적으로 떨어져 있는 상황에서는 거의 불가능 하다는 걸 알수 있게 될것이다. 특히 인터넷을 통해서 느슨하게 연결된 오픈 프로젝트의 경우 도구를 사용하지 않는 다면 거의 관리가 불가능 할 것이다.
CVS 를 사용하면 이러한 대규모의 프로젝트에서 각 모듈 개발자가 자신의 버젼을 유지하면서 전체 프로젝트에 참여할수 있도록 할수 있다.
실제로 KDE, GNOME, APACHE 서버 등 다양한 프로젝트가 CVS 를 이용해서 프로젝트를 관리하고 있다. 이러한 프로젝트는 규모가 작아도 수십명, 혹은 수백명이 프로젝트를 진행하게 되는데(게다가 지역적으로 멀리 떨어져 있다), CVS가 중간에서 프로젝트가 산으로 가지 않도록 중계해준다. 오픈 프로젝트를 하는데 있어서 CVS는 거의 표준적으로 사용되는 버젼관리 도구이다.
CVS 를 사용할경우 자동적으로 프로젝트 백업의 문제까지 해결이 가능하다. CVS 는 중간에 CVS 서버가 있어서, 프로젝트 데이터의 저장소 역할을하며 모든 개발자는 CVS 서버에서 최신의 프로젝트를 다운로드 받아서, 자신의 컴퓨터에서 테스트하고 코딩해서, 이걸 다시 CVS 서버에 업데이트 시키는 방식을 사용하게 된다.
그러므로 실수로 자신의 프로젝트 데이터가 날아간다고 해도 전혀 염려할 필요가 없다. 그냥 서버에서 다시 다운 받기만 하면 된다. 최악의 경우 CVS 서버가 날라갔다고 하더라도 가장 최근의 쏘쓰를 가진 개발자가 있을 것이므로 쉽게 복구 가능하다.
또한 CVS는 최신 버젼의 소스코드 뿐만 아니라 과거 버젼의 소스코드에 대한 정보를 가지고 있어서 최근의 몇개 버젼에 문제가 생겼다고 하더라도 쉽게 그이전의 소스코드를 얻어올 수 있다.
요즘은 회사와 집과의 경계가 많이 허물어 졌다. (좋은 현상인지 나쁜 현상인지는 좀 생각해 봐야겠지만) 그러다 보니 회사에서 하는일을 가정에서 하기도 하고, 가정에서 했던 일을 회사로 가져가기도 한다. 그럴경우 회사의 컴터와 가정의 컴터에 있는 데이타의 동기화가 필수적이다. 이런 데이타 동기화를 위해서 "노트북", "PDA" 같은걸 사용할수 있겠지만, 이건 너무 비싸다. ftp 도 사용할수 있겠지만, 이거 잘못 사용하면 데이터가 꼬일수 있다. 또한 상당히 불편하다.
이럴때 CVS 를 사용하면 대단히 편하게 작업이 가능하다. 회사에서 작업을 마치고 CVS 서버에 등록하고, 가정으로 돌아가서 CVS 서버에 등록된 최신의 작업을 받아와서 작업을 하고 다시 CVS 서버에 등록만 하면 되기 때문이다. (물론 이왕이면 가정에까지 회사일을 가지고 가지 않으면 좋겠지만..)
또한 덤으로 자신의 중요한 자료까지 자동으로 백업된다.
필자 역시 이러한 방법으로 작업을 한다. 작업거리가 좀 남았는데, 회사에서는 일이 잘안되고(실은 일하기 싫어서겠지만 --;), 그냥 집에가서 느긋하게 TV도 보고, 웃통 벗어던지고 일하고 싶을때 매우 편하게 CVS를 이용할수 있다.
지금 까지 CVS에 대한 개론적인 설명을 알아 보았다. 이제 본격적으로 CVS를 설치하고 운용하고 사용하는 방법을 알아보도록 하겠다. CVS 서버 설치는 redhat 8.x 리눅스를 기준으로 하겠다. 대부분의 redhat 리눅스 배포판은 cvs 를 기본적으로 포함하고 있다. rpm 패키지 관리자를 통해서 설치하자.
이제 Internet services daemon 에 cvs 서버를 등록 시켜주기만 하면 된다. 레드헷 7.x 버젼부터는 inetd 대신에 xinetd 가 Internet services daemon 으로 사용되어 지고 있다. /etc/xinetd.d 디렉토리 밑에 cvspserver 이란 이름으로 서비스 설정파일을 만들도록 하자. 내용은 다음과 같다.
service cvspserver { disable = no flags = REUSE socket_type = stream wait = no user = root server = /usr/bin/cvs server_args = --allow-root=/home/cvs pserver log_on_failure += USERID } |
# echo "2401 stream tcp nowait root /usr/bin/cvs cvs -f \ --allow-root=/cvsroot pserver" >> /etc/inetd.conf |
위의 설정값들중 --allow-root를 주목하기 바란다. 프로젝트가 서버에 저장된다면 당연히 이들 프로젝트가 서버의 어디 디렉토리로 저장되어야 하는지 지정할 수 있어야 할것이다. cvs에서는 이를 repository(이하 저장소)라고 한다. --allow-root는 cvs 저장소가 /home/cvs임을 명시해 주기 위해서 사용된다. 만약 새로운 프로젝트인 hello_world를 만들었다면 이 프로젝트는 /home/cvs/hello_world 디렉토리에 저장이 된다.
이제 xinetd 데몬(혹은 inetd데몬)을 다시 실행(/etc/rc.d/init.d/xinetd restart) 시키면 cvs 서버가 작동하게 될것이다. cvs 서비스는 2401 포트를 이용해서 서비스 된다(/etc/services 참조). 제대로 cvs 서비스가 되고 있는지 알아보기 위해서 포트 스캐닝 도구인 nmap 을 사용해서 확인해 보도록 하자.
[root@cvs xinetd.d]# nmap 192.168.0.4 Starting nmap V. 2.54BETA7 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1527 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 80/tcp open http 111/tcp open sunrpc 2401/tcp open cvspserver 3306/tcp open mysql |
다른 배포판을 사용하더라도 설치상에 있어서 문제점은 없을것이다. 데비안 이라면 전용 패키지관리자를 이용해서 설치하면 된다. 패키지 설치가 여의치 않다면 쏘쓰를 직접 컴파일 해서 설치 하면 된다.
cvs 는 cvspserver 를 이용한 서비스 외에도 rsh, ssh 를 이용한 서비스도 가능하다. 이에 대한 내용은 CVS 사용 문서를 참고 하기 바란다. 이문서에서는 가장 널리 사용되는 cvspserver 방식에 대해서만 설명하고 있다.
위의 설정에서 우리는 /home/cvs를 프로젝트들을 위한 저장소로 사용한다고 했는데, 저장소로 사용하기 전에 저장소 터를 다지기 위한 사전작업이 필요하다.
이러한 작업은 cvs에서 제공하는 init옵션을 통해서 가능하다.
# cvs -d /home/cvs init |
CVS 에 서버를 만들어 놓았으면 이제 CVS 자원을 사용하도록 환경설정을 해주어야 한다. 가장 중요한 건 공동으로 작업할 프로젝트 파일들이 저장될 CVS 저장 디렉토리(저장소)를 설정하는 일이다.
일단 우리는 위의 /etc/xinetd.d/cvspserver 를 설정하면서 cvs 데몬이 뜨게될경우 --allow-root 옵션을 이용해서 /home/cvs 를 홈디렉토리(프로젝트가 저장될 디렉토리)를 지정했다. 이제 /home/cvs 를 실제 프로젝트 사용자들이 사용할수 있도록 권한 설정을 해주어야 한다.
cvs 의 권한 설정을 위해서 cvs 란 그룹을 만들도록 하고 /home/cvs 디렉토리에 cvs 그룹에 대해서 읽기/쓰기/실행 권한을 부여하도록 하자.
# groupadd cvs # mkdir cvs # chmod 770 cvs |
이제 CVS 서버의 설정이 끝났음으로, 클라이언트의 입장에서 어떻게 프로젝트를 등록하고 공동으로 작업을 진행시킬수 있는지에 대해서 알아보도록 하겠다. 이러한 작업들은 클라이언트에게 제공되는 "cvs" 라는 프로그램을 통해서 이루어진다.
CVS 의 사용방법은 다음과 같은 환경하에서 테스트되었다.
+------------+ | @cvs | project : hello_world | CVS SERVER | +------------+ | | +------------+------------+ | | +---------+ +---------+ | @myhome | | @one | +---------+ +---------+ |
익명 CVS란 말그대로 일반 사용자에게 CVS를 읽고/쓸수 있는 권한을 부여하는 것이며, 많은 오픈 프로젝트들이 익명 CVS를 허용해서 가능한한 많은 개발자가 참여할 수 있도록 길을 열어 놓고 있다.
이러한 익명 CVS사용자는 보통 프로젝트에 대한 읽기권한만을 부여한다. 익명 사용자에게 쓰기권한을 주면 프로젝트의 진행이 너무 산만해 질 수 있기 때문이다. 익명 사용자(혹은 개발자)는 프로젝트에 반영해야 될 내용이 있을 때 메일등을 통해서 프로젝트 메인 개발자에게 통보하는게 보통이다.
익명 CVS를 허용하기 위해서는 우선 시스템에 anonymous계정이 만들어져 있어야 한다. 쉘을 가지지 못하도록 설정한다.
# useradd anonymous -s /bin/false |
# echo anonymous: > /cvsroot/CVSROOT/passwd |
익명 CVS사용자의 경우 아래와 같이 설정해서 읽기만 가능하도록 권한을 제한시킨다.
# echo anonymous > /cvsroot/CVSROOT/readers |
cvs 서버에 프로젝트를 등록시키고, 프로젝트를 업데이트하고, 받아오기 위해서 우리는 "cvs" 라는 전용 클라이언트를 사용하게 된다. "cvs" 다음에 여러가지 명령행 옵션을 이용함으로써, 원하는 작업을 하게 된다.
"cvs" 프로그램을 사용하기 위해서 우리는 CVS 서버에 접근해서 지정된 디렉토리(프로젝트가 저장되는 디렉토리 다른말로 "저장소") 가 어디인지 cvs 프로그램에 알려주어야만 한다. 보통 환경변수인 CVSROOT 를 통해서 "cvs" 에게 CVS 서버의 정보를 알려준다. 그러므로 자신의 홈디렉토리의 .bash_profile 파일에 다음과 같은 내용을 추가시켜주어야 한다.
CVSROOT=:pserver:yundream@192.168.0.5:/home/cvs |
환경변수 CVSROOT 를 사용하지 않고 -d 를 이용하는 방법도 있다.
cvs -d :pserver:yundream@192.168.0.5:/home/cvs [옵션] |
프로젝트를 아무나 접근해서 사용하게 해서는 당연히 안될 것이다. 그러므로 최초에 아이디와 패스워드를 이용한 인증절차를 거치게 된다.
CVS 서버에 로그인 하기 위해서는 "cvs" 다음에 옵션으로 login 을 주고 실행시키면 된다.
# cvs login CVS password: |
물론 당연히 CVS 서버인 192.168.0.5 에는 yundream 이란 사용자가 등록되어 있어야 하며 이 사용자는 cvs 그룹에 포함되어 있어야 한다.
가장 먼저 해야할일은 진행될 프로젝트를 만들고 등록하는 일이다. 우리가 진행하고자 하는 프로젝트는 hello_world 프로젝트이며, 여기에는 hello.c라는 하나의 파일이 포함되어 있다. 다음은 hello.c의 코드이다.
int main() { printf("Hello World\n"); } |
# cd hello_world # cvs -d:pserver:yundream@192.168.0.5:/home/cvs import hello_world project start |
# cvs import hello_world project start N hello_world/hello.c No conflicts created by this import |
이렇게 하면 cvs서버의 저장소에 hello_world란 디렉토리가 생기고 여기에 hello.c가 올라가게된다.
참고: cvs 저장소에 올라가는 파일 원래 파일이름뒤에 ',v'이 붙어서 저장된다. hello.c라면 hello.c,v라는 이름으로 저장되며 여기에는 hello.c의 원래 내용외에 버젼 관리를 위한 각종 정보가 들어가게 된다.
프로젝트 관리자가 프로젝트를 만들었다면 이제 프로젝트 개발자들이 프로젝트를 받아와서 필요한 작업을 해야할 것이다. 프로젝트에 가져오는 방법은 간단하다. "cvs" 다음에 checkout(혹은 co) 옵션을 사용하면 된다. co 옵션 뒤에는 등록할 프로젝트 이름(hello_world)를 명시해 주면 된다.
# cvs co hello_world cvs server: Updating hello_world U hello_world/hello.c |
그런데 원래의 hello.c를 보면 printf()함수가 선언되어 있는 stdio.h가 빠져있다. 대부분의 경우 문제가 없지만 컴파일러에 따라서 경고메시지를 보내거나 심한경우 컴파일 실패하는 경우도 있다. 그래서 헤더파일을 추가하기로 했다.
#include <stdio.h> int main(int argc, char **argv) { printf("Hello world"); } |
# cvs commit -m "stdio.h 헤더파일 인클루드" hello.c Checking in hello.c; /home/cvs/hello_world/hello.c,v <-- hello.c new revision: 1.2; previous revision: 1.1 done # |
이제 여러분은 hello_world 프로젝트의 진행 일원이 되었다. 프로젝트 참여 개발자로서 여러분이 컴퓨터 앞에 앉았다면 가장 먼저 해야할일은 간밤에 누군가 프로젝트를 수정하지 않았는지 확인하고 테스트하는 일부터 해야 한다. 최근 프로젝트에 대한 변경사항은 "up"을 이용해서 확인할 수 있다.
[yundream@myhome hello_world]$ cvs up cvs server: Updating . P hello.c [yundream@myhome hello_world]$ |
[yundream@myhome hello_world]$ cvs log hello.c cvs server: Logging . RCS file: /home/cvs/hello_world/hello.c,v Working file: hello.c head: 1.1 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 1; selected revisions: 1 description: ---------------------------- revision 1.1 date: 2002/06/07 01:36:27; author: yundream; state: Exp; stdio.h 헤더파일 인클루드 ============================================================================= |
이렇게 해서 새로운 소스 파일을 가져왔는데, 어느 코드의 어떤 라인이 수정되었는지 확인하고 싶을 때가 생길 것이다. 이러한 버젼별 코드 변경사항의 히스토리가 남게 된다면 나중에 문제가 생겼을 때 이전버젼의 코드를 쉽게 얻어낼수도 있을 것이다.
cvs는 버젼별 코드변경사항을 모두 저장하며 개발자는 이 내용을 이용해서 코드변경사항을 확인할 수 있을 뿐 아니라 문제가 생겼을시 이전 버젼의 코드를 얻어올 수도 있다.
참고: 물론 이러한 작업을 위해서는 약간의 수작업이 필요한데, 공개된 CVS프론트엔드들은 자동으로 이러한 귀찮은 일을 대신 해준다. 아마도 웹기반의 CVS프론트엔드가 가장 좋은 선택이 될 것이다.
버젼별 변경내용은 diff를 통해서 확인할 수 있다.
//hello.cc에 대해서 1.1버젼과 1.2버젼과의 변경내용을 출력하시오. # cvs diff -r 1.2 -r 1.1 hello.cc bash-2.04# cvs diff -r 1.2 -r 1.1 hello.c Index: hello.c =================================================================== RCS file: /home/cvs/hello_world/hello.c,v retrieving revision 1.2 retrieving revision 1.1 diff -r1.2 -r1.1 1,2d0 < #include <stdio.h> < |
단지 diff만 사용하면 가장최근의 변경사항을 출력한다.
#cvs diff test.cc |
이렇게 해서 프로젝트를 진행하다 보니 README파일을 추가시켜야 할 필요성을 느끼게 되었다. 이처럼 프로젝트를 진행하다 보면 중간중간 여러개의 파일을 추가해야 될건데 이럴경우 add를 이용해서 파일을 추가하면 된다.
# cvs add README cvs server: scheduling file `README' for addition cvs server: use 'cvs commit' to add this file permanently |
이제 다른 개발자가 cvs up을 하면 README파일이 추가된것을 확인할 수 있게 된다.
# cvs up cvs server: Updating . U README |
위의 경우는 "팀장"이 파일을 올리고, "팀원"이 파일을 받아서 수정하고 다시 파일을 올리는 과정을 밟고 있다. 그러나 하나의 프로젝트파일에 대해서 2명이 동시에 작업을 하다보면 충돌되는 경우가 생길수 있을것이다.
예를 들어서 "팀장"과 "팀원"이 동시에 같은 라인을 수정하고 있는데, 팀장이 먼저 commit 를 했다고 하자. 잠시 후에 팀원이 commit 하면, 같은 코드라인에 대해서 충돌이 일어나게 될것이다.
그렇지만 걱정할것 없다. cvs 가 알아서 자동적으로 관리해주기 때문이다. 팀원이 자신의 쏘쓰를 commit 하려고 하면 cvs 는 자동적으로 "코드라인에 충돌이 일어났음으로 먼저 update 를 하시오" 라는 메시지를 출력한다. 그래서 update 를 시키면 어느 부분이 충돌을 일으키는지 표시해준다.
다시 프로젝트 쏘쓰인 hello.c 로 돌아가서, 팀장이 다음과 같이 코드를 약간 수정했다고 가정하자.
#include <stdio.h> int main(int argc, char **argv) { printf("Hello World!!!!!\n"); } |
#include <stdio.h> int main(int argc, char **argv) { printf("Hello World??\n"); } |
[yundream@myhome hello_world]$ cvs commit -m hello.c cvs commit: Examining . cvs server: Up-to-date check failed for `hello.c' cvs [server aborted]: correct above errors first! |
# cvs up cvs server: Updating . RCS file: /home/cvs/hello_world/hello.c,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into hello.c rcsmerge: warning: conflicts during merge cvs server: conflicts found in hello.c C hello.c |
#include <stdio.h> int main(int main, char **argv) { <<<<<<< hello.c printf("Hello World!!!!!\n"); ======= printf("Hello World??\n"); >>>>>>> 1.3 } |
쏘쓰파일중에 더이상 필요가 없어진 파일에 대해서는 delete 명령을 이용할수 있다. README 파일이 더이상 필요 없다면 우선 README 파일을 rm을 이용해서 지워주고.. delete한 후 commit시키면 된다.
# rm README # cvs delete README cvs server: scheduling `README' for removal cvs server: use 'cvs commit' to remove this file permanently # cvs commit -m "리드미 더이상 필요 없어서 삭제했음" README Removing README; /home/cvs/hello_world/README,v <-- README new revision: delete; previous revision: 1.1 done |
# cvs up cvs server: Updating . cvs server: README is no longer in the repository |
CVS는 여러명의 개발자가 참여한다는 가정하게 사용되어 지므로 이를 효율적으로 프로젝트가 진행되도록 하기 위한 몇가지 지켜야할 사항이 있는데 이들에 대해서 알아보도록 하겠다.
아침에 와서 컴퓨터 앞에 앉았다면, 가장먼저 cvs up 을 이용해서 밤사이에 업데이트 된 내용이 있는지 확인을 한다. 그다음 작업에 들어간다. 공동작업을 할때 가장 중요한것은 상대편 작업자가 무슨일을 하고 있는지에 대해 알아야 하는 것이다. 습관적으로 cvs up을 해줘야 한다.
그리고 꽤 중요한 수정이 있었다고 하면 중간중간에 commit하도록 한다. commit할때도 우선 cvs up을 이용해서 수정사항이 있었는지 확인하도록 하고 당연하지만 반드시 컴파일이 되는지 확인한 후 commit 시켜야 한다.
CVS 를 제대로 사용하기 위해서는 CVS 저장소의 구성을 잘해놓아야 한다. 예를 들어 Project_A 란 프로젝트를 시작한다면 Project_A 란 디렉토리를 만들고 그 아래에 프로젝트에 필요한 각종 디렉토리, 즉 작업문서의 저장을 위한 doc 디렉토리, 실제 쏘쓰가 포함될 src 디렉토리, 인크루드 파일이 존재하게 될 src/include 디렉토리 등, 체계적으로 프로젝트를 관리할수 있도록 미리 저장소를 세팅해 놓아야한다. 물론 나중에라도 디렉토리를 추가할수도 있지만, 이왕이면 미리 프로젝트에 대한 계획을 잘 세워두는게 좋을것이다.
Project_A --+-- doc -+-- readme.txt | | | +-- todo_list.txt | | | +-- schedule.xls | +-- src --+-- Makefile | +-- main.cc | +-- io.cc | +-- include --+-- io.h | | | +-- common.h +-- lib --+-- crypt.a |
필자는 개인 정보의 관리를 위해서 CVS 를 사용한다. 회사에서 일하다가 좋은 사이트를 찾았다거나, 중요한 메모 상황이 발생했다거나, 좋은 자료를 찾았을경우, 일정관리 까지 모두 CVS 로 저장해두고 집에 있건 회사에 있건 개인 자료를 공유할수 있도록 만들어 놓았다.
모질라의 북마킹 데이타를 CVS 로 연결시켜 놓았기 때문에, 집에 있건 회사에 있건 동일한 북마킹 데이타를 유지할수 있으며, 일정관리(Koraganizer 을 이용한다), 메모데이타(knotes) 역시 공유 가능하도록 해두어서 편하게 사용하고 있다.
이렇게 CVS를 사용함으로써 PDA, email, 노트북(돈이 좀 있어야 한다) 매체를 이용하지 않고도, 간단하게 데이타 동기화를 이루어 낼수 있다.