'SCM'에 해당되는 글 4건

  1. 2008.08.19 cvs 파일 상태 기호 (2)
  2. 2008.04.30 SVN 사용하기
  3. 2007.03.03 cvs 사용법
  4. 2006.12.11 CVS Command Line Reference
cvs 디렉토리 내에서 checkout 이나 update 명령을 내리고 나면 파일 리스트들 앞에 알수 없는 영어 한 글자가 꼭 보인다. 당췌 이게 무엇인지에 대해서 너무 심각하게 생각하지 말자. 그냥 파일의 현재 상태를 나타내는 하나의 기호일 뿐이다. 아래 표에서 그 기호에 대해 간략하게 살펴 보도록하자 :
  • A file 로컬 워크스페이스('지역 작업공간'이라고 번역 되기도 한다)에 파일이 추가 되었지만 아직 저장소(repository)에는 저장되지 않았다.
  • C file 파일을 갱신하는 과정에서 충돌이 발생 했음을 의미한다. 즉, 로컬에 있는 파일과 저장소에 있는 파일의 버전이 맞지 않는다는 소리다. 로컬 file의 충돌 위치에 충돌 표시가 들어 가며, 원본 로컬 파일은 ".#file.버젼번호"라는 이름으로 워크스페이스에서 백업으로 보존 된다.
  • M file 워킹 스페이스에서 파일이 수정되었다는 의미. 저장소에 갱신하려면 체크인을 해야 한다.
  • P file 아래에 나오는 "U"와 동일한 의미. "P"는 파일을 최신 상태로 갱신할 때 서버가 패치를 사용한다는 차이가 있다.
  • U file 로컬 파일이 저장소에 맞춰 최신 상태로 업데이트 되었음을 의미. 저장소 버젼이 로컬보다 이후인경우나 저장소에는 있지만 로컬에는 없는 경우 모두 "U"로 표시된다.
  • ? file 워킹 스페이스에는 있지만, 저장소에는 파일이 없는 경우. 파일을 추가해야 한다면 cvs add를 사용하면 되고, 파일을 무시 해야 한다면 .cvsignore를 수정 하여 cvs에게 파일을 무시하라고 지정하면 된다.

'도구의발견' 카테고리의 다른 글

키보드 리매핑하기(레지스트리 변경)  (7) 2008.12.05
Handle leak 찾기  (3) 2008.10.02
cvs 파일 상태 기호  (2) 2008.08.19
GDB Tutorial  (0) 2008.08.19
Break point  (0) 2008.08.18
vim Undo & Redo  (3) 2008.08.06
Posted by kukuta
TAG cvs, SCM

댓글을 달아 주세요

  1. jm2y 2008.09.09 13:16  댓글주소  수정/삭제  댓글쓰기

    글이 뜸하군화~

팀에서는 소스세이프를 쓰지만 개인적으로는 서브버젼을 사용해보기로 마음먹었습니다.
매번 저장소를 만들 때 마다 메뉴얼을 살펴 봐야 해서 간단하게나마 블로그에 요약 합니다.

1. Repository 생성하기
저장소는 각 프로젝트 마다 하나씩 존재 해야 합니다.
저장소를 생성 할 때는 svnadmin을 사용 합니다.

$ svnadmin create --fs-type bdb /home/kukuta/SVN/sample

--fs-type은 파일 시스템을 지정합니다. 일반 적인 파일 시스템을 사용하려면 'fsfs', 버클리DB를 사용 할 경우에는 bdb를 지정합니다. 지정하지 않으면 디폴트로 셋팅 됩니다.
자세한 사항은 'svnadmin help create'를 하시면 create에 대한 보다 상세한 정보를 얻을 수 있습니다.
버클리DB로 파일을 저장하는 repository를 '/home/kukuta/SVN/sample' 에 생성하였습니다.

2. Repository 설정하기
위의 과정에서 생성 된 '/home/kukuta/SVN/sample' 디렉토리가 정상적으로 생성되었다고 가정하고 설명을 시작하도록 하겠습니다.
해당 디렉토리를 살펴 보면 README.txt, conf, dav, db, format, hooks, locks 등의 파일과 디렉토리가 생성되어 있음을 확인 할 수 있습니다.
'sample/conf/svnserv.conf' 파일을 편집기로 열면 모든 텍스트가 주석 처리 되어 있음을 볼 수 있습니다.
2.1 'general' section
접근 권한을 설정하는 섹션 입니다.
[general]이라는 라벨을 사용하여 섹션의 시작을 나타 냅니다.
anon-access(익명사용자), auth-access(실명사용자)에 대한 권한을 설정 할 수 있습니다.

[general]
anon-access = read #인증 되지 않은 유저는 
auth-access = write
password-db = /var/svn/conf/passwd # 파일을 열어 보면 유저들의 패스워드가 적혀 있다.
authz-db = /var/svn/conf/authz # 파일을 열어 보면 유저들의 접속 가능 유저 리스트가 있다

필자는 익명 접근, 실명 접근 모두 저장소에 읽고 쓸수 있는 권한을 부여 했습니다. 만일 익명에게는 읽기 권한만 인증된 사용자에게는 읽기/쓰기를 모두 허용하고 싶다면 read를 적어 주면 됩니다.
계정과 패스워드, 권한을 부여하고 싶다면 password-db와 authz-db에 해당 정보가 기록된 파일 경로를 적어 주면 됩니다.

