[SCM] cvs 용어및레퍼런스

[eclipse] cvs 용어및레퍼런스 

참고:http://cafe.naver.com/javastep.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=19

 

Repository

프로젝트 파일들의 모든 버전들에 대한 마스터 복사본을 저장하고 있는 중앙 집중소 (central place).

 

Workspace

repository에 저장되어 있는 파일들에 접근할 수 있는 사용자 작업 영역. 이는 프로젝트 부분에 대한 작업 수행을 위해 repository로부터의 필요한 모든 것들에 대한 로컬 복사본.

 

Check out 

Repository로부터 필요한 것들을 Workspace에 가져오는 행위. Repository로부터 check out을 수행하게 되면, workspace로 파일들의 복사본을 로컬로 가져오게 된다. 최신 버전을 요청하고 가져오는 행위라 할 수 있다.

 

Commit

로컬 workspace에서 자신이 작업하여 변경된 내용을 repository에 반영하는 과정을 말한다. 이를 수행하면 로컬 workspace의 변경 내용이 repository로 저장된다. Check in이라고도 한다.

 

Update

프로젝트에 참여하고 있는 다른 사람들 역시 repository로부터 파일들을 내려 받아 작업한 후, 그 내용들을 repository로 commit 한다. 그러나, 이러한 내용은 자신의 local workspace에 반영되어 있지 않다. 그러므로, 자신의 local workspace로 이러한 것들을 받아와야 하는데, 이를 가리켜 Update라 한다. (개념적으로는 Commit과 Update는 동일하기 때문에 이 둘을 혼용하여 사용하기도 한다)

 

Project

일반적으로 언급되는 프로젝트의 개념과 동일하다. 이러한 프로젝트는, 자신을 이루고 있는 여러 가지 구성 요소들과 함께, Repository에 통째로 저장되어 관리될 수 있다

 

Module

repository 관리자는 CVS를 사용하여 한 프로젝트를 여러 개의 비교적 독립적인 단위로 나누어 관리할 수 있는데, 이 때 나누어지는 단위를 가리키는 것이 Module이다. Module은 일련의 파일들로 구성된 그룹이며, Module의 이름을 통해 check out 할 수 있다. 서로 다른 팀간에 공유될 요소들을 구분 짓고 관리하는데 편리하게 사용될 수 있다.

 

Version

CVS는 파일 전체를 복사해서 저장하는 것이 아니라, 변경된 부분만을 저장하여 관리한다. 이 때, 이러한 변경 사항의 구분을 위해 Version이라는 것을 사용한다. 예를 들어, 한 파일을 check out하고 편집하고 commit 하게 되면, CVS는 원래 버전과 변경 사항을 포함하고 있는 버전 모두를 repository에 저장한다. CVS에서는 첫 번째 파일의 revision 번호로 1.1이 할당된다. 그런 후, 변경이 가해져서 repository로 반영될 때 마다, 1.2, 1.3, .... 과 같은 식으로 revision 번호가 할당된다.

 

Tag

일련의 파일 그룹들에 이름을 할당하기 위한 수단이다. revision 번호는 각각의 파일들에 부여되는데, 실제로 어떤 릴리즈를 구성하고 있는 파일들에 대한 revision 번호를 일일이 기억해서 다루기란 여간 어려운 일이 아니다. 가령 릴리즈 버전 1.6을 이루고 있는 파일들의 revison 번호가 1.0, 0.9 등등 다양한데, 이 중 한 파일만이 변경 작업 결과 새로운 revision 번호를 부여 받았고, 이것이 릴리즈 버전 1.7에 반영되었다면, 작업 추적을 위해 이 파일을 기억하는 것은 정말 어려울 것이다. 이럴 때, 이들 파일 그룹들에 논리적인 이름을 부여하여 참조를 하게 되면 작업이 쉬워질 텐데 이 때 사용되는 것이 바로 이 Tag라는 것이다.

 

Mainline

프로젝트에 참여하는 모든 인원들은 지속적으로 check out, 편집, commit 과정을 거치는데, 이러한 작업은 시간이 흘러가도 모든 구성원들 사이에 공유된다. 개념적으로 이러한 시간의 흐름 속에 모든 구성원들이 작업을 수행하고 이러한 작업 결과를 공유하는 중심 라인(일종의 일방 통행 1차 차선이라고 생각하면 될 것 같다)을 Mainline이라고 한다.

 

Branch

우리나라 말로 하자면, 가지, 분기, 분점 정도이다. 소프트웨어 배포 작업과 같은 중요한 작업을 수행할 때, 이를 Mainline에 직접 수행할 경우, 비효율적인 결과나 잘못된 결과를 낳을 확률이 높아진다. 이 때, Branch를 사용하게 된다. 이것은 커다란 하나의 물줄기에서 갈라져 나가는 물줄기를 연상하면 될것이다. Branch는 마치 별도로 완전히 독립된 Repository를 만드는 것과 같다.

 

Merge

Branch에서의 작업 완료를 Mainline에 반영하거나, 동일한 소스 코드 수정 시 충돌이 발생할 경우, 이를 해결하는 과정을 가리킨다.