tail head cat sleep
QR code linking to this page

Man page  — CVS

명칭

cvs - 콘커렌트(common agenda) 버젼 시스템

내용

주기

이 메뉴얼 페이지는 cvs 의 기능의 통계입니다만, 보다 상세한 문서에 관해서는 (이 메뉴얼 페이지의 관련 항목의 마디에 기술되어 있도록(듯이)) Cederqvist 저의 메뉴얼을 참조해 주세요.

서식

cvs [ cvs_options ]
  cvs_command [ command_options ] [ command_args ]

해설

CVS 는 버젼 제어 시스템이며, RCS 나 SCCS 와 같이, 파일 (통상은 원시 코드)의 낡은 버젼의 보관 유지와 누가 몇시 왜 변경을 가했는지등의 기록의 보관 유지를 가능하게 합니다. 같은 시스템과는 달라, CVS 는 1시에 1 파일이나 1 디렉토리만을 조작 대상으로 하는 것이 아니라, 버젼 관리된 파일을 가지는 디렉토리 집합으로부터 되는 계층을 조작 대상으로 합니다. CVS 는, 릴리스 관리를 도와 또 복수의 저자에 의한 병행적인 원시 파일 편집을 돕습니다. CVS 는, 여러가지 조작을 유효하게 하거나 기록하거나 제어하거나 하기 위해서 방아쇠를 사용 가능하고, 광역 네트워크로 잘 동작합니다.

cvs (은)는 마스터 소스의 단일의 카피를 보관 유지합니다. 이 카피는 소스의``리포지터리(repository)''로 불립니다. 이것은, 이전의 소프트웨어 릴리스를 언제라도 상징적인 리버젼 태그인가, 또는 과거의 일자의 어느 쪽인가에 기초를 두어 꺼낼 수 있도록(듯이)하기 위한 모든 정보를 포함합니다.

불가결한 명령

cvs (은)는 버라이어티가 풍부한 명령을 제공합니다 (서식 설명에 있어서의 cvs_command). 또 분산환경에서의 다양한 소스 관리 요구를 채우기 위해서(때문에), 이러한 명령이 많게는 얼마든지의 옵션이 준비되어 있습니다. 그렇지만, cvs편리하게일을하기위해서각각의세부에건너마스터한다 필요는 없습니다. 실제, 소스 리포지터리(repository)를 사용하려면 (그리고 거기에 공헌하기) 5 개(살)의 명령로 충분합니다.
cvs checkout modules. . .
  대부분의 cvs 에서의 작업을 위해서(때문에) 필요한 준비: modules (이름을 붙인 소스의 집합. 여기에는 소스 리포지터리(repository)에의 상대 패스를 사용할 수도 있습니다)의 소스의 사적인 카피를 작성합니다. 타인의 작업에 방해받는 일 없이 이 카피로 작업할 수가 있습니다. 적어도 1 레벨의 서브 디렉토리가 반드시 작성됩니다.
cvs update
  다른 개발자가 리포지터리(repository)의 출처에 간 변경을 당신의 카피에 수중에 넣고 싶다고 생각했을 때에, 당신의 사적인 소스의 디렉토리의 중에서 이 명령을 실행해 주세요.
cvs add file. . .
  당신의 작업 디렉토리의 cvs 의 레코드에 새로운 파일을 실으려면 , 이 명령을 사용합니다. 그 파일은 다음에 당신이 `cvs commit'를 주의: 새로운 소스를 소스 리포지터리(repository)에 등록하려면 `cvs import' 명령을 사용해 주세요. `cvs add' (은)는 벌써 체크아웃 되고 있는 모듈에 새로운 파일을 추가할 경우에 마셔 사용합니다.
cvs remove file. . .
  (지정하는 파일을 지운 후에) 리포지터리(repository)로부터 파일을 지우고 싶은 것을 선언하는 경우에, 이 명령을 사용합니다. `cvs commit'를
cvs commit file. . .
  당신의 변경을 소스 리포지터리(repository)에 수중에 넣는 것으로, 다른 개발자에게 변경 결과를 ``공개''하고 싶을 때에, 이 명령을 사용합니다.

옵션

cvs 의 명령행에는 cvs_options포함할수가있어 이것은 cvs 프로그램 전체에 적용됩니다. 하나의 cvs_command소스리포지터리(repository)에의특정의동작을 지정합니다. 그리고 cvs_command 의 동작을 완전하게 지정하기 위해서 command_options (와)과 command_arguments (을)를 포함할 수가 있습니다.

경고: cvs_command옵션의상대적인위치관계에정확함을 기하지 않으면 안됩니다. 왜냐하면 같은 옵션이 cvs_options 의 위치 ( cvs 명령의 좌측)과 command_options 의 위치 ( cvs 명령의 우측)의 머지않아에 놓여질까로 다른 의미를 가질 가능성이 있기 때문에입니다.

cvs_command생략있는상황이2개만있습니다: `cvs -H' 또는 `cvs --help' (은)는 이용 가능한 명령의 일람을 꺼냅니다, 그리고 `cvs -v' 또는 `cvs --version' (은)는 cvs 그것 자신의 버젼 정보를 표시합니다.

CVS OPTIONS

릴리스 1.6 현재, cvs (은)는, 짧은 옵션과 함께 GNU 스타일의 긴 옵션도 서포트합니다. 현재는 아직 2, 3 의 긴 옵션 밖에 서포트되지 않고, 그것들은 같은 의미를 가지는 짧은 옵션의 뒤로 꺾쇠 괄호로 둘러싸 나타나고 있습니다.

이하의 옵션은 cvs 프로그램의 전체적인 제어에 사용합니다:
-H [ --help ]
  지정되었다 cvs_command 의 용법을 표시합니다 (가, 명령의 실행은 실시하지 않습니다). 커멘드명을 지정하지 않으면 `cvs -H' (은)는 이용 가능한 전명령의 요약을 표시합니다.
-Q (은)는 명령을 실로 과묵하게 합니다. 명령은 심각한 문제에 대한 보고 출력을 실시합니다.
-q (은)는 명령을 조금 조용하게 합니다. 서브 디렉토리를 재귀적으로 이동할 때의 보고와 같은 통지적인 메세지가 억제됩니다.
-b bindir
  RCS 프로그램이 놓여져 있는 디렉토리로서 bindir (을)를 사용합니다 (CVS 1.9 및 그 이전). 환경 변수 RCSBIN 의 설정보다 우선됩니다. 이것은 절대 패스명으로 지정하지 않으면 안됩니다.
-d CVS_root_directory
  마스터가 된다 소스 리포지터리(repository)의 루트 디렉토리에의 패스명으로서 CVS_root_directory (을)를 사용합니다. 환경 변수 CVSROOT 의 설정보다 우선됩니다. 이것은 절대 패스로 지정하지 않으면 안됩니다.
-e editor
  로그 정보의 입력에 대해 에디터로서 editor (을)를 사용합니다. 환경 변수 CVSEDITOR , VISUAL , EDITOR 의 설정보다 우선됩니다.
-f cvs 스타트 업 파일 (~/.cvsrc)을 읽어들이지 않습니다.
-l 명령 역사에 cvs_command 의 로그를 취하지 않습니다 (그러나 실행은 합니다). 명령 역사에 관한 정보에 대해서는 history 명령의 설명을 참조해 주세요.
-n 어떠한 파일도 변경하지 않습니다. cvs_command실행하려고합니다만, 경과 보고만을 실시합니다. 파일에의 삭제, 갱신이나 merge의 모두 실시하지않고, 새로운 파일도 작성하지 않습니다.
-t 프로그램의 실행을 트레이스 합니다. cvs 의 동작의 스텝을 나타내는 메세지를 표시합니다. 서투른 명령의 영향의 가능성을 조사하는데 -n (와)과의 편성으로 특히 유용합니다.
-r 새로운 작업 파일을 읽어내기 전용으로 합니다. 환경 변수 CVSREAD 하지만 세트 되고 있는 경우와 같은 효과를 가집니다.
-R 읽어내기 전용 리포지터리(repository) 모드를 온으로 합니다. 이것에 의해, anoncvs 서버상등의 읽어내기 전용 리포지터리(repository)로부터의 체크아웃이나, CDROM 상의 리포지터리(repository)로부터의 체크아웃이 가능하게 됩니다. 환경 변수 CVSREADONLYFS 하지만 세트 되고 있는 경우와 같은 효과를 가집니다. 또, -R (을)를 사용하면(자) NFS 를 개입시킨 체크아웃이 고속으로 됩니다.
-v [ --version ]
  cvs 의 버젼과 저작권 정보를 표시합니다.
-w 새로운 작업 파일을 읽고 쓰기 가능하게 합니다 (디폴트입니다). 환경 변수 CVSREAD 하지만 세트 되고 있어도 무시합니다.
-g 강제적으로, 그룹 기입 권한을 작업 파일에 부가합니다. 전형적으로는, 단일의 체크아웃 된 소스 트리를 복수 유저로 공유하는 경우에 이 옵션을 사용해, 각 유저가 보다 안전한 umask 로 쉘을 사용할 수 있도록(듯이) 합니다. 이 기능을 사용하기 위해서는, 체크아웃 하는 소스 트리를 격납하는 디렉토리를 작성해, 본디렉토리의 그룹을 프라이빗 그룹으로 설정해, 본디렉토리하의 파일이 디렉토리의 그룹 ID 를 계승하도록(듯이) 합니다. FreeBSD 에서는 자동적으로, 파일은 디렉토리의 그룹 ID 를 계승합니다. SysV 에서는, 전형적으로는 SGID 비트를 디렉토리로 설정할 필요가 있습니다. 체크아웃 한 트리를 공유하는 유저는, 이 그룹에 포함될 필요가 있습니다. 단일의 체크아웃 된 소스 트리를 공유한다고 하는 것은, 공통의 CVS 리포지터리(repository)에 복수 유저의 액세스를 허락하는 것으로 완전히 다른 것에 주의해 주세요. 공통의 CVS 리포지터리(repository)에의 액세스는, 공유 그룹 기입 권한에 의해 이미 실현되고 있어 본옵션을 필요로 하지 않습니다.

본옵션을 투과적으로 사용하기 위해서는, 단지 'cvs -g'라고 하는 행을 ~/.cvsrc 파일에 두는 것만으로 좋습니다. 프라이빗 그룹 혹은 프라이빗 모드 0700 의 디렉토리에 전소스를 체크아웃 한 것을 파이야워르로 방어하고 있으므로 않은 한, 본옵션의 사용은 권유받지 않습니다.

-x 클라이언트와 서버의 사이의 통신을 모두 암호화합니다. 현재는, Kerberos connection 사용시만 사용 가능합니다.
-z compression-level
  파일을 네트워크 경유로 교환할 때, 압축 레벨 compression-levelgzip (을)를 사용해, 교환하는 데이터의 압축과 신장을 실시합니다. 링크의 양단으로 GNU gzip 프로그램이 그 시점에서의 서치 패스중에 존재할 필요가 있습니다.

사용법

`cvs -H'로 실시하고 싶은 특정의 릴리스 제어 기능을 선택하기 위해서, cvs 에 대해서 하나의 cvs_command (을)를 지정하지 않으면 안됩니다. 각 cvs 명령은 그것 자신의 옵션과 인수의 모임을 받아들입니다. 그렇지만, 많은 옵션이 복수의 명령에 건너 이용 가능합니다. -H 옵션을 명령와 함께 지정하는 것으로, 각 명령의 사용법의 통계를 표시할 수가 있습니다.