3. 저장소에 소스 업로드 하기 - import

#svn import localdirectorypath svn://subversion.ip.or.domain/sample/

import를 사용하는 경우에는 디렉토리 이름을 적어 줄것. 파일하나씩 올리는 것은 안됨

4. 저장소에서 소스 다운로드 하기 - checkout

#svn checkout localdirectorypath svn://subversion.ip.or.domain/sample/

5. 로컬 소스를 업데이트 하기 - update
소스를 다운 받았던 디렉토리에서 실행해야만 합니다.

#svn update

6. commit
#svn commit


'도구의발견' 카테고리의 다른 글

vim Undo & Redo  (3) 2008.08.06
개발자를 위한 .vimrc 설정  (0) 2008.07.15
SVN 사용하기  (0) 2008.04.30
memcached  (0) 2008.04.19
msxml 파서 사용하기  (2) 2008.04.03
Dependency Walker 2.2  (0) 2008.03.21
Posted by kukuta
TAG SCM, SVN

댓글을 달아 주세요

cvs 사용법

도구의발견 2007.03.03 01:36

1. 기본적인 사용 방법
 CVS는 대부분의 Linux 배포본에 포함되어 있으므로 Linux를 사용하고 있다면 이미 CVS가 설치 되어 있을 것이다. 만일 CVS 명령이 없다면 http://www.cyclic.com/에서 적당한 파일을 받아 설치하면 된다.

 CVS를 이용하는 모든 과정은 cvs 명령을 통해 이루어진다. cvs 명령의 기본 형식은 다음과 같다.  

 $ cvs [cvs 옵션] 명령 [명령 옵션과 인자]

 명령 부분에는 실제로 cvs에게 지시할 명령이 오게 되며, 각 명령마다 요구하는 인자가 있을 수 있다. 실제로 사용되는 명령의 종류와 기능에 대해서는 새로운 명령이 소개될 때마다 언급하도록 하겠다.  

2. 저장소 초기화
  CVS를 사용하기 위해서 가장 먼저 할 일은 각 프로젝트의 파일들을 저장할 저장소(repository)의 위치를 정하는 것이다. 저장소를 이용할 프로젝트들의 규모를 고려하여 충분한 공간을 가진 디렉토리를 저장소로 쓰도록 한다. 저장소를 /home/CVS에 만들기로 했다면 다음과 같이 초기화할 수 있다.

  # cvs -d /home/CVS init

 여기서 -d는 저장소의 위치를 나타내며, 마지막의 init CVS 명령이다. 물론 이 명령을 사용하기 위해서는 /home에 쓰기 권한을 갖고 있어야 한다. 그러므로 대개의 경우 저장소의 초기화는 root 권한을 가진 시스템 관리자가 하게 된다. 명령이 실행되고 나면 /home CVS란 디렉토리가 생기고, 그 안에는 CVSROOT란 디렉토리가 있을 것이다. CVSROOT 디렉토리는 CVS의 각종 설정 내용을 담고 있는 디렉토리이다. 다시 말하지만 저장소(/home/CVS)의 파일들을 직접 건드리는 것은 절대로 피해야 한다. 이 파일들을 변경하고 싶다면 cvs 명령을 이용해야 한다.

 저장소를 만들었으면 CVS를 이용할 개발자들에게 저장소가 있는 디렉토리에 쓰기 권한을 주어야 한다. 그러기 위해 개발자들을 모두 같은 그룹(: cvs)의 구성원으로 만든다. 이는 시스템별로 존재하는 그룹 관리 도구를 이용하거나 groupadd와 같은 명령으로 cvs라는 그룹을 만들고, 그룹 관리 도구를 쓰거나 /etc/group 파일을 직접 수정하여 개발자들을 그 그룹에 추가하면 된다. 예를 들어 minskim sehkone이라는 사용자를 cvs 그룹에 추가한다면 다음과 같은 줄이 /etc/group에 생길 것이다.

 cvs:*:510:minskim,sehkone

이제 다음 명령으로 디렉토리의 권한을 열어 주면 된다.
# chgrp -R cvs /home/CVS
# chmod -R g+w /home/CVS
이후로는 cvs 그룹에 속한 개발자는 이 저장소를 마음대로 이용할 수 있다.

3. 저장소 이용
 
모든 CVS 명령은 저장소의 위치를 알아야 수행될 수 있다. 앞에서 본 저장소 초기화의 예에서도 init 명령을 사용하면서 -d 옵션으로 저장소의 위치를 알려 주고 있다. CVS의 다른 명령들도 같은 옵션으로 저장소의 위치를 지정할 수 있다. 또 다른 방법은 CVSROOT라는 환경변수의 값으로 저장소의 위치를 주는 것이다. 예를 들어 sh이나 bash를 쓴다면 다음의 내용을 초기화 파일(.bash-profile )에 넣어 놓으면 편리할 것이다.

CVSROOT=/home/CVS
export CVSROOT
csh
이나 tcsh을 쓴다면 다음과 같이 한다.
setenv CVSROOT /home/CVS

 이렇게 설정을 하고 나면 -d 옵션과 저장소의 위치를 매번 줄 필요 없이 바로 cvs 뒤에 원하는 명령을 주면 된다.

 개발자가 CVS 명령을 이용하려 하는 경우 고려해야 할 사항이 하나 더 있다. 개발자가 어떤 방식으로 저장소가 위치한 기계에 연결하는가 하는 것이다. CVS는 다양한 연결 방식을 지원하는데, 여기에서는 주로 사용되는 세 가지 방식에 대해 저장소의 위치를 지정하는 방법을 알아보도록 하자.

 1) 저장소와 개발자가 같은 기계를 쓸 경우
 
