2003년 4월 9일 수요일

CVS 메뉴얼(Concurrency versions System Manual)

http://www.cvshome.org/
http://kldp.org/KoreanDoc/html/CVS_Tutorial-KLDP/index.html
http://wiki.kldp.org/wiki.php/DocbookSgml/CVS-KLDP
http://wiki.kldp.org/wiki.php/CVS/GuideLine

CVS repository에 등록할 module 만들기 : cvs import
$ cd module 안으로 들어감
$ cvs import 모듈명 DIST명(적당히) Branch명(적당히)

repository에서 처음으로 source 가져오기 : cvs checkout [module명] (cvs co)
(pserver를 이용한다면) 먼저 export CVSROOT=:pserver:ilashman@host명:/cvsroot(cvs repository)
(ext)를 이용한다면 먼저 export CVSROOT=:ext:ilashman@host명:/cvsroot(cvs repository)
                                  export CVS_RSH=ssh

repository에 자료 올리기 : cvs commit 파일명

repository에서 변경된 source 받아오기 : cvs update 파일명 (파일명을 생략하면 모든 파일)

sticky tag가 달려있을 때. sticky tag를 무시하고 head에 있는 것을 받아오는 방법. : cvs update -A

repository에 새 파일 등록 하기 : cvs add 파일명  (그 다음 'cvs commit 파일명' 을 실행)

repository에 있는 파일 지우기 : 우선 source directory에서 그 파일을 지운다.
                                            cvs remove 파일명 (그 다음 'cvs commit 파일명' 을 실행)

repository에 있는 디렉토리 지우기 : 불가능하다. 대신 -P 옵션을 쓰면 빈 디렉토리는 안 받아온다.

tag 달기 : cvs rtag [tag명] [module명]
현재 디렉토리의 내용으로 tag 달기 : cvs tag [tag명]

tag 달려 있는 revision 받아오기 : cvs co -r [tag명] [module명]

log 확인하기 : cvs log
status : cvs status (sticky tag, release tag등을 확인할 수 있다.)
---------------------------------------------------
CVS Repository 만들기

groupadd cvs

/etc/group 파일을 편집하여
---------------------------
cvs:*:510:minskim,sehkone         # cvs에 접근할 수 있는 계정들을 group에 추가
---------------------------
이제 다음 명령으로 디렉토리의 권한을 열어 주면 된다.
chgrp -R cvs /home/cvs
chmod ug+rwx /home/cvs /home/cvs/CVSROOT
이후로는 cvs 그룹에 속한 개발자는 이 저장소를 마음대로 이용할 수 있다.

.2.2. 계정이 없는 경우
개발자들이 씨스템에 계정을 갖고 있지 않다면 CVS의 암호 인증 방식을 이용해서 CVS 써버에 접속할 수 있다. 개발자 각각은 CVS 계정(씨스템 계정과는 다르다)을 부여받게 되며, inetd를 통해 정해진 포트로 CVS를 사용하게 된다. 설정은 조금 복잡하지만 개발자들에게 일일이 씨스템 계정을 발급할 필요가 없으므로 씨스템 관리 측면에서는 보다 낳은 방법이라 할 수 있다. 특히 불특정 다수에 대해 CVS로 파일을 받아갈 수 있도록 해야 하는 공개 프로젝트의 경우 대부분이 이 방식을 채택하고 있다. 아파치나 모질라 같은 경우가 대표적인 예가 될 것이다. 반면 개발자들이 씨스템 계정을 갖고 있는 경우라도 ssh이나 rsh을 통한 접속을 허용하고 싶지 않을 경우는 별도의 CVS 계정을 만들어 암호 인증 방식을 이용할 수도 있다.

그러면 inetd로 CVS 접속을 허용하는 방법을 알아보자. 우선 CVS가 사용하는 포트 번호(2401번)를 등록해야 한다. /etc/services에 다음과 같은 줄이 있는지 살펴 보자. cvspserver      2401/tcp

만일 없다면 위의 내용을 추가하면 된다. 다음은 실제로 해당 포트를 열어줄 차례인데, 이는 씨스템이 inetd를 쓰고 있는지, xinetd를 쓰고 있는지에 따라 설정 방법이 다르다. 먼저 inetd의 경우는 /etc/inetd.conf에 다음 내용을 추가한다. cvspserver stream tcp nowait root /usr/bin/cvs cvs
   --allow-root=/home/cvs pserver

편의상 두 줄로 나타냈으나, 실제 파일에는 한 줄로 들어가야 한다. 만약 tcpd를 사용한다면 위의 줄 대신 다음을 추가한다. cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs
   --allow-root=/home/cvs pserver

물론 /usr/bin/cvs나 /usr/sbin/tcpd는 실제로 이들 명령이 위치하는 절대 경로로 써 주어야 한다.

새로운 설정 내용을 반영하려면 inetd를 재시작하여야 한다. inetd의 프로세스 ID가 357이라면 다음과 같이 HUP 신호를 보내면 된다. # kill -HUP 357



xinetd를 쓴다면 /etc/xinetd.d에 cvspserver란 이름으로 별도의 파일을 만들어야 한다. 파일 내용은 다음과 같다. # default: on
# description: The cvspsever serves CVS Passowrd Server sessions; it uses \
#          unencrypted username/password pairs for authentication.
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
}