CVS 의 스타트 업 파일

통상, CVS 는 기동시에 유저의 홈 디렉토리로부터 .cvsrc 그렇다고 하는 파일을 읽어들입니다. 이 기동시의 수속은 -f 플래그로 멈출 수가 있습니다.

.cvsrc 파일에는 CVS 명령에 인수 리스트를 붙여, 1 행에 1 개의 명령을 늘어놓습니다. 예를 들면 .cvsrc 에 이하와 같이 쓰면(자):

diff -c

`cvs diff' 명령에는 항상 커멘드 라인으로 지정된 옵션에 가세해 -c 옵션이 건네받는다고 하는 의미가 됩니다 (이 경우 `cvs diff' (을)를 실행하면(자) 모두에 대해 context diff 형식이 생성된다고 한다 효과를 가집니다).

포괄적인 옵션은, cvs 키워드를 사용해 지정합니다. 예를 들면 다음의

cvs -q

(은)는, 포괄적 옵션 -q 가 지정되었는지와 같이 전 `cvs' 명령이 동작하는 것을 의미합니다.

CVS COMMAND 의 통계

이하는 전 cvs 명령의 해설을 요약한 것입니다:
add 새로운 파일 또는 디렉토리를 리포지터리(repository)에 추가합니다. 파일에 대해서는 추가를 동파일에 대한다 `cvs commit' (을)를 할 때까지 기다립니다. 이전에 `cvs checkout' (을)를 실시하는 것으로 작성된 소스중에서 마셔 실행 가능합니다. 새로운 소스 계층의 전체를 cvs 의 제어하에 두려면 `cvs import' (을)를 사용해 주세요. (리포지터리(repository)를 직접 변경하는 것이 아닙니다. 작업 디렉토리를 변경합니다. )
admin
  소스 리포지터리(repository)에 대해서 제어 명령을 실행합니다. (리포지터리(repository)를 직접 변경합니다. 작업 디렉토리를 사용합니다만 변경은 실시하지 않습니다. )
checkout
  편집 작업을 위한 원시 파일의 작업 디렉토리를 작성합니다. (작업 디렉토리를 생성 또는 변경합니다. )
commit
  작업 디렉토리에서의 변경, 추가, 삭제 부분을 소스 리포지터리(repository)에 반영합니다. (리포지터리(repository)를 변경합니다. )
diff
  작업 디렉토리의 파일과 소스 리포지터리(repository), 또는 소스 리포지터리(repository)중의 2 개의 리버젼간의 차분을 표시합니다. (리포지터리(repository), 작업 디렉토리의 모두 변경하지 않습니다. )
export
  사이트로부터의 출하를 위한 한갖춤의 원시 파일의 카피를 준비합니다. `cvs checkout' (와)과 달라 cvs 관리를 위한 디렉토리가 만들어지지 않고 (그리고 그 때문에 `cvs export'로 `cvs commit'를 상징적 태그가 지정되지 않으면 안됩니다 (리포지터리(repository)를 변경하지 않습니다. 작업 디렉토리를 닮은 디렉토리를 작성합니다).
history
  소스 리포지터리(repository)의 특정의 파일 또는 디렉토리에 당신이나 다른 사람이 실행했다 cvs 명령을 표시합니다. (리포지터리(repository)도 작업 디렉토리도 변경하지 않습니다. ) 역사 로그는 `$CVSROOT/CVSROOT/history' 파일이 작성되는 것으로 유효하게 되었을 경우에게만 기록됩니다. cvs(5) (을)를 참조해 주세요.
import
  외부에서 행해진 갱신 내용을 ``vender 브랜치(branch)''로서 소스 리포지터리(repository)에 수중에 넣습니다. (리포지터리(repository)를 변경합니다. )
init
  CVSROOT 서브 디렉토리와 디폴트의 제어 파일을 추가하는 것으로, 리포지터리(repository)를 초기화합니다. 리포지터리(repository)를 사용하기 전에, 본명령을 사용하는지, 다른 방법으로 리포지터리(repository)를 초기화할 필요가 있습니다.
log 로그 정보를 표시합니다. (리포지터리(repository)도 작업 디렉토리도 변경하지 않습니다. )
rdiff
  리포지터리(repository)안의 2 개의 릴리스의 사이의 차분의 집합을 패치 파일로서 준비합니다. (리포지터리(repository)도 작업 디렉토리도 변경하지 않습니다. )
release
  `cvs checkout'를 모든 변경을 버리고 갑니다. (작업 디렉토리를 삭제할 수 있습니다. 리포지터리(repository)는 변경하지 않습니다. )
remove
  소스 리포지터리(repository)로부터 파일을 삭제합니다, 그 파일에 `cvs commit' 하지만 실행될 때까지 보류됩니다. (직접 리포지터리(repository)에는 영향을 주지 않습니다. 작업 디렉토리를 변경합니다. )
rtag
  소스 리포지터리(repository)의 특정의 리버젼의 파일에 명시적으로 상징적 태그를 지정합니다. `cvs tag'도 (리포지터리(repository)를 직접 변경합니다. 작업 디렉토리는 필요없고 또 변경도 하지 않습니다. )
status
  현재의 파일 상태를 표시하는: 최신 버젼, 작업 디렉토리의 파일의 버젼, 작업 버젼이 편집되었는지 어떠했는지, 옵션으로 RCS 파일중의 상징적 태그. (리포지터리(repository), 작업 디렉토리라고도 변경하지 않습니다. )
tag 리포지터리(repository)중의 파일에 상징적 태그를 지정합니다. 디폴트에서는, 작업 디렉토리와 마지막에 동기를 취한 리버젼에 태그를 붙입니다. (직접 리포지터리(repository)를 변경합니다. 작업 디렉토리를 사용합니다만 변경은 하지 않습니다. )
update
  리포지터리(repository)로부터 변경을 꺼내 작업 디렉토리를 최신 상태로 합니다. 가능하면 merge가 자동으로 행해집니다. 변경점이 충돌하고 있기 위해서(때문에) 수동으로 해결해야 하는 경우는, 경고가 표시됩니다. (작업 디렉토리를 변경합니다. 리포지터리(repository)는 변경하지 않습니다. )

공통의 COMMAND OPTIONS

이 마디에서는 복수의 cvs 명령로 사용할 수 있다 command_options 에 대해 설명합니다. 반드시 모든 명령이 이것들 모든 옵션을 서포트하고 있는 것은 아닙니다. 명령의 각 옵션은, 그것이 의미를 이루는 명령에서만 서포트됩니다. 그렇지만, 명령이 그러한 옵션의 하나를 가질 때, 다른 명령에서도 그 옵션이 같은 의미를 가진다고 생각해 서로 지장있습니다. (개개의 명령와 함께 열거되어 있는 다른 옵션은 있다 cvs 명령와 다른 커멘드로 다른 의미를 가질지도 모릅니다. ) 주의: history 명령은 예외입니다. 이 명령은, 이것들 표준의 옵션과도 충돌하는 많은 옵션을 서포트하고 있습니다.
-D date_spec
  date_spec 이전의 것 중(안)에서 가장 최근의 리버젼을 사용합니다 (단독의 인수로, 일시의 표기는 과거의 일시를 지정합니다). 다종 다양한 일시의 포맷이, 특히 ISO ("1972-09-24 20:05") 또는 Internet ("24 Sep 1972 20:05")가 서포트됩니다. 특정의 타임 존이 지정되어 있지 않으면, date_spec 는 로컬 타임 존으로 해석됩니다. 원시 파일의 개인적인 카피를 만들 때 사용하면(자), 지정은 ``sticky''와 됩니다. 즉, -D 를 사용해 작업 파일을 꺼내면(자), cvs 는 지정된 일시를 기록합니다. 이것은 같은 디렉토리에서의 그 후의 update 로 같은 날시를 사용하도록(듯이) 하기 (위해)때문입니다 (이것을 명시적으로 무효(윳돈CF(듯이) 지정하고 있지 않는 경우에 한정합니다. update 명령의 설명을 참조해 주세요). -Dcheckout, diff, history, export, rdiff, rtag, update 명령로 유효합니다. 유효한 일시 지정에는 이하와 같은 것이 있습니다:
1 month ago
2 hours ago
400000 seconds ago
last year
last Monday
yesterday
a fortnight ago
3/31/92 10:00:07 PST
January 23, 1987 10:05pm
22:00 GMT
-f cvs 명령에 특정의 일시나 태그를 지정했을 경우, 통상은 지정한 태그를 포함하지 않는다 (또는 지정한 일시에 존재하지 않았다) 파일을 무시합니다. 일치하는 태그 또는 일시가 존재하지 않아도 파일을 꺼내고 싶을 때는 -f 옵션을 사용합니다. (그 경우, 가장 새로운 버젼이 사용됩니다. ) -f (은)는 이하의 명령로 사용할 수 있습니다: checkout, export, rdiff, rtag, update
-k kflag 디폴트의 키워드 처리를 변경합니다. -k 옵션은 add, checkout, diff, export, rdiff, update 명령로 사용할 수 있습니다. 원시 파일의 개인적인 카피를 작성할 경우에 사용하면(자) kflag 의 지정은 ``sticky''가 됩니다. 즉, 이 옵션을 checkoutupdate 명령로 지정하면(자), cvs 는 지정한 kflag 를 파일에 관련지어 다른 것을 지정할 때까지, 이후의 update 명령로 그것을 계속 사용합니다.

보다 유용한 kflag 로서는 -ko 와 -kb (바이노리필드용) (와)과 -kv 가 있습니다. -kv 는 export 때, 어딘가 다른 사이트에서 후에 import 되어도 키워드 정보가 남도록(듯이) 하고 싶은 경우에 유용합니다.

-l 로컬; 서브 디렉토리를 재귀적으로 처리하는 것이 아니라, 현디렉토리에서만 실행합니다. 이하의 명령로 사용할 수 있습니다: checkout, commit, diff, export, remove, rdiff, rtag, status, tag, update 주의: 이것은 cvs 명령의 왼쪽 (으)로 지정할 수 있는, 전체에 작용한다 `cvs -l' 옵션과는 다릅니다!
-n checkout/commit/tag/update 의 어느 프로그램도 실행하지 않습니다. (프로그램은 각각의 동작중에 모듈 데이타베이스로 실행하는 것을 지정될 가능성이 있어, 이 옵션은 이것을 우회도로 합니다. ) checkout, commit, export, rtag 명령로 이용할 수 있습니다. 경고: 이것은 cvs 명령의 좌측 (으)로 지정할 수 있는, 전체에 작용한다 `cvs -n' 옵션과 같지는 않습니다.
-P checkoutupdate 에 의해 갱신된 것으로 비운 여분의 디렉토리를 없앱니다 (즉 삭제합니다). 통상은, 하늘의 디렉토리 (리버젼 관리된 파일을 포함하지 않는 걸)는 남겨집니다. -P (을)를 지정하면(자), 체크아웃 한 소스로부터 그렇게 말한 디렉토리를 입다물어 삭제합니다. 이것은 리포지터리(repository)로부터는 디렉토리를 삭제하지 않습니다. 당신이 체크아웃 한 카피로부터 삭제할 뿐입니다. 이 옵션은 -r 인가 -D 옵션이 checkoutexport지정되었을경우에암묵중에 지정되는 것에 주의해 주세요.
-T (로컬) 리포지터리(repository)로부터의 카피에 의해, CVS/Template 를 작성/갱신합니다. 본옵션은, 로컬의 cvs 리포지터리(repository)를 관리해, 리모트의 리포지터리(repository)에 위탁하는 개발자에게 있어 유용합니다. CVS/Template 를 유지하는 것으로써, 리모트 위탁에 대해도 여전히, 적절한 템플릿을 위탁 에디터 세션에 착수하고 가능해집니다. checkoutupdate이용가능합니다.
-p 리포지터리(repository)로부터 꺼내진 파일을, 커런트 디렉토리에 기입하는 것이 아니라, 표준 출력에 파이프 합니다. checkoutupdate 명령로 사용할 수 있습니다.
-r tag 디폴트의 ``head''리버젼 대신에 인수 tag 그리고 지정된 리버젼을 사용합니다. tagrtag 명령로 붙일 수 있었던 임의의 태그와 함께, 항상 2 개(살)의 특별한 태그를 사용할 수 있습니다: `HEAD' (은)는 리포지터리(repository)중에서 가장 새로운 유효한 버젼을 가리켜, 그리고 `BASE' (은)는 경향의 작업 디렉토리에 마지막에 체크아웃 했다 리버젼을 가리킵니다.