앞에서 저장소를 초기화한 것과 같은 경우이다. 같은 기계를 쓰기 때문에 저장소가 있는 디렉토리 이름을 주는 것으로 충분하다. 앞에서 만든 저장소에 CVS 명령을 내리려면 다음과 같이 한다.

 $ cvs -d /home/CVS 명령

  2) 개발자가 rsh을 이용하는 경우
 
개발자가 저장소와 다른 기계를 사용할 경우 일반적으로 쓰이는 방법이다. 여럿이 진행하는 프로젝트는 대부분 개발자들이 자신의 기계에서 작업을 하게 되는데, 이 방식을 이용하면 그러한 경우에도 쉽게 저장소를 공유할 수 있게 해 준다. 이 방법을 쓰려면 먼저 rsh을 사용할 수 있어야 한다. 예를 들어 저장소는 cvs.webdox.co.kr이란 기계에 있고, 개발자의 기계는 birch.webdox.co.kr이라고 하자. 개발자는 cvs.webdox.co.kr minskim이란 계정을 갖고 있고, birch.webdox.co.kr min이란 계정을 갖고 있다. 그러면 다음과 같은 방법으로 rsh을 쓸 수 있는지를 시험해 볼 수 있다.

 rsh -l minskim cvs.webdox.co.kr 'echo $PATH'

 뒤의 명령이 수행된다면 rsh을 쓸 수 있는 것이다. 만일 그렇지 않다면 cvs.webdox.co.kr에 로그인하여 .rhosts란 파일을 만들자. .rhosts에는 다음과 같은 내용이 있어야 한다.

 birch.webdox.co.kr min

 이제 다시 한 번 위의 rsh 명령을 시험해보자. 이번에도 안 된다면 cvs.webdox.co.kr에서 rsh을 통한 접속을 막아 놓았을 가능성이 크다. 이는 cvs.webdox.co.kr의 관리자에게 문의하여 해결하여야 한다. rsh을 쓸 수 있다면 CVS 명령을 다음과 같이 사용하면 된다.

 $ cvs -d :ext:minskim@cvs.webdox.co.kr:/home/CVS 명령

 만일 rsh과 같은 방식으로 동작하는 다른 명령이 있다면 그 명령을 사용할 수도 있다. 대표적인 것이 ssh이다. 특히 누군가 네트웍을 통해 전달되는 계정의 암호를 가로챌 위험이 있다면 rsh 대신 ssh을 사용하여 그 위험을 줄일 수 있다. 그러기 위해서는 CVS_RSH라는 환경변수를 ssh로 선언해주면 된다. 이 경우 저장소가 있는 기계에서는 .rhosts 파일을 만들 필요는 없는 대신 sshd 등이 돌고 있어야 한다.

 3) 암호 인증 방식 이용
 
프로젝트에 직접 이용하지 않더라도 CVS가 필요한 경우는 CVS를 사용하는 여러 공개 프로젝트들의 최신 프로그램들을 받아 오는 경우일 것이다. 개발이 빨리 진행되는 프로젝트들은 대부분 CVS를 통해 프로그램을 받아 갈 수 있도록 하고 있다. 이런 프로젝트들의 홈페이지에서는 'CVSROOT ...로 설정하십시오'라는 문구를 볼 수 있는데, 이것이 바로 저장소의 위치이다. Mozilla의 최신 source를 받아 보고 싶다면 다음과 같이 하면 된다.

 $ cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot login

 그러면 암호를 물어오는데 암호는 anonymous이다. 일단 로그인을 하고 나면 인증 정보가 .cvspass란 파일에 저장이 되며, 이후로는 암호 없이 CVS 명령을 이용할 수 있다. 방법은 다음과 같다.

 $ cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot 명령

4. 프로젝트 초기화
 
사용 가능한 CVS 저장소가 있고, 어떻게 저장소를 이용하는지 알고 있다면 프로젝트를 시작할 모든 준비가 끝난 셈이다. 더군다나 기존의 프로젝트에 CVS를 도입하려는 경우라면 이미 디렉토리와 파일들이 있을테니 이를 저장소에 저장하는 방법만 배우면 된다. 하지만 처음 시작하는 프로젝트를 CVS로 관리하려 한다면 먼저 디렉토리 구조를 잘 설계해야 한다. 물론 언제라도 CVS를 이용해서 파일의 위치를 옮기고 새로운 디렉토리를 만드는 등의 일은 가능하다. 하지만 처음부터 디렉토리 구조와 각 디렉토리에 들어갈 파일들을 잘 정해 놓는 것은 전체 프로젝트 관리에도 도움을 주므로 되도록이면 나중에 파일이나 디렉토리의 위치 변경이 생기지 않도록 설계를 하고 프로젝트를 시작하도록 하자.

 먼저 할 일은 프로젝트의 이름을 정하는 것이다. 이 이름은 저장소에서 이 프로젝트 관련 파일들을 저장하는 디렉토리의 이름으로 쓰인다. 여기에서는 myprj란 이름으로 프로젝트를 만들어 보기로 하겠다. 이후에 나올 모든 예는 환경변수 CVSROOT가 제대로 설정되어 있다고 가정한다. CVSROOT를 어떻게 설정해야 하는가에 대해서는 앞 절의 내용을 참고하기 바란다.
 myprj