inetd의 경우와 마찬가지로 /usr/bin/cvs는 cvs 명령의 절대 경로, /home/cvs는 저장소의 위치로 바꿔 준다.

xinetd를 재시작하는 방법도 inetd와 동일하다. 우선 xinetd의 프로세스 ID(357이라 가정한다)를 알아낸 후, HUP 신호를 보내자. # kill -HUP 357



이제 접속 포트는 열어두었으니, 개발자들에게 CVS 계정을 발급하는 일만 남았다. 암호 인증 방식을 이용하는 경우, 계정과 암호는 저장소의 CVSROOT 디렉토리 밑에 passwd란 이름의 파일에 저장된다. 여기에서는 /home/cvs/CVSROOT/passwd가 될 것이다. 하지만 이 파일은 처음에는 존재하지 않는다. 그러므로 직접 만들어주어야 하는데, 먼저 예를 하나 보도록 하자. minskim:YxNPCzaM/WCp2:cvs
sehkone:Yw2najHG5cLfo:cvs

각 줄은 한 사용자에 대한 정보를 담고 있다. 줄은 ':'을 경계로 다시 세 부분으로 나뉘는데 첫 부분이 사용자의 CVS 계정 이름(씨스템 계정과는 무관하다), 그 다음은 암호, 그리고 마지막은 씨스템 계정 이름이다. 즉, 이 파일에는 현재 minskim과 sehkone이라는 두 사용자가 등록되어 있고, 이들이 CVS 이용시에는 cvs란 씨스템 계정의 권한을 갖는 것이다. 암호부분은 유닉스 씨스템에서 전통적으로 사용되는 crypt 함수를 이용하여 변환된 값이 저장되어 있다. 새로운 사용자를 추가하려면 같은 형식으로 한 줄을 추가해 주면 된다.

마지막으로 필요한 것은 cvs란 씨스템 계정에 저장소에 대한 읽기 및 쓰기 권한을 주는 것이다. 3.2.1절과 일관성을 유지하려면 cvs란 그룹을 만들고 cvs란 사용자를 cvs 그룹에 추가한 후, cvs 그룹에 대한 권한을 같은 방법으로 열어주면 된다. # chgrp -R cvs /home/cvs
# chmod ug+rwx /home/cvs /home/cvs/CVSROOT


-------------------------------------------------
CVS에 실행파일(*.pl, *.sh)을 commit할 때 주의할 점.

실행 permission (execution permission)을 주지 않고 commit하면 update와 check out시에도 실행 permission이 없다. 따라서 처음에 commit하기 전에 실행권한을 준다.
(chmod u+x 실행 파일)
그렇지 못했다면 직접 repository로 가서 실행권한을 줘야만한다.
처음 commit 이후에는 permission을 바뀌어도 repository에 반영이 안된다.;;

-------------------------------------------------
vendor tag은 third party의 소스를 가져와 자신의 CVS에 올려 놓고 사용하는 경우에 유용합니다.

third party는 third party 대로 개발을 할테고, 자신도 역시 소스를 수정해서 사용할텐데요.

나중에 third party가 프로그램을 버젼업 하면 버젼업 된 프로그램에 다시 수정한 내용을 반영해야 하는

난감한 상황이 생겨 버립니다. 예를 들어 우리가 PHP4 소스를 가져다 어느 부분을 수정해서 사용하고 있었는데

PHP5가 나와버렸다.. 면. 버젼업은 해야 겠고, 수정한 부분도 반영해야 겠지요.


이럴 때 vendor tag를 사용하면 유용합니다.


사용 방법을 순서대로 살펴보겠습니다.

postfix 1.x를 가져와서 수정한 뒤, postfix 2.x로 업그레이드 하려 한 다 가정하겠습니다.

1. postfix 1.x를 CVS에 import 하기

아래와 같이 import 합니다.

cvs import -m "postfix version 1.x" postfix/ POSTFIX POSTFIX_1_X


2. import된 postfix를 마음대로 수정하고, 사용합니다.


3. postfix1.x를 수정하며 사용하다 보니 postfix 2.0이 나왔습니다.

1.x대에서 수정된 소스를 2.0에 반영하려고 할 때 다음과 같이 합니다.

일단 2.0 소스를 import 합니다.


cvs import -m "postfix version 2.0" postfix/ POSTFIX POSTFIX_2_0

1의 명령과 달라진 건 release tag 밖에 없습니다.

import를 하면 cvs가 1.x 버젼에서 수정한 부분과 2.0 버젼에 conflict가 발생했다고 경고합니다.
  
4. 아래와 같이 실행합니다.

cvs checkout -jPOSTFIX_1_X -jPOSTFIX_2_0 postfix

그러면 1.x 버젼의 수정본과 2.0 버젼이 merge된 상태로 내려받게 됩니다.

-----------------------
branch 만들기, 이용하기

cvs tag -b branch명
cvs up -r branch명
cvs ci -r branch명 파일명

Merging branch

cvs update -j Branch명1 -j Branch명2 모듈명

http://www.psc.edu/~semke/cvs_branches.html

댓글 없음:

댓글 쓰기