이 옵션을 `cvs checkout' 인가 `cvs update' 그리고 파일의 카피를 작성할 경우에 사용하면(자), tag 의 지정은 ``sticky''입니다: cvstag 를 기억한 이후의 update 명령에서도, 다른 것을 지정할 때까지, 그것을 계속 사용합니다. tag (으)로서는 상징적 또는 번호에 의하는 것을 사용할 수 있습니다. RCS 파일이 지정된 태그를 포함하지 않을 때에 경고 메세지를 억제하기 위해(때문에) 전체에 작용한다 -q 옵션을 명령 옵션 -r (와)과 함께 지정하면(자) 편리한 경우가 많이 있습니다. -rcheckout, commit, diff, history, export, rdiff, rtag, update 명령로 사용할 수 있습니다. 경고: 이것은 cvs 명령의 좌측 (으)로 지정해, 전체에 작용한다 `cvs -r' 옵션과 같지는 않습니다.

CVS COMMANDS

이하가 (최종적인) 전 cvs 명령의 상세와 각각이 받아들이는 옵션입니다. 각 명령의 최초의 요약행의 설명은 3 종류의 일을 정리하고 있습니다:
명령의 옵션과 인수 특별한 옵션이 이하로 설명됩니다. 공통의 명령 옵션은 요약행 밖에 나타나지 않을지도 모릅니다.
작업 디렉토리인가 리포지터리(repository)인가?
  몇개의 cvs 명령은 실행에 작업 디렉토리가 필요합니다. 몇개인가는 리포지터리(repository)가 필요합니다. 같이 몇개의 명령은 리포지터리(repository)를 변경해, 몇개인가는 작업 디렉토리를 변경해, 몇개인가는 어떤 변경도 실시하지 않습니다.
동의어 많은 명령에는 동의어가 있습니다. 동의어는 정식적 이름보다 기억하기 쉽다 (혹은 타이프 치기 쉽다)와 느끼겠지요.
add [-k kflag] [-m 'message'] files. . .
  이하가 필요: 리포지터리(repository), 작업 디렉토리.
이하를 변경: 작업 디렉토리.
동의어: new
add 명령을 사용해 소스 리포지터리(repository)에 새로운 파일 또는 디렉토리를 작성합니다. add 그리고 지정되는 파일 또는 디렉토리는, 벌써 커런트 디렉토리 ( checkout 명령로 작성된 디렉토리가 아니면 안됩니다)에 존재하지 않으면 안됩니다. 새로운 디렉토리 계층의 전체를 소스 리포지터리(repository)에 추가한다 (예를 들면, 써드파티의 vender로부터 받은 파일군과 같은)에는, 대신에 `cvs import' 명령을 사용합니다.

`cvs add' 의 인수가 직하의 서브 디렉토리를 가리키고 있다면, 그 디렉토리가 소스 리포지터리(repository)의 현위치에 작성되어 필요한 cvs 관리 파일이 작업 디렉토리에 작성됩니다. 디렉토리가 벌써 소스 리포지터리(repository)에 존재했을 경우에서도, `cvs add' (은)는 당신의 버젼의 디렉토리에 관리 파일을 작성합니다. 이것에 의해, 당신이 소스를 checkout 한 후에 누군가 다른 사람이 디렉토리를 만들고 있어도 `cvs add' 그리고 그 디렉토리를 당신의 사적인 소스에 작성하는 것이 가능하게 됩니다. 이하와 같이 할 수가 있습니다:

example% mkdir new_directory
example% cvs add new_directory
example% cvs update new_directory

`cvs update' (을)를 사용한 다른 접근도 있습니다:

example% cvs update -d new_directory