란 디렉토리가 다음과 같이 되어 있다고 하자.

 $ cd myprj
 $ ls
 Hello.java     README

 저장소에 새 프로젝트를 만들고 이 두 파일을 저장하기 위해서는 import 명령을 사용한다. import 명령의 사용법은 다음과 같다.

 $ cvs import -m "메시지" 프로젝트이름 vender_tag release_tag

 '메시지'는 프로젝트를 시작하면서 저장소에 기록하고 싶은 내용을 적어주면 된다. CVS는 파일을 저장할 때마다 메시지를 적도록 하고 있다. 이 내용을 원하는 때에 다시 볼 수 있으므로 개발자가 어떤 작업을 했는지를 적어 놓으면 다른 개발자들이 파일의 변경 내용, 작업 진척 상황등을 파악하는데에 도움을 줄 수 있다. 뒤의 두 태그는 지금 단계에서는 별 의미가 없으므로 적당한 말을 써 주면 된다. myprj란 프로젝트를 저장소에 만들기 위해서는 다음 명령을 사용한다.

 $ cvs import -m "프로젝트 시작" myprj webdox start
 N myprj/Hello.java
 N myprj/README
 No conflicts created by this import

 앞에 말했듯이 뒤의 두 단어는 별 의미가 없으므로 크게 신경쓰지 말기 바란다. 이 명령을 실행하면 CVS는 저장소에 myprj란 디렉토리를 만들고, 거기에 README Hello.java를 저장한다. 이 외에도 옵션으로 준 메시지와 각 파일의 부가적인 정보를 기록하게 된다. 출력되는 메시지를 보면 각 파일 이름 앞에 N이란 글자가 있는 것을 알 수 있다. CVS는 특정 명령 수행시에 파일별로 수행 결과를 나타낸다. N은 새로운 파일이 추가된 것을 의미한다. 이후의 예에서 다른 경우들도 보게 될 것이다. 마지막 줄에서 conflict란 현재 디렉토리에 있는 파일을 저장소에 저장하게 되면 어떤 이유로 이미 저장소에 있는 파일과 충돌을 일으키는 경우를 뜻한다. 다른 사람이 작업해서 저장소에 저장해 놓은 것을 덮어쓰려 한다거나 하는 경우인데, 자세한 것은 뒤에서 conflict가 발생하는 경우를 예로 들어 설명하겠다. 여기에서는 저장소에 아무 파일도 없으므로 충돌(conflict)이 생기지 않는 것이 당연하다.

 import 명령으로 프로젝트를 초기화하고 나면 더 이상 현재 디렉토리에 갖고 있는 것들을 사용하면 안 된다. 현재 디렉토리에는 CVS에 관련된 정보가 아무 것도 없기 때문이다. 대신 저장소에 모든 내용이 들어 있으므로 myprj 디렉토리 자체를 완전히 지워버려도 괜찮다. 다음 절에서 소개할 명령들을 이용해서 언제라도 다시 불러올 수가 있다. 이상으로 프로젝트 초기화는 모두 끝난 것이며, 이후로는 각 개발자들이 CVS를 이용하여 프로젝트를 진행시키는 일만이 남아 있다.

5. 프로젝트 진행

 1) 작업 공간 생성 (checkout)
 
작업을 시작하기 위해서는 파일을 마음대로 변경하고 저장하여 테스트해 볼 수 있는 작업 공간이 필요하다. 저장소에 있는 파일들을 불러와 나만의 작업 공간을 만드는 명령이 checkout이다. 앞에서 만든 myprj checkout 명령으로 불러 오자.

 $ cvs checkout myprj
 cvs checkout: Updating myprj
 U myprj/Hello.java
 U myprj/README

 checkout 대신 co만 써 주어도 된다. 앞에 붙은 U는 파일이 갱신(update)되었음을 의미한다. 명령을 수행하고 나면 현재 디렉토리에 myprj란 디렉토리가 생긴다. 이 디렉토리가 바로 작업 공간이다. 이 안에서 필요에 따라 파일들을 수정하고, 이를 다시 저장소로 저장하면 되는 것이다. 그러면 디렉토리 안에는 어떤 파일들이 들어 있을까?

 $ cd myprj
 $ ls
 CVS    Hello.java    README

 프로젝트를 초기화할 때 있던 파일들이 그대로 들어 있는 것을 볼 수 있다. 하지만 하나 달라진 것이 있다. CVS란 디렉토리가 바로 그것이다. 바로 이 디렉토리에 CVS가 파일들을 관리하는데에 필요한 정보가 기록된다. 예를 들면 각 파일들의 버젼, 최종 수정 시각, 저장소의 위치 등이 이에 속한다. 앞으로 여러 CVS 명령들을 사용하게 되는데, 그때마다 CVS는 이 디렉토리의 정보를 참고하여 각 명령을 수행한다. 하지만 개발자가 이 디렉토리의 내용에 신경쓸 필요는 전혀 없다. 관심이 있다면 살펴보는 것은 좋지만, 내용을 임의로 변경한다거나 해서는 안 된다.

 2) 작업 내용의 저장 (commit)
 