(새롭고 할 수 있던 디렉토리를 당신의 작업 디렉토리에 추가하려면 , 아마 `cvs checkout' 인가 `cvs update -d'를

`cvs commit' 그리고 변경이 항구적인의 것으로 여겨질 때까지, 추가된 파일은 소스 리포지터리(repository)에는 놓여지지 않습니다. `cvs remove' 명령로 삭제된 파일에 대해서 `cvs add' (을)를 실시하면, 사이에 `cvs commit' 명령이 실행되어 있지 않으면 파일이 restore합니다.

새로운 파일을 `cvs commit' 그리고 항구적인의로 할 경우에, 여느 때처럼, 로그 메세지를 지정한다 기회가 있습니다. 만약 파일의 작성 (와)과 대응하는 하나 더의 로그 메세지를 지정하고 싶다면 (예를 들면, 파일의 목적을 설명하는 등), add 명령의 `-m message' 옵션으로 지정할 수가 있습니다.

`-k kflag' 옵션으로 이 파일이 체크아웃 될 때의 디폴트를 지정할 수 있습니다. 인수 `kflag' 하 RCS 파일에 기록되어 `cvs admin' 그리고 변경할 수가 있습니다. 전개되었다 키워드를 가지지 말고 있을 것이다 바이너리를 체크인 하는 경우에는 `-ko' (을)를 지정하면(자) 편리합니다.

admin [rcs-options] files. . .
  이하가 필요: 리포지터리(repository), 작업 디렉토리.
이하를 변경: 리포지터리(repository).
동의어: rcs
이것은 rcs(1) (을)를 닮은 관리 기구와 대응한다 cvs 의 인터페이스입니다. 무슨 필터나 변환도 실시하지 않습니다. 그렇지만, 이 명령은 재귀적으로 일합니다. 따라서 사용에는 특별한 주위를 기울이지 않으면 안됩니다.
checkout [options] modules. . .
  이하가 필요: 리포지터리(repository).
이하를 변경: 작업 디렉토리.
동의어: co, get
modules지정된원시파일의카피를가진다 작업 디렉토리를 작성합니다. 다른 대부분의 cvs 명령은 작업 디렉토리에 작용하는 것이므로, 이것들을 사용하기 전에 `cvs checkout' (을)를 실행하지 않으면 안됩니다.

modules 는 몇개의 소스 디렉토리와 파일을 모은 것에 대한 심볼명 (그 자체는 `modules' 그렇다고 하는 모듈로서 소스 리포지터리(repository)에 정의되고 있습니다. cvs(5) 참조)인가, 혹은 리포지터리(repository)중에서의 디렉토리 또는 파일에의 패스명입니다.

지정했다 modules 에 응해, checkout (은)는 재귀적으로 디렉토리를 작성해 적절한 원시 파일로 채웁니다. 그 후는 언제라도, (다른 소프트웨어 개발자들이 소스의 그들의 분의 카피를 편집하고 있는지 어떤지를 신경쓰는 일 없이) 이러한 원시 파일을 편집하거나 다른 사람에 따라서 소스 리포지터리(repository)에 행해진 새로운 변경을 수중에 넣기 위해서(때문에) 이것들을 갱신 (update)하거나 당신의 작업을 항구적인 변경으로서 리포지터리(repository)에 등록 (commit)할 수가 있습니다.

checkout (은)는 디렉토리의 작성에 사용되는 것에 주의해 주세요. 작성되는 디렉토리의 톱 레벨은 항상 checkout 하지만 기동된 디렉토리에 추가되고 그리고 통상, 지정되었다 module같은이름을가집니다. module 하지만 앨리어스(alias)의 경우는, 작성된 서브 디렉토리는 다른 이름을 가질지도 알려지지 않습니다만, 그것이 서브 디렉토리인 것, 그리고 checkout (은)는 파일이 사적인 작업 area에 꺼내질 때에 각 파일에의 상대 패스를 표시하는 것 (전체에 작용한다 -Q 옵션을 지정하고 있지 않으면)는 목표로 할 수 있습니다.

벌써 이전의 checkout 그리고 작성되고 있는 디렉토리에서 `cvs checkout' (을)를 실행하는 일도 용서되고 있습니다. 이것은 이하로 설명한다 update 명령에 -d 옵션을 지정하는 것과 같은 효과를 가집니다.

`cvs checkout' 그리고 사용할 수 있다 options (은)는 이하의 표준의 명령 옵션입니다. -P, -f, -k kflag , -l, -n, -p, -r tag, -D date

이것들에 가세해, 이하의 특별한 명령 옵션을 checkout 그리고 사용할 수가 있습니다:

-A 옵션으로 sticky 인 태그, 일자 또는 -k 옵션을 리셋트 할 수 있습니다. (작업 파일을 -r, -D, -k 옵션의 어느쪽이든을 사용해 꺼내면(자), cvs 는 대응하는 태그, 일자, kflag 를 기록한 이후의 갱신 (update)으로 그것을 계속 사용합니다. -A 옵션을 사용해 cvs 에 그러한 지정을 잊게 해 파일의 ``head''버젼을 꺼냅니다).

-j branch 옵션은 베이스가 된 리버젼과 거기로부터 변경된 결과의 리버젼과의 차분을 merge 합니다 (예를 들면, 만약 태그가 브랜치(branch)를 가리키고 있을 때는, cvs (은)는, 그 브랜치(branch)로 행해진 모든 변경을 작업 파일에 merge 합니다).

2 개의 -j 옵션을 지정하면(자), cvs (은)는 2 개의 각각의 리버젼간에서의 변경을 merge 합니다. 이것은 특정의 차분을 작업 파일로부터 ``삭제''하기 위해서 사용하는 것이 할 수 있습니다.

더해, 각 -j 옵션을 브랜치(branch)로 사용하는 경우에 필요하면 일시 지정을 더할 수가 있어 선택하는 리버젼을 지정한 일시 이내에 제한할 수 있습니다. 일시를 더하는 경우는 태그에 코론 (:)을 붙여 지정합니다. 예로서는 `cvs import' 그리고 로컬인 변경과 충돌하는 부분이 있는 소스를 import 할 경우에 실행하도록(듯이) 지시받는 명령이 있습니다:

example% cvs checkout -jTAG:yesterday -jTAG module

-N 옵션과 `-d dir' (을)를 지정하는 것으로 작업 디렉토리에서 모듈의 패스가 단축되는 것을 막을 수 있습니다. (통상, 명시적으로 대상 디렉토리를 지정하면(자) cvs 는 가능한 한 패스가 짧아지도록(듯이) 합니다. )

-c 옵션으로, 작업 디렉토리의 파일이나 디렉토리로 작성이나 변경을 실시하는 대신에, 모듈 파일을 정렬 한 것을 표준 출력에 카피 합니다.

-d dir 옵션으로, 모듈명이 아니고, dir 그리고 지정한 이름의 디렉토리를 작업 파일을 위해서(때문에) 작성합니다. -N 를 함께 지정하지 않는 경우는, dir 아래에 작성되는 패스는 가능한 한 짧아집니다.

-s 옵션을 사용해 -s 옵션으로 모듈 파일에 격납된 모듈 단위의 스테이터스 정보를 표시합니다.

commit [-lnR] [-m 'log_message' | -f file] [-r revision] [files. . .]
  이하가 필요: 작업 디렉토리, 리포지터리(repository).
이하를 변경: 리포지터리(repository).
동의어: ci
작업 디렉토리에서의 변경을 공유의 소스 리포지터리(repository)에 짜넣는에 때로는 `cvs commit' (을)를 사용합니다.

위탁하는 대상이 되는 files 를 지정하지 않는 경우, 현재의 작업 디렉토리안의 전파일을 조사할 수 있습니다. commit (은)는 당신이 정말로 변경한 파일만을 신중하게 리포지터리(repository)으로 변경합니다. 디폴트에서는 (또는 명시적으로 -R 옵션을 지정했을 경우), 서브 디렉토리의 파일도 조사할 수 있어 만약 변경되고 있으면 위탁됩니다. -l 옵션으로 현디렉토리만 위탁 하도록(듯이) 제한할 수 있습니다. 변경되어 있지 않아도 강제적으로 파일을 위탁하고 싶은 경우가 있을지도 알려지지 않습니다. 이것은 -f 플래그로 가능해, 이것은 동시에 재귀도 억제합니다 (물론 -R 그리고 재귀 하도록 할 수 있습니다).

commit (은)는 선택된 파일이 소스 리포지터리(repository)의 현리버젼에 대해서 최신인 것을 확인합니다. 만약 선택된 파일중 한쪽이 우선 `cvs update' 그리고 최신으로 되지 않으면 안 되면, 거기서 통지해 위탁하지 않고 끝납니다. commitupdate 명령을 호출하지 않습니다. update 해야 한다고나무인지 어떤지의 판단은 유저에게 맡겨집니다.

모두가 잘되면(자), 로그 메세지를 입력하기 위해서 에디터가 불려 갑니다. 로그 메세지는 하나인가 그 이상의 로그를 취한다 프로그램에 기입해져 소스 리포지터리(repository)의 파일에 놓여집니다. 대신에 명령행으로 -m 옵션과 함께 로그 메세지를 지정해, 에디터의 호출을 억제할 수가 있습니다. 또 -F 옵션으로 인수의 file 에 로그 메세지가 포함되어 있는 것을 지시할 수도 있습니다.

-r 옵션으로 특정의 상징적 또는 번호로 지정된다 리버젼으로서 위탁할 수 있습니다. 예를 들면, 전파일을 리버젼 ``3. 0''에 올린다 (변경되어 있지 않은 것도 포함해) 에는, 이하와 같이 합니다:

example% cvs commit -r3. 0

cvs (은)는 메인의 간상의 리버젼 (닷이 1 개의 리버젼)에의 위탁만 허락합니다. 그렇지만, -r 옵션으로 브랜치(branch)상의 리버젼 (짝수개의 닷을 가지는 리버젼)에 위탁할 수도 있습니다. 브랜치(branch)가 되는 리버젼을 작성하려면 , 통상 rtag 또는 tag 명령의 -b 옵션을 사용합니다. 그 후, checkout 또는 update 의 어느쪽이든으로 소스의 베이스를 새롭게 작성한 브랜치(branch)로 할 수가 있습니다. 그 이후, 그러한 작업 파일로 행해진 모든 commit 되는 변경점은 자동적으로 브랜치(branch)의 리버젼에 추가되어 거기에 따라 주된 개발 라인이 혼란 당할 것은 없습니다. 예를 들면(자), 제품의 버젼 1.2 에의 패치를 작성하지 않으면 안 되게 되었다고 하면(자), 버젼 2.0 이 벌써 개발중이었다고 해도, 이하와 같이 할 수 있습니다:

example% cvs rtag -b -rFCS1_2 FCS1_2_Patch product_module
example% cvs checkout -rFCS1_2_Patch product_module
example% cd product_module
[[ hack away ]]
example% cvs commit

지극히 실험적인 소프트웨어를 개발하고 있다고 하여, 전의 주에 체크아웃 했군 등인가의 리버젼을 베이스로 하고 있으면(자) 합니다. 당신의 그룹의 다른 사람이 이 소프트웨어로 당신과 함께 작업하고 싶지만, 주된 개발 라인의 방해는 하고 싶지 않다고 생각했다면, 당신은 당신의 변경점을 새로운 브랜치(branch)에 위탁하면 좋을 것입니다. 그러자(면) 다른 사람은 당신의 실험적인 변경을 체크아웃 해 cvs 의 충돌 해결 기능을 최대한으로 이용할 수가 있습니다. 시나리오는 이하와 같이 됩니다:

example% cvs tag -b EXPR1
example% cvs update -rEXPR1
[[ hack away ]]
example% cvs commit

다른 사람은 단순하게 `cvs checkout -rEXPR1 whatever_module' 그렇다면 실험적인 변경을 채용해 당신과 작업할 수 있게 됩니다.

diff [-kl] [rcsdiff_options] [[-r rev1 | -D date1 | -j rev1:date1] [-r rev2 | -D date2 | -j rev2:date2]] [files. . .]
  이하가 필요: 작업 디렉토리, 리포지터리(repository).
이하를 변경: 아무것도 변경하지 않습니다.
작업 디렉토리의 파일과 소스 리포지터리(repository)의 리버젼을 `cvs diff' 명령로 비교할 수 있습니다. 만약 특정의 리버젼을 지정하지 않으면, 베이스로 한 리버젼이라고 비교됩니다. 표준의 cvs 명령의 옵션 -r 그리고 비교의 대상이 되는 리버젼을 지정할 수도 있습니다. 마지막으로, -r (을)를 2 회 사용하면(자), 리포지터리(repository)의 2 개의 리버젼간의 차분을 취할 수가 있습니다. (head 브랜치(branch)의) 과거의 리버젼과의 차분을 취하기 위해서(때문에) -D 옵션을 지정할 수도 있습니다. 또, 과거의 브랜치(branch) 태그간의 차분을 취하기 위해서(때문에) -j 옵션을 지정할 수도 있습니다. -r (와)과 -D (와)과 -j 옵션은 항상 지정된 중에서 2 개까지를 조합할 수 있습니다.

다른 사용 가능한 옵션에 대해서는 rcsdiff(1) (을)를 참조해 주세요.

파일을 아무것도 지정하지 않으면 diff (은)는 현디렉토리 (그리고, 표준 옵션 -l지정하고있지않으면 그 서브 디렉토리)의 모든 파일에 대해, 소스 리포지터리(repository)의 대응하는 리버젼과 다르고 있는 것 (즉 당신이 변경한 파일) 또는 지정된 리버젼과 차이가 나는 것에 임해서, 그 차분을 표시합니다

export [-flNnQq] -r rev|-D date [-d dir] [-k kflag] module. . .
  이하가 필요: 리포지터리(repository).
이하를 변경: 현디렉토리.
이 명령은 `cvs checkout'의 cvs 의 관리 디렉토리를 가지지 않는다 module 의 소스의 카피가 필요한 때에 사용합니다. 예를 들면, 사이트외에 소스를 낼 준비를 하기 위해서 `cvs export' (을)를 사용할 수가 있습니다. 이 명령에서는 일자 또는 태그를 지정하는 것이 필요 입니다. (-D 또는 -r 에 의해). 거기에 따라 출하한 소스를 확실히 재구성할 수 있게 됩니다.

표준이 아닌 옵션은 `-d dir' (소스를 디렉토리 dir 에 기입합니다)(와)과 `-N' (모듈 패스를 단축하지 않습니다) 뿐입니다. 이것들은 `cvs checkout'의

export 하지만 사용될 때는 -kv 옵션이 유용합니다. 이것에 의해 키워드가, 어딘가 다른 사이트에서 import (을)를 했을 때에 리버젼 정보가 없어지지 않는 것 같은 형태에 전개되도록(듯이) 됩니다. 다른 kflag 를 `cvs export' 그리고 사용할 수도 있습니다. 그 설명은 co(1) 에 있습니다.

history [-report] [-flags] [-options args] [files. . . ]
  이하가 필요: `$CVSROOT/CVSROOT/history'파일.
이하를 변경: 아무것도 변경하지 않습니다.
cvs 는 역사 파일을 관리하고 있어, 각 checkout, commit, rtag, update, release 명령의 사용을 기록합니다. `cvs history' (을)를 사용해, 이 정보를 다양한 포맷으로 표시할 수가 있습니다.

경고: `cvs history' 하 `-f', `-l', `-n', `-p' (을)를 공통의 COMMAND OPTIONS 에서의 설명과는 다른 의미에 사용합니다.

몇개의 옵션 (위에서 -report 가 되고 있는 부분)은 어떤 종류의 리포트를 생성하는지를 제어합니다:

-c 지금까지의 각 commit (즉 리포지터리(repository)의 변경)에 대해 리포트합니다.
-m module 특정의 module 에 대해 리포트합니다. (명령행으로 복수의 -m 를 지정할 수 있습니다. )
-o 체크아웃 된 모듈에 대해 리포트합니다.
-T 모든 태그에 대해 리포트합니다.
-x type 특정의 레코드 타입 X 세트를 cvs 역사로부터 꺼냅니다. 타입은 1 캐릭터로 나타내져 조합해 지정할 수 있습니다. 이하의 명령은 단일의 레코드 타입을 가지는: checkout (타입 `O'), release (타입 `F'), rtag (타입 `T'). update 는 4 개의 레코드 타입 중 1 개가 됩니다: `W'는 작업용의 파일의 카피가 update 로 (그것이 리포지터리(repository)로부터 없어져 있었기 때문에) 삭제되었을 경우입니다; `U'는 작업 파일이 리포지터리(repository)로부터 카피되었을 경우입니다; `G'는 필요한 merge가 무사하게 끝났을 경우입니다; 'C'는 merge가 필요하지만 충돌이 검출되었을 경우 (수동에서의 merge가 필요한 경우)입니다. 또, commit 에서는 3개의 레코드 타입 중 하나가 됩니다: `M'는 파일이 변경되었을 경우; `A'는 파일이 최초로 추가되었을 경우; `R'는 파일이 삭제되었을 경우입니다.
-e 모두 (전레코드 타입); 이하를 지정하는 것과 등가입니다. `-xMACFROGWUT'
-z zone 역사 레코드를 출력할 때에 zone 그리고 지정된 타임 존을 사용합니다. LT 그렇다고 하는 존명은 로컬 타임의 의미가 됩니다. 수치에 의한 오프셋(offset)는 시분에서의 UTC 와의 시차를 의미합니다. 예를 들면, +0530 (은)는 5 시간과 30 분만 UTC 보다 전 (즉 동쪽)의 의미가 됩니다.

  -flags 라고 쓰여진 부분의 옵션은, 리포트하는 범위를 짭니다. 인수의 지정은 없습니다.
-a 모든 유저의 데이터를 표시합니다 (디폴트에서는 `cvs history'를
-l 마지막 변경만 표시합니다.
-w `cvs history' 하지만 실행되고 있는 것과 같은 작업 디렉토리로부터 행해진 변경에 관한 레코드만을 표시합니다.

  -options args 라고 쓰여진 부분의 옵션은 인수에 기초를 두어 리포트 범위를 짭니다:
-b str 캐릭터 라인 str 를 모듈명, 파일명, 리포지터리(repository) 패스의 어느 쪽인가에 포함한 레코드로 돌아와 표시합니다.
-D date date 이후의 데이터를 표시합니다.
-p repository
  특정의 소스 리포지터리(repository)의 데이터를 표시합니다 (복수의 -p 옵션을 같은 명령행으로 지정할 수 있습니다).
-r rev 개개의 RCS 파일에 나타나는 리버젼이 rev 로 지정된 리버젼 또는 태그 이후인 레코드를 표시합니다. 각 RCS 파일에 대해 리버젼 또는 태그가 검색됩니다.
-t tag tag 로 지정되는 태그가 역사 파일에 마지막에 추가되고 나서의 레코드를 표시합니다. 이 옵션은, RCS 파일은 아니고 역사 파일만 참조하는 점으로 상기의 -r 플래그와 달리, 보다 고속으로.
-u name name 로 지정되는 유저의 레코드를 표시합니다.
import [-options] repository vendortag releasetag. . .
  이하가 필요: 리포지터리(repository), 소스 배포물의 디렉토리.
이하를 변경: 리포지터리(repository).
`cvs import' (을)를 사용하는 것으로 외부의 공급원 (예를 들면 소스 vender)으로부터의 소스 배포물 전체를 당신의 소스 리포지터리(repository)의 디렉토리에 수중에 넣을 수 있습니다. 최초의 리포지터리(repository)의 작성과 외부의 공급원으로부터의 모듈에의 대규모 갱신의 양쪽 모두에 이 명령을 사용할 수가 있습니다.

인수 repository 로 CVS 루트 디렉토리하의 리포지터리(repository)용 디렉토리명 (또는 디렉토리에의 패스)을 줍니다. 만약 디렉토리가 존재하지 않으면, import 가 작성합니다.

당신의 소스 리포지터리(repository)로 (전회의 import 로부터) 변경되었다 소스에의 갱신에 import 를 사용했을 경우, 개발의 2 개의 브랜치(branch)로 충돌하고 있는 파일에 대해 경고합니다. import 가 지시하도록(듯이), `cvs checkout -j' (을)를 사용해 차분을 조정할 수 있습니다.

디폴트에서는, 어떤 종류의 파일명이 `cvs import'로 CVS 관리, 또는 다른 일반적인 소스 관리 시스템에 관련하는 이름; 패치 파일, 오브젝트 파일, archive파일, 에디터의 백업파일을 위한 일반적인 이름; 그리고 잡다한 유틸리티의 가공품인 것을 나타내는 그 외의 이름. 무시되는 파일의 리스트의 최신에 대해서는, (이 메뉴얼 페이지의 관련 항목의 마디에 기술되어 있도록(듯이)) Cederqvist 저의 메뉴얼을 참조해 주세요.

외부로부터의 소스는 제일 레벨의 브랜치(branch), 디폴트에서는 `1.1. 1'에 이후의 갱신은 이 브랜치(branch)의 리프가 됩니다. 예를 들면, 최초로 import 한 소스 집합으로부터의 파일은 리버젼 `1.1. 1.1'이 다음의 import 에 의한 갱신으로 파일은 리버젼 `1.1. 1.2'가

최악이어 3 개의 인수가 필요합니다. 소스의 집합을 식별하기 위해서 repository 가 필요합니다. vendortag 는 브랜치(branch) 전체를 나타낸다 태그가 됩니다 (예를 들면 `1.1. 1'으로 `cvs import'를 식별하기 위해서 적어도 하나의 releasetag 도 지정하지 않으면 되지 않습니다.

cvs 의 표준의 명령 옵션 중 1 개 -m 가 이용 가능합니다: 로그 메세지를 -m 로 지정하지 않다고(commit 에서의 같게) 메세지를 입력할 수 있도록(듯이) 에디터가 기동됩니다.

게다가 3 개(살)의 특별한 옵션이 있습니다.

`-d' (을)를 사용해, 각 파일의 최종 갱신 일시가 체크인의 일자와 시각으로서 사용되도록 지시할 수 있습니다.

`-b branch' (을)를 사용해 제일 레벨의 브랜치(branch)를 `1.1. 1'이외에

`-I name' (을)를 사용해 import 중에 무시되어야 할 파일명을 지정할 수 있습니다. 이 옵션은 반복해 지정할 수 있습니다. 어떠한 파일도 무시되지 않는다 (디폴트로 무시되는 것이라도) 같게 하려면 , `-I ! '(와)과

log [-l] rlog-options [files. . . ]
  이하가 필요: 리포지터리(repository), 작업 디렉토리.
이하를 변경: 아무것도 변경하지 않습니다.
동의어: rlog
files 의 로그 정보를 표시합니다. rlog 의 옵션 중(안)에서도 유용한 것으로 해서는, 다음의 것이 있습니다: 헤더 (태그의 정의를 포함하지만, 로그의 대부분은 생략 된다) 마셔 표시한다 -h ; 특정의 리버젼 또는 리버젼의 범위에서 로그를 선택한다 -r; 그리고 특정의 일시 또는 시각의 범위를 선택하는 -d 가 있습니다. 완전한 설명은 rlog(1) (을)를 참조해 주세요. 이 명령은 -l 옵션이 지정되어 있지 않으면, 디폴트로 재귀적으로 일합니다.
rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules. . .
  이하가 필요: 리포지터리(repository).
이하를 변경: 아무것도 변경하지 않습니다.
동의어: patch
2 개의 릴리스간의 patch(1) 파일을 Larry Wall 씨의 포맷으로 작성합니다. 그것은 직접 patch 프로그램에 입력할 수 있는 것으로, 낡은 릴리스를 새로운 릴리스에 갱신한다 위해(때문에) 사용할 수 있습니다. (이것은 직접 리포지터리(repository)를 참조하기 위해(때문에), 이에 앞서 checkout 할 필요가 없는, 얼마 안되는 cvs 명령 중 1 개입니다. ) 차분 출력은 표준 출력 디바이스에 보내집니다. (표준의 -r-D 옵션을 사용해) 1 개(살) 또는 2 개의 리버젼 또는 일시의 임의의 편성을 지정할 수 있습니다. 만약 리버젼 또는 일시가 1 개 밖에 지정되지 않으면 그 리버젼 또는 일시와 그 시점에서의 RCS 파일의 ``head''리버젼의 차분이 패치 파일에 반영됩니다.

만약 소프트웨어 릴리스에의 영향이 복수 디렉토리에 건너간다면, 낡은 소스에 패치를 맞힐 때, patch 하지만 다른 디렉토리에 놓여진 파일을 찾아낼 수 있도록(듯이), -p 옵션을 patch 명령로 지정할 필요가 있을지도 모릅니다.

표준 옵션의 flags -f, -l 가 이 명령로 이용 가능합니다. 그 밖에도 몇개의 특별한 옵션 플래그가 있습니다:

-s 옵션을 지정하면(자), 패치 출력이 만들어지지 않습니다. 대신에, 2 개의 릴리스간에 변경 또는 추가된 파일의 요약이 표준 출력 디바이스에 보내집니다. 이것은, 예를 들면, 2 개의 일자 또는 리버젼의 사이로, 어느 파일이 변경되었는지를 조사하는데 편리합니다.

-t 옵션을 지정하면(자), 새로운 (분)편으로부터 2 개의 리버젼의 차분이 표준 출력 디바이스에 보내집니다. 이것은 파일에의 마지막 변경이 무엇으로 있었는지를 아는데 최적입니다.

-u 옵션을 지정하면(자), 패치 출력으로서 새롭다 ``unidiff''포맷을 사용해 문맥 차분으로 합니다.

희망한다면, -c (을)를 사용해 명시적으로 `diff -c' 형식의 문맥 차분을 지정할 수 있습니다 (이쪽이 디폴트입니다).

release [-dQq] modules. . .
  이하가 필요: 작업 디렉토리.
이하를 변경: 작업 디렉토리, 역사 로그.
이 명령은 `cvs"'checkout' 의 효과를 안전하게 캔슬하게 되어 있습니다. cvs (은)는 파일을 잠그지 않기 때문에, 엄밀하게는 이 명령을 사용할 필요는 없습니다. 단지 작업 디렉토리를 삭제해도 상관하지 않습니다. 그러나 잊고 있을지도 모르는 변경을 잃는 위험이 있어, 그리고 cvs 역사 파일에는 버리게 된 체크아웃의 기록은 남지 않습니다.

`cvs release' 사와 이러한 문제를 회피할 수 있습니다. 이 명령은 이하의 점을 체크합니다: 위탁되어 있지 않은 변경이 존재하지 않는 것, cvs 의 작업 디렉토리의 바로 윗쪽 또는 내부로부터 실행하고 있는 것, 파일이 기록된 리포지터리(repository)가 모듈 데이타베이스에 정의된 리포지터리(repository)와 같은 것, 입니다.

이러한 조건이 모두진이라면 `cvs release' (은)는 그 실행 기록 (의도적으로 체크아웃을 삭제한 증거)을 cvs 의 역사 로그에 남깁니다.

-d 플래그를 사용해 소스의 작업용 카피를 release 가 성공하면(자) 삭제하도록(듯이) 지시할 수 있습니다.

remove [-lR] [files. . .]
  이하가 필요: 작업 디렉토리.
이하를 변경: 작업 디렉토리.
동의어: rm, delete
이 명령을 사용해, files 를 소스 리포지터리(repository)로부터 삭제한다 작정(생각)인 것을 선언할 수 있습니다. 대부분의 cvs 명령이 그렇듯이, `cvs remove' (은)는 작업 디렉토리의 파일에 작용해, 리포지터리(repository)에는 직접은 작용하지 않습니다. 안전 기구로서 우선 지정하는 파일을 작업 디렉토리 (으)로부터 삭제하는 일도 필요하게 되어 있습니다.

리포지터리(repository)에 commit 그리고 변경을 반영할 때까지, 파일은 실제로는 삭제되지 않습니다. commit 한 시점에서, 소스 리포지터리(repository)의 대응한다 RCS 파일이 `Attic' 디렉토리 (이것도 소스 리포지터리(repository)안입니다)에 이동 됩니다.

이 명령은 디폴트로 재귀적으로 되어 있어 물리적으로 삭제된 모든 파일이 다음의 commit 에서의 삭제되도록(듯이) 스케줄 합니다. -l 옵션을 사용하는지, 또는 실제로 삭제하고 싶은 파일만을 지정하는 것으로, 이 재귀를 억제할 수 있습니다.

rtag [-falnRQq] [-b] [-d] [-r tag | -D date] symbolic_tag modules. . .
  이하가 필요: 리포지터리(repository).
이하를 변경: 리포지터리(repository).
동의어: rfreeze
이 명령을 사용해, 리포지터리(repository)중의 특정의, 명시적으로 지정된 소스 버젼에 상징적 태그를 할당할 수 있습니다. `cvs rtag' (은)는 리포지터리(repository)의 내용에 직접 작용합니다 (이에 앞서 checkout 할 필요는 없습니다). 작업 디렉토리의 내용에 근거해 태그를 붙이는 버젼을 선택하려면 , 대신에 `cvs tag' (을)를 사용합니다.

일반적으로, 태그 (자주 소프트웨어 배포물의 상징적인 이름이기도 하다)는 삭제되어야 하는 것이 아닙니다. 그러나 완전하게 쓸모없게 되어 버린 상징적인 이름을 삭제하는 경우 (예를 들면, 알파 릴리스의 경우등)의 수단으로서 -d 옵션이 준비되어 있습니다.

`cvs rtag' (은)는 벌써 존재하는 태그를 이동하지 않습니다. 그렇지만, -F 옵션이 지정되면(자) `cvs rtag' (은)는 그 파일에 이미 존재하는 symbolic_tag 의 인스턴스를 새로운 리포지터리(repository)의 버젼에 이동합니다. -F 옵션이 없는 경우, `cvs rtag' (을)를 사용해 벌써 그 파일에 존재하는 태그를 붙이려고 하면(자), 에러 메세지가 출력됩니다.

-b 옵션은 태그를 ``브랜치(branch)''태그로 해, 병행의, 독립한 개발을 가능하게 합니다. 이것은 이전에 릴리스 한 소프트웨어 배포물에의 패치를 작성하는데 가장 유용합니다.

표준의 -r-D 옵션을 사용해, 벌써 특정의 태그를 포함하고 있는 파일에만 태그를 붙일 수가 있습니다. 이 방법은 태그의 이름을 바꾸는데 사용할 수 있겠지요: 낡은 태그로 지정되는 파일에게만 태그를 붙여 그리고 낡은 태그를 삭제하면, 확실히 같은 파일로 낡은 태그를 새로운 태그로 옮겨놓을 수가 있습니다.

rtag (은)는 디폴트로 재귀적으로 실행해, 인수로 지정했다 modules 의 모든 서브 디렉토리에 태그를 붙입니다. 이 동작을 톱 레벨의 디렉토리에 제한하려면 표준의 -l 옵션을 지정합니다. 또 명시적으로 재귀를 지정하려면 -R 를 지정합니다.

모듈 데이타베이스에서는 태그가 지정되었을 때에 반드시 실행된다 프로그램을 지정할 수 있습니다. 자주 있는 사용법은, 흥미를 가지고 있다 그룹에 전자 메일을 보낸다고 하는 것입니다. 만약 그 프로그램을 우회도로 하고 싶은 경우는, 표준의 -n 옵션을 사용합니다.

-a 옵션을 사용하면(자) `Attic' 안의 지정된 태그를 포함한 삭제된 파일을 rtag 의 대상으로 할 수 있습니다. 태그는 그러한 파일로부터 삭제되어 개발의 진전에 따른 상징적 태그의 재이용에 편리하게 됩니다 (그리고 파일은 이후의 배포물로부터 삭제됩니다).

status [-lRqQ] [-v] [files. . . ]
  이하가 필요: 작업 디렉토리, 리포지터리(repository).
이하를 변경: 아무것도 변경하지 않습니다.
files 의 현재 상태에 대해, ``sticky''태그, 일자, -k 옵션을 포함한, 소스 리포지터리(repository)에 관한 간결한 리포트를 표시합니다. (``sticky''옵션은 리셋트 할 때까지 `cvs update' 하지만 어떻게 일하는지를 규정합니다. `cvs update -A. . . '의

이 명령을 이용해, 작업용 소스 디렉토리에서의 `cvs update' 에 의한 잠재적인 영향을 예측할 수도 있습니다. 만약 files 를 명시적으로 지정하지 않으면 cvs 가 작업 디렉토리에 둔 모든 파일에 대해 리포트가 표시됩니다. 이 검색의 범위를 (그 서브 디렉토리는 아니고) 커런트 디렉토리 인 만큼 제한하려면 , 표준의 -l 옵션 플래그를 사용합니다. -R 옵션에 의해, 명시적으로 재귀적인 스테이터스 리포트를 지정할 수도 있습니다.

-v 옵션을 지정하면(자) RCS 파일의 상징적 태그도 표시되게 됩니다.

tag [-lQqR] [-F] [-b] [-d] [-r tag | -D date] [-f] symbolic_tag [files. . . ]
  이하가 필요: 작업 디렉토리, 리포지터리(repository).
이하를 변경: 리포지터리(repository).
동의어: freeze
이 명령은, 작업 디렉토리에 가장 가까운 리포지터리(repository)의 버젼에 상징적 태그를 붙이기 위해서(때문에) 사용합니다. rtag 를 사용했을 때와 같이, 태그는 리포지터리(repository)에 직접 붙여집니다.

태그의 사용법의 하나는, 프로젝트의 소프트웨어 동결일이 왔을 때에 개발중의 소스의 ``snapshot''를 기록한다고 하는 것입니다. 동결한 날의 다음에 버그가 수정되면(자), 그러한 변경된 릴리스의 일부가 되는 소스에만 재차 태그를 붙일 필요가 있습니다.

상징적 태그는 어느 파일의 어느 리버젼이 소프트웨어 배포물을 작성할 때에 사용되었는지를 항구적으로 기록하는 의미가 있습니다. checkout, export, update 명령은, 태그를 붙인 릴리스와 완전히 같은 것을, 릴리스의 태그가 붙여진 이후로 파일이 변경, 추가, 삭제되었는지 어떠했는지를 신경쓴다 무사히, 장래의 언제라도 꺼내는 것을 가능하게 합니다.

표준의 -r-D 옵션을 사용해, 벌써 특정의 태그를 포함하고 있는 파일에만 태그를 붙일 수가 있습니다. 이 방법은 태그의 이름을 바꾸는데 사용할 수 있습니다. 즉, 낡은 태그로 지정되는 파일에게만 태그를 붙여 그리고 낡은 태그를 삭제하면, 확실히 같은 파일로 낡은 태그를 새로운 태그로 옮겨놓을 수가 있습니다.

-r 또는 -D 플래그에 가세해 -f 플래그를 지정하면(자), 명령행으로 지정한 파일로 낡은 태그를 가지고 있지 않은가 지정된 일시에 존재하지 않았던 것에도 태그를 붙입니다.

디폴트 (-r 또는 -D 플래그가 없는 경우)에서는, 버젼은 명시적으로 지정되는 것이 아니라, 암묵중에 작업 파일의 역사의 cvs 레코드로부터 놓칩니다.

`cvs tag -d symbolic_tag. . . ' (으)로 하면(자), 지정한 상징적 태그가 추가되는 것이 아니라 삭제 됩니다. 경고 : 태그를 삭제하기 전에 그 근거를 확실히 확인해 주세요. 이것은 효율적으로 일부의 히스토리 정보를 버립니다만, 나중이 되어 그 정보가 중요했다고 판명될지도 모르기 때문입니다.

`cvs tag' (은)는 벌써 존재하는 태그를 이동하지 않습니다. 그렇지만, -F 옵션이 지정되면(자) `cvs tag' (은)는 그 파일에 이미 존재하는 symbolic_tag 의 인스턴스를 새로운 리포지터리(repository)의 버젼에 이동합니다. -F 옵션이 없는 경우, `cvs tag' (을)를 사용해 벌써 그 파일에 존재하는 태그를 붙이려고 하면(자) 에러 메세지가 출력됩니다.

-b 옵션은 태그를 ``브랜치(branch)''태그로 해, 병행해, 독립한 개발을 가능하게 합니다. 이것은 이전에 릴리스 한 소프트웨어 배포물에의 패치를 작성하기 위해서 가장 유효합니다.

통상, tag (은)는 서브 디렉토리에 건너 재귀적으로 실행합니다. 이것은 표준의 -l 옵션을 사용해 억제할 수 있습니다. 명시적으로 재귀를 지정하려면 -R 를 사용합니다.

update [-ACdflPpQqR] [-d] [-r tag|-D date] files. . .
  이하가 필요: 리포지터리(repository), 작업 디렉토리.
이하를 변경: 작업 디렉토리.
당신이 공유의 리포지터리(repository)로부터 사적인 소스의 카피를 작성하기 위해서 checkout (을)를 실행한 후도, 다른 개발자는 공유의 소스에의 변경을 계속하겠지요. 가끔, 개발 과정에서 적당할 때에, 작업 디렉토리내로부터 update 명령을 사용하는 것으로, 마지막에 checkout 또는 update 하고 나서 소스 리포지터리(repository)에 등록된 변경을, 당신의 변경과 융합시킬 수가 있습니다.

update (은)는 진행 상황을 파일 마다 1 행 표시하는 것으로 계속 알립니다. 각 행의 선두에는 이하의 `U A R M C ? ' 의 어느쪽이든 1 캐릭터가 있어, 파일 상태를 나타내고 있습니다:

U file file 는 리포지터리(repository)에 관해서 최신에 되었습니다. 이것은 리포지터리(repository)에는 존재하지만 당신의 소스에는 없는 것, 및 당신은 변경하고 있지 않지만 리포지터리(repository)의 최신 리버젼은 아닌 것에 관해서 행해집니다.
A file file 는 소스의 당신의 사적인 카피에 추가 된 것으로, file 에 대해서 `cvs commit' (을)를 실행했을 때에 소스 리포지터리(repository)에 추가됩니다. 이것은 해당 파일을 commit 할 필요가 있다고 하는 조언입니다.
R file 이것은 소스의 당신의 사적인 카피로부터 file 가 삭제 되고 있어 file 에 대해서 `cvs commit' (을)를 실행하면(자) 소스 리포지터리(repository)로부터 삭제되는 것을 나타냅니다. 이것은 해당 파일을 commit 할 필요가 있다고 하는 조언입니다.
M file 당신의 작업 디렉토리의 file 는 변경 되고 있습니다. `M' (은)는 작업중의 파일에 대해 2 개 상태 중 1 개를 나타냅니다: 리포지터리(repository)중의 대응하는 파일은 변경되지 않고, 당신의 파일은 마지막에 보았을 때대로 되어 있다. 또는, 당신의 카피 같이 리포지터리(repository)의 것도 변경되고 있지만, 그러한 변경은 충돌하는 일 없이 무사하게 당신의 작업 디렉토리에 융합 (merge) 되었습니다.
C file file 에의 당신의 변경과 소스 리포지터리(repository)로부터의 변경과의 융합을 시도하는 동안에 충돌 (conflict) 가 검출되었습니다. 현재 file (당신의 작업 디렉토리의 카피)는 2 개의 버젼을 merge 한 결과가 되어 있습니다. 변경되어 있지 않은 당신의 파일의 카피도 작업 디렉토리에, `. #file.version'라는 이름으로 놓여집니다. 여기서 version (은)는 당신의 변경한 파일의 출발점이 되었다 리버젼입니다. (어떤 종류의 시스템에서는, `. #' 그리고 시작되는 파일은 며칠이나 액세스 되지 않으면 자동적으로 삭제되므로 주의해 주세요. 만약 원의 파일의 카피를 취해 둘 생각이라면, 이름을 바꾸어 두는 것이 좋을 것입니다. )
? file file 가 당신의 작업 디렉토리에 있습니다만, 소스 리포지터리(repository)의 어떤 것과도 대응하고 있지 않고, cvs 가 무시하는 파일의 리스트에도 없습니다 (-I 옵션의 설명을 참조해 주세요).

 

-A 옵션을 이용해 sticky 인 태그, 일자, -k 옵션을 리셋트 할 수 있습니다. (-r, -D, -k 옵션의 어느쪽이든을 사용해 작업 파일의 카피를 얻으면(자), cvs 는 대응하는 태그, 일자, kflag 를 기억해, 이후의 update 로 그것을 계속 사용합니다. -A 옵션을 사용해 cvs 에 그러한 지정을 잊게 하는 것으로, 파일의 ``head''버젼을 꺼냅니다).

-jbranch 옵션은, 변경 결과의 리버젼과 베이스로 한 리버젼의 사이에서의 변경을 merge 합니다 (예를 들면, 만약 태그가 브랜치(branch)를 가리키고 있다면, cvs (은)는, 그 브랜치(branch)로 행해진 모든 변경을 당신의 작업 파일에 merge 합니다).

2 개의 -j 옵션을 지정하면(자), cvs (은)는 2 개(살)의 각각의 리버젼간에서의 변경을 merge 합니다. 이것은 특정의 변경을 작업 파일로부터 ``삭제''하는데 사용할 수 있습니다. 예를 들면, 파일 foo.c 가 리버젼 1.6 을 베이스로 하고 있어, 1.3 으로 1.5 의 사이에 행해진 변경을 삭제하고 싶으면, 다음과 같이 합니다:

example% cvs update -j1. 5 -j1. 3 foo.c # 차례로 주의...

더해, 각 -j 옵션에는 옵션으로, 브랜치(branch)와 사용하는 경우에, 일자 지정을 포함하는 것이 가능해, 선택하는 리버젼을 지정했다 일자의 범위내에 제한할 수 있습니다. 옵션의 일자는 코론 (:)을 태그에 붙이는 것으로 지정합니다.

-jSymbolic_Tag:Date_Specifier

-d 옵션을 사용하면(자), 만약 작업 디렉토리에 없는 디렉토리가 리포지터리(repository)에 있으면 작성합니다. (통상, update 는 작업 디렉토리에 벌써 등록되어 있는 디렉토리와 파일에만 일합니다. ) 이것은 최초의 checkout 이후에 작성된 디렉토리를 갱신하는데 유용합니다. 그러나 불행하게도 부작용이 있습니다. 만약 작업 디렉토리를 만들 때에 신중하게 리포지터리(repository)중의 특정의 디렉토리를 제외했다 (모듈명을 사용했는지 명시적으로 필요한 파일과 디렉토리를 명령행으로 지정했는지의 어느쪽이든으로) (으)로 하면(자), -d 그리고 갱신하면(자) 그러한 불필요할지도 모르는 디렉토리가 가능하게 됩니다.

-I name 를 사용하면(자), update 때, 이름이 name 에 부합 한다 (작업 디렉토리의) 파일을 무시합니다. 명령행으로 -I 를 2 회 이상 지정하는 것으로, 복수의 무시하는 파일을 지정할 수 있습니다. 디폴트로, update 는 있는 패턴에 이름이 매치 하는 파일을 무시합니다; 무시되는 파일명의 최신 리스트에 대해서는, (이 메뉴얼 페이지의 관련 항목의 마디에 기술되어 있도록(듯이)) Cederqvist 저의 메뉴얼을 참조해 주세요.

어느 파일도 무시하지 않게 하려면 `-I ! ' (을)를 사용합니다.

로컬로 수정한 파일을, 리포지터리(repository)상의 깨끗한 파일로 덧쓰기하려면 , `-C' (을)를 사용합니다 (수정된 파일은 `. #file.revision'에 보존됩니다).

표준의 cvs 명령 옵션 -f, -k, -l, -P, -p, -rupdate 로 사용 가능합니다.

관련 파일

보다 상세한 cvs 서포트 파일의 정보에 대해서는 cvs(5) (을)를 참조해 주세요.

홈 디렉토리의 파일:
.cvsrc cvs 의 초기화 파일. 이 파일의 행은 각 cvs 명령의 디폴트의 옵션의 지정에 사용할 수 있습니다. 예를 들면 `diff -c' 이렇게 말하는 행은 `cvs diff' 에 대해서, 명령행으로 건네받은 옵션에, 항상 -c 옵션이 더해져 건네받는 것을 지정합니다.
.cvswrappers
  리포지터리(repository)의 파일 CVSROOT/cvswrappers 로 지정되어 있다 물건에 가세해 사용되는 나팔을 지정합니다.
작업 디렉토리의 파일:
CVS cvs 관리 파일의 디렉토리. 삭제 해서는 안됩니다.
CVS/Entries
  작업 디렉토리의 파일의 리스트와 상태.
CVS/Entries.Backup
  `CVS/Entries'의
CVS/Entries.Static
  플래그: `cvs update' 그리고 그 이상 엔트리를 추가하지 않습니다.
CVS/Root
  체크아웃 했을 때의 리포지터리(repository) ( CVSROOT ) 위치에의 패스명. CVSROOT 환경 변수가 설정되어 있지 않은 경우, 이 파일이 대신에 사용됩니다. 이 파일의 내용과 CVSROOT 환경 변수가 차이가 난다고 경고 메세지가 나옵니다. CVS_IGNORE_REMOTE_ROOT 환경 변수가 설정되어 있으면(자), 이 파일은 덧쓰기되는 일이 있습니다.
CVS/Repository
  소스 리포지터리(repository)중의 대응하는 디렉토리에의 패스명.
CVS/Tag
  디렉토리 마다의 ``sticky''태그 또는 일자 정보를 보관 유지하고 있습니다. 이 파일은 -r 인가 -D (을)를 checkout 또는 update 명령로 지정해, 파일이 지정되지 않았을 때에 작성/갱신됩니다.
CVS/Checkin.prog
  `cvs commit'시에
CVS/Update.prog
  `cvs update'시에
소스 리포지터리(repository)중의 파일:
$CVSROOT/CVSROOT
  리포지터리(repository) 전체의 관리 파일의 디렉토리.
CVSROOT/commitinfo, v
  `cvs commit' 의 리퀘스트를 선별하는 프로그램을 등록합니다.
CVSROOT/cvswrappers, v
  파일을 리포지터리(repository)에 체크인 그리고 리포지터리(repository)로부터 체크아웃 할 경우에 사용된다 cvs 나팔 명령을 등록합니다. 나팔은 파일 또는 디렉토리가 CVS 로 입출력될 때에 처리를 실시하는 것을 가능하게 합니다. 용도는 여러 가지 있습니다만, 그 하나로서 C 의 파일을 체크인 하기 전에 재포맷 해, 리포지터리(repository)중의 코드의 외형을 가지런히 한다고 하는 것이 있습니다.
CVSROOT/editinfo, v
  `cvs commit' 의 로그 엔트리의 편집/확인용 프로그램을 등록합니다.
CVSROOT/history
  cvs 처리의 로그 파일.
CVSROOT/loginfo, v
  `cvs commit' 의 로그 엔트리를 파이프로 건네주는 프로그램을 등록합니다.
CVSROOT/modules, v
  이 리포지터리(repository)중의 모듈을 정의합니다.
CVSROOT/rcsinfo, v
  `cvs commit' 조작중에 사용하는 템플릿에의 패스명을 등록합니다.
CVSROOT/taginfo, v
  `cvs tag' (와)과 `cvs rtag' 에서의 확인/로그 채집을 위한 프로그램을 등록합니다.
MODULE/Attic
  삭제된 원시 파일을 위한 디렉토리.
#cvs.lock
  소스 리포지터리(repository)에 미묘한 변경을 실시하고 있을 때 cvs 하지만 작성하는 락 디렉토리.
#cvs.tfl.pid
  리포지터리(repository)의 일시적인 락 파일.
#cvs.rfl.pid
  읽기 락.
#cvs.wfl.pid
  기입 락.

환경 변수

CVSROOT
  cvs 소스 리포지터리(repository)의 루트에의 풀 패스명 ( RCS 파일이 보존되고 있는 장소)를 지정합니다. 이 정보는 대부분의 명령의 실행으로 cvs 로부터 참조할 수 없으면 안됩니다. 만약 CVSROOT 하지만 설정되어 있지 않은지, 그것을 덧쓰기 지정하고 싶은 경우는, 명령행상에서 줄 수가 있습니다: `cvs -d cvsroot cvs_command. . . ' 만약 cvs 바이너리의 컴파일시에 올바른 패스가 지정되어 있다면 CVSROOT (을)를 설정하지 않아서 상관하지 않습니다.
CVSREAD
  이것이 세트 되고 있으면(자), checkout (와)과 update (은)는 작업 디렉토리의 파일을 읽어내기 전용으로 할 수 있도록 노력하겠습니다. 이것이 세트되어 있지 않을 때는, 디폴트에서는 작업 파일의 변경이 허가됩니다.
CVSREADONLYFS
  이것이 세트 되고 있으면(자), -R 옵션이 가정되어 cvs 의 동작이 읽어내기 전용 리포지터리(repository) 모드가 됩니다.
RCSBIN co(1) (이)나 ci(1) 그렇다고 했다 RCS 의 프로그램이 놓여져 있는 장소에의 풀 패스명을 지정합니다 (CVS 1.9 또는 그 이전).
CVSEDITOR
  commit 안에 로그 메세지의 기록에 사용되는 프로그램을 지정합니다. 설정되어 있지 않으면 VISUAL (와)과 EDITOR 의 환경 변수가 (이 순서로) 시험 받습니다. 어느 쪽 도 설정되어 있지 않으면, 시스템 의존의 디폴트 에디터 (예를 들면 vi) 하지만 사용됩니다.
CVS_IGNORE_REMOTE_ROOT
  이 변수가 세트 되고 있으면(자) cvs (은)는 CVS/Root 파일중의 리모트의 리포지터리(repository)에의 참조를 모두 무시합니다.
CVS_OPTIONS
  cvs 의 디폴트 옵션을 지정합니다. 이러한 옵션은, 스타트 업 파일 (~/.cvsrc)의 읽기전으로 해석됩니다. 또, 명령행 파라미터에 의해 명시적으로 덧쓰기 가능합니다.
CVS_RSH
  cvs 서버를 개시할 경우에 사용하는 리모트 쉘 명령의 이름을 결정합니다. 이 변수가 설정되어 있지 않은 경우는 `ssh' 하지만 사용됩니다.
CVS_SERVER
  cvs 서버 명령의 이름을 지정합니다. 이 변수가 설정되어 있지 않은 경우는 `cvs' 하지만 사용됩니다.
CVSWRAPPERS
  `cvswrappers' 스크립트는, 리포지터리(repository)의 CVSROOT/cvswrappers (와)과 유저의 홈 디렉토리의 ~/.cvswrappers 에 포함되는 디폴트의 나팔에 가세해 변수 CVSWRAPPERS (을)를 참조해, 나팔 파일의 이름을 결정합니다.

저자

Dick Grune
  comp.sources.unix 에 포스트되어 1986 년 12 월의 릴리스 volume6 에 거둘 수 있었던 오리지날의 cvs 셸 스크립트판의 저자. cvs 의 충돌을 해결하는 알고리즘의 대부분을 작성했습니다.
Brian Berliner
  cvs 프로그램 자신의 코딩과 디자인을 1989 년 4 월에, Dick 에 의한 오리지날을 베이스로 해 실시했습니다.
Jeff Polk
  Brian 를 도와 cvs 의 모듈과 vender 브랜치(branch)의 서포트를 디자인했습니다. 그리고 checkin(1) 셸 스크립트 ( `cvs import'의 의 저자이기도 합니다.
여기에 쓰기에는 많은 사람이 그 밖에도 있습니다.
 

관련 항목

CVS 의 가장 포괄적인 메뉴얼은 Per Cederqvist 등에 의한 Version Management with CVS 입니다. 시스템에 따라서는, info cvs 명령로 열람할 수 있거나 cvs.ps (postscript), cvs.texinfo (texinfo 의 소스), cvs.html 가 이용 가능할지도 모릅니다.

CVS 의 갱신, 문서에 관한 새로운 정보, CVS 관련의 소프트웨어, CVS 의 개발등에 대해서는, 아래와 같이를 봐 주세요: http://www.cyclic.com http://www.loria.fr/~molli/cvs-index.html

ci(1), co(1), cvs(5), cvsbug(8), diff(1), grep(1), patch(1), rcs(1), rcsdiff(1), rcsmerge(1), rlog(1).

일본어 번역

노쿠비관고(h-nokubi@nmit.mt.nec.co.jp): FreeBSD 용으로 번역
사카이 쥰 상속인(sakai@jp.freebsd.org): FreeBSD 판의 교정

\*(Dt CVS (1)

tail head cat sleep
QR code linking to this page


Ben Bullock이 유닉스 매뉴얼 페이지에서 서비스에 대한 의견을 주시기 바랍니다. Privacy policy.

The wonderful thing about standards is that there are so many of them to choose from.
— Grace Murray Hopper