만들어진 작업 공간에서 작업을 시작해보자. Hello.java의 내용이 다음과 같다고 하자.

  public class Hello {
    public static void main(String args[]) {
    }
  }

 여기에 인사말을 출력하는 부분을 추가해보자. 아무 편집기로나 파일을 열어 작업하면 된다. CVS를 사용한다고 해도 특별한 에디터나 통합 개발 환경을 필요로 하지는 않는다. Hello.java '안녕하세요?'라고 출력하는 문장을 추가했다고 하자.

  public class Hello {
    public static void main(String args[]) {
       System.out.println("
안녕하세요?");
    }
  }

 컴파일을 해서 실행을 해 보고 예상대로 실행된다면 이제 작업 내용을 저장소에 저장해야 한다. 그래야 다른 개발자들도 인사말이 추가되었다는 것을 알게 될 것이다. 파일의 변동 사항을 저장소에 저장하는 명령은 commit이다.

 $ cvs commit -m "인사말 추가" Hello.java
 Checking in Hello.java;
 /home/CVS/myprj/Hello.java,v  <--  Hello.java
 new revision: 1.2; previous revision: 1.1
 done

 어떤 명령인지 쉽게 이해할 수 있을 것이다. -m은 앞의 예와 마찬가지로 메시지를 의미한다. 이 명령으로 Hello.java '인사말 추가'란 메시지와 함께 저장소에 저장된다. 그렇다고 이전의 Hello.java가 없어지는 것은 아니다. CVS는 각 버젼의 변경 내용을 파악하여 언제라도 개발자가 원하는 버젼을 꺼내 줄 수 있도록 파일들을 저장한다. 출력 결과를 보면 원래 있던 Hello.java 1.1이고, 새로 저장된 Hello.java 1.2임을 알 수 있다. 이 번호는 CVS가 자동으로 붙이는 것이며 변경 사항이 저장될 때마다 올라가므로 각 파일마다 다를 수 있다. 나중에 특정 버젼이 필요하다면 이 번호를 이용해서 불러 오면 된다.

 맨 끝의 파일 이름은 생략할 수 있다. 파일 이름을 주지 않으면 CVS가 변경된 파일을 모두 찾아 저장소에 저장한다. 이때 저장되는 모든 파일에는 같은 메시지가 붙게 된다. 하지만 파일마다 다른 메시지를 붙이고 싶다거나 특정 파일의 변경 내용만을 저장하고 싶다면 위의 예처럼 파일 이름을 명시해 주어야 한다.

 commit을 할 때 주의할 점은 반드시 제대로 동작하는가를 확인하고 commit을 해야 한다는 것이다. 일단 commit을 하면 다른 개발자들도 나의 작업 결과를 받아갈 수 있다. 그러므로 내가 제대로 컴파일조차 되지 않는 파일을 commit으로 저장소에 저장하면 이 파일을 받아간 다른 개발자들도 컴파일이 안 되는 결과를 가져올 것이다. 특히나 여러 파일을 변경하고 일부 파일만을 commit하는 경우라면 더욱 주의해야 한다. 공동 작업을 하는 경우라면 이렇게 자신의 부주의로 다른 개발자들에게 피해를 입히는 일은 절대로 삼가야 한다. 대개의 경우 변경 내용 전체가 서로 관련이 있는 경우가 많으므로 특정한 인자를 주지 않고 commit 명령을 사용하여 작업 공간 전체의 변경 내용이 한꺼번에 저장소에 저장되도록 하는 것이 좋다.

 3) 저장소의 파일 받아오기 (update)
 
공동 작업에서 자신의 작업 결과를 저장하는 일 못지 않게 중요한 일은 다른 사람의 작업 결과를 받아오는 일이다. 자신이 작업한 내용을 모두 저장한 상태라면 작업 디렉토리를 지워버리고 checkout 명령으로 새로운 작업 공간을 만드는 것도 한 방법이 될 것이다. 하지만 이는 모든 파일을 새로 받아오므로 저장소와의 연결이 느릴 경우에는 상당한 시간을 기다려야 할 수도 있다. 보다 좋은 방법은 update 명령을 사용하는 것이다. 작업중이던 디렉토리에서 이 명령을 쓰면 CVS에 저장된 파일들 중 내가 받아온 이후로 변경된 것들만을 다시 받아 온다.

 $ cvs update
 cvs update: Updating .

 현재 작업 공간에 있는 파일들이 저장소에 있는 파일과 모두 동일하면 위와 같이 별다른 출력 없이 끝날 것이다. 그렇다면 작업 공간에 있는 파일을 수정하고 commit을 하지 않은 상태라면 어떤 결과가 나오는지 보기 위해 Hello.java를 다음과 같이 수정해보자.

 public class Hello {
    public static void main(String args[]) {
        System.out.println("
안녕하세요?");
        System.out.println("
반갑습니다.");
    }
 }

 원래의 파일에 "반갑습니다."를 출력하는 문장을 추가하였다. 이제 update 명령을 실행하면 다음과 같이 나올 것이다.

 $ cvs update
 cvs update: Updating .
 M Hello.java

 파일 이름 앞에 있는 영문자(이 경우는 M)가 각 파일별 상태를 알려준다. M은 파일이 변경된(modified) 상태임을 의미한다. , 파일의 내용이 원래 저장소에 있는 것과 달라졌을 때 M을 써서 표시하게 된다.

 저장소의 파일과 작업 공간의 파일이 달라질 수 있는 또 다른 경우는 다른 사람이 파일을 변경하여 commit 명령으로 저장소에 저장한 경우이다. 예를 들어 원래의 README 파일이 다음과 같았다고 하자.

 $ cat README
 
이 파일은 매우 중요한 내용을 담고 있습니다.

 그런데 다른 개발자가 README 파일을 다음과 같이 변경하여 저장소에 저장하였다.

 $ cat README
 
이 파일은 매우 중요한 내용을 담고 있습니다.
 1999
12 11
 $ cvs commit -m "
날짜 추가" README
 Checking in README;
 /home/CVS/myprj/README,v  <--  README
 new revision: 1.2; previous revision: 1.1
 done

 이제 내가 update를 하면 다음과 같은 결과를 볼 수 있다.

 $ cat README
 
이 파일은 매우 중요한 내용을 담고 있습니다.
 $ cvs update
 cvs update: Updating .
 M Hello.java
 U README

 README 앞에 붙은 U는 파일이 갱신된(updated) 것을 의미한다. 이제 내 작업 공간의 README가 저장소에 저장된 내용과 같게 갱신된 것을 볼 수 있다.

 $ cat README
 
이 파일은 매우 중요한 내용을 담고 있습니다.
 1999
12 11

 그렇다면 이 두 경우가 혼합된 경우는 어떤 일이 발생할까? , 다른 개발자가 수정하여 저장소에 저장한 파일을 나 역시 수정한 후 update를 하는 경우이다. 다른 개발자가 Hello.java를 다음과 같이 main 함수 앞에 주석을 한 줄 추가하여 commit을 했다고 생각해보자.

 $ cat Hello.java
 public class Hello {
    // main
함수
    public static void main(String args[]) {
        System.out.println("
안녕하세요?");
    }
 }
 $ cvs commit -m "
주석 추가" Hello.java
 Checking in Hello.java;
 /home/CVS/myprj/Hello.java,v  <--  Hello.java
 new revision: 1.3; previous revision: 1.2
 done

 그런 다음 내가 update를 하면 다음과 같이 된다.
 $ cat Hello.java
 public class Hello {
    public static void main(String args[]) {
        System.out.println("
안녕하세요?");
        System.out.println("
반갑습니다.");
    }
 }
 $ cvs update
 cvs update: Updating .
 RCS file: /home/CVS/myprj/Hello.java,v
 retrieving revision 1.2
 retrieving revision 1.3
 Merging differences between 1.2 and 1.3 into Hello.java
 M Hello.java

 여기서 update 명령은 현재 디렉토리의 Hello.java 1.2에서 수정된 상태이고, 저장소에 있는 Hello.java 1.3이기 때문에 저장소의 내용을 가지고 1.2 1.3의 차이를 파악하게 된다. 그 차이가 한 줄이 추가된 것임을 발견하고 나면 그 차이를 현재 디렉토리의 Hello.java에 반영한다. 하지만 Hello.java에는 "반갑습니다."를 출력하는 줄도 들어 있기 때문에 여전히 저장소에 있는 파일과는 다른 상태이다. 따라서 저장소에 있는 내용에서 변경되었다는 의미의 M을 출력하는 것이다. 실제로 Hello.java의 내용을 보면 다음과 같이 바뀐 것을 볼 수 있다.

 $ cat Hello.java
 public class Hello {
   // main
함수
   public static void main(String args[]) {
      System.out.println("
안녕하세요?");
      System.out.println("
반갑습니다.");
   }
 }

 다른 개발자가 추가한 주석이 들어 있으면서 내가 추가한 줄도 그대로 있음을 볼 수 있다. 이것이 CVS의 강력한 장점이다. , 서로 다른 두 개발자가 같은 파일을 수정하였는데도, 서로의 작업을 하나로 합쳐주는 것이다. 한가지 주의할 점은, 만일 update를 수행할 때 Hello.java를 에디터에서 불러 작업 중이었다면, 계속 에디터로 작업을 한 후 저장할 때 update에 의해 변경된 내용을 덮어 쓸 수가 있다는 것이다. 대부분의 에디터는 작업하고 있는 파일이 다른 프로그램에 의해 변경되면 이 사실을 사용자에게 알리고, 변경된 파일을 다시 불러올 수 있도록 하지만, 간혹 그렇지 못한 에디터도 있을 수 있으므로 조심하기 바란다.

 4) 충돌의 해결
 
비록 CVS가 두 개발자의 작업 내용을 합쳐 주기는 하지만 여기에도 한계는 있다. 두 개발자가 같은 부분을 수정한다면 CVS는 누구의 변경 내용을 택해야 하는지 알 도리가 없다. 이런 경우를 충돌(conflict)라 하며, CVS는 이 사실을 개발자에게 알려 개발자가 적절한 조치를 취할 수 있도록 한다.

 위의 예에서 다른 개발자가 작업을 계속하여 "환영합니다."를 출력하도록 만들고, 이를 저장소에 저장했다고 하자. 그러면 저장소에는 다음과 같은 내용이 들어 있을 것이다.

 public class Hello {
   // main
함수
   public static void main(String args[]) {
      System.out.println("
안녕하세요?");
      System.out.println("
환영합니다.");
   }
 }

 이 때 내가 update를 하면 충돌이 발생한다.

 $ cvs update
 cvs update: Updating .
 RCS file: /home/CVS/myprj/Hello.java,v
 retrieving revision 1.3
 retrieving revision 1.4
 Merging differences between 1.3 and 1.4 into Hello.java
 rcsmerge: warning: conflicts during merge
 cvs update: conflicts found in Hello.java
 C Hello.java

 현재 디렉토리의 Hello.java 1.3에서 변경된 상태("반갑습니다." 출력 추가)이다. 저장소에 저장되어 있는 것은 1.4이므로 CVS는 저장소에 있는 1.3 1.4의 차이를 살핀다. 둘의 차이는 다른 개발자에 의해 "환영합니다."를 출력하는 줄이 추가된 것이다. 이를 현재디렉토리의 Hello.java에 추가하려고 시도하지만, 그 위치에 이미 다른 내용("반갑습니다." 출력)이 들어가 있음을 알게 된다. 결국 CVS는 충돌(C로 표시)이 생겼음을 알리고 수행을 마친다. Hello.java의 내용을 보면 어디에서 어떤 충돌이 발생했는지 CVS가 표시해 놓을 것을 발견할 수 있다.

 $ cat Hello.java
 public class Hello {
   // main
함수
   public static void main(String args[]) {
      System.out.println("
안녕하세요?");
 <<<<<<< Hello.java
      System.out.println("
반갑습니다.");
 =======
      System.out.println("
환영합니다.");
 >>>>>>> 1.4
   }
 }

<<<<<<< >>>>>>> 사이가 충돌이 일어난 부분이다. 그 부분은 다시 두 부분으로 나뉘는데, ======= 이전까지가 현재 디렉토리에 있는 파일의 내용이고, 그 이후가 저장소에 있는 파일의 내용이다. 개발자는 이걸 보고 어느 한 쪽을 없애거나 두 내용을 적절히 합친 후 다시 commit을 해 주면 된다. 이 경우 "반갑습니다."가 더 마음에 들어 "환영합니다."를 삭제하기로 했다면 다음과 같이 고치고 commit을 한다.

 $ cat Hello.java
 public class Hello {
   // main
함수
   public static void main(String args[]) {
      System.out.println("
안녕하세요?");
      System.out.println("
반갑습니다.");
   }
 }
 $ cvs commit -m "
인사말 변경" Hello.java
 Checking in Hello.java;
 /home/CVS/myprj/Hello.java,v  <--  Hello.java
 new revision: 1.5; previous revision: 1.4
 done

 하지만 다른 개발자가 수정한 내용을 그대로 놔 두고 내가 고친 부분을 없애기로 했다면 따로 commit을 할 필요가 없다. 이미 저장소에 그 내용이 들어 있기 때문이다.

 충돌은 commit 시에도 발생할 수 있다. 앞의 예에서 다른 개발자가 "환영합니다." 출력 문장을 추가하여 commit을 한 후, 내가 update 대신 commit을 하려 했다면, CVS는 다음과 같이 충돌이 발생했음을 알려 줄 것이다.

 $ cvs commit -m "반갑습니다 추가" Hello.java
 cvs commit: Up-to-date check failed for `Hello.java'
 cvs [commit aborted]: correct above errors first!

 이런 메시지를 보게 되면 update 명령으로 어디에서 충돌이 발생했는지를 확인하면 된다. 그 결과와 수정 방법은 앞에서 나온 것과 동일하다.

 5) 파일의 추가/삭제 (add/delete)
 
지금까지는 저장소에 있는 파일을 수정하고, 그 결과를 다시 저장하는 방법을 알아보았다. 하지만 작업을 하다 보면 새로운 파일을 만들거나 기존의 파일을 지워야 할 경우가 생긴다. 이런 경우에 사용하는 명령이 add delete이다. 사용 방법은 매우 간단하다. Test.java란 파일을 새로 만들려면 먼저 현재 디렉토리에 Test.java를 생성한 후 다음과 같이 하면 된다.

 $ cvs add Test.java
 cvs add: scheduling file `Test.java' for addition
 cvs add: use 'cvs commit' to add this file permanently

 메시지에서 알 수 있듯이 add 명령만으로는 저장소에 Test.java가 생기지 않는다. 저장소를 변경하는 것은 commit 명령뿐이다. add 명령은 단지 commit 명령시에 Test.java를 추가해야 한다는 것을 기록해 놓을 뿐이다. 이 사실은 update로 확인해 볼 수도 있다.

 $ cvs update
 cvs update: Updating .
 A Test.java

 앞의 A는 추가될(added) 파일임을 의미한다. 그러므로 Test.java는 나중에 작업 내용 전체를 commit할 때 저장소에 추가될 것이다. 아니면 미리 Test.java를 인자로 commit을 하여 바로 추가되도록 할 수도 있다.

 $ cvs commit -m "새 파일" Test.java
 RCS file: /home/CVS/myprj/Test.java,v
 done
 Checking in Test.java;
 /home/CVS/myprj/Test.java,v  <--  Test.java
 initial revision: 1.1
 done

 추가된 파일은 다른 개발자가 update를 할 때 그 개발자의 작업 공간에도 생겨나며, 파일 내용이 갱신되는 것과 마찬가지로 U를 써서 표시한다.

 $ cvs update
 cvs update: Updating .
 U Test.java

파일을 지우는 것도 마찬가지이다. Test.java를 지우려면 다음과 같이 한다.

 $ rm Test.java
 $ cvs delete Test.java
 cvs remove: scheduling `Test.java' for removal
 cvs remove: use 'cvs commit' to remove this file permanently

 delete 명령을 사용하기 전에 반드시 먼저 파일을 작업 공간에서 삭제하여야 한다. 이제 commit 명령을 사용하면 Test.java는 저장소에서 삭제될 것이다. 이것도 update로 확인해 본다면 다음과 이 나올 것이다.

 $ cvs update
 cvs update: Updating .
 R Test.java

 R은 삭제될(removed) 파일임을 나타낸다. 이제 commit으로 완전히 삭제해 보자.

 $ cvs commmit -m "삭제" Test.java
 Removing Test.java;
 /home/CVS/myprj/Test.java,v  <--  Test.java
 new revision: delete; previous revision: 1.1
 done

 이렇게 삭제된 파일은 이후로 다른 개발자가 update를 하게 되면 다음과 같은 메시지를 출력하면서 그 개발자의 작업 디렉토리에서도 삭제된다.

 $ cvs update
 cvs update: Updating .
 cvs update: warning: Test.java is not (any longer) pertinent

 6) 작업 기록 열람 (log)
그 동안의 예에서 본 바와 같이 CVS는 작업 내용을 저장소에 저장할 때마다 메시지를 적도록 하고 있다. 이 내용은 저장소에 함께 저장되어 log 명령을 이용하면 언제라도 꺼내 볼 수 있다. Hello.java를 예로 들어 보자.

$ cvs log Hello.java

원문 보기 : http://kin.naver.com/db/detail.php?d1id=1&dir_id=10103&docid

'도구의발견' 카테고리의 다른 글

gcc 라이브러리 만들기와 사용  (0) 2007.04.24
gcc의 실행과 옵션  (0) 2007.04.24
cvs 사용법  (0) 2007.03.03
vim editor - foldmethod  (1) 2006.12.12
awk  (0) 2006.12.12
ssh login without password  (0) 2006.12.11
Posted by kukuta
TAG cvs, SCM

댓글을 달아 주세요

CVS Command Line Reference


일반적인 CVS command :

% cvs general-options command-name command-specific-options filename

Help

cvs --help-commands
모든 명령어 보여주기
cvs --help-options
모든 command에 적용되는 'global' 옵션들을 보여준다. 이 기능중에서 가장 유용한 것은 아무것도 실행하지 않고 디스크의 파일을 변경하는  -n 이다. 하지만 무슨일을 할것인지는 보여준다.
cvs -H command
지정된 커맨드의 help를 보여준다.


Task Reference

Action How to do it.
Repository와 로컬파일들의 동기화를 시킨다. 아직 check in 되지 않은 파일중에서 무엇이 수정되었는지 알수 있다.
cvs update
(sample)
지정된 파일의 revision history를 보여준다.
cvs log filename
(sample)
한 revision의 comment를 보연 준다.
cvs log -r1.5 filename
이전 버전의 파일과 현재 파일과의 차이 점을 보여준다.
cvs diff filename
이미 체크인 된 두 버전의 파일간의 차이를 보여준다.
cvs diff -r1.4 -r1.7 filename
(sample)
누가 파일을 수정했는지 보여준다.
cvs annotate filename
(sample)


누가 코드를 잘못짜서 커밋했는지 찾을때 유용하다.

Repository에 새로운 파일을 추가한다. Create the file
cvs add filename
cvs commit -m "Initial Revision" filename
Repository에 새로운 바이너리 파일 추가 Create the file
cvs add -kb filename
cvs commit -m "Initial Revision" filename

A "binary file" won't have CVS keyword expansion performed on it.

프로젝트에 새로운 디렉토리 추가 하기 cd to the directory's parent cvs add directoryname
파일의 변경사항을 Repository에 반영
cvs commit -m "check-in comment" filename
If your check-in comment is more than one line, leave off the the -m option and use the editor that is brought up.
가장 최근에 check in 된 버전으로 rollback Remove the file
cvs update filename
모든 디렉토리 트리를 새로운 프로젝트에 추가 cdto the project directory
cvs import -m "project name" directory "ArsDigita" "initial-development"

Note that this does not change directory into a CVS-controlled tree. You'll need to remove the tree and check it out.

프로젝트의 모든 것들을 check out
cvs checkout project-name
Label a tree for concurrent development cd to the parent directory of your tree
cvs tag -R -b labelname

This will use the currently-checked-out versions of the files as they exist in your directory tree.

The -b argument means that this tag is a "branch" tag, meaning that someone can check out a new tree based on this tag and do development.

If you omit the -b, the label will be a "sticky" tag, meaning that someone won't be able to check in new changes under that label. See the notes on Labeling and Branching

label에 따라 check out
cvs checkout -r labelname projectname
If labelname was created as a "branch" tag, then you can check in changes without affecting anyone using the development tip.

Otherwise files are considered "sticky" and changes cannot be checked in.

파일이 add 되고 난후 바이너리 파일로 처리될 수있도록 변경 cvs admin -kb filename

A "binary file" won't have CVS keyword expansion performed on it.



'도구의발견' 카테고리의 다른 글

gcc의 실행과 옵션  (0) 2007.04.24
cvs 사용법  (0) 2007.03.03
vim editor - foldmethod  (1) 2006.12.12
awk  (0) 2006.12.12
ssh login without password  (0) 2006.12.11
CVS Command Line Reference  (0) 2006.12.11
Posted by kukuta
TAG cvs, SCM

댓글을 달아 주세요