mercurial session
WoC2007 Snowcamp "머큐리얼을 이용한 오픈소스 개발" 세션
ToC
- version control에 대한 이해
- mercurial 소개
- mercurial 실습
- mercurial s/w
- reference to
version(revision) control system의 이해
-
왜 사용하는가?
- 개발자들은 서로 물리적으로 떨어진 공간에서 작업을 하게 된다. (오픈소스 프로젝트)
- 모든 변경에대하여 누가,언제,무엇을 왜 바꾸었는지에 대한 모든 이력이 남는다.
- 협업을 해 나가면서 일어나는 혼란(conflict)를 편리하게 해결(resolve)할 수 있다.
- 실수를 했을 경우 언제든지 예전상태로 되돌려 놓을 수 있다.
- 여러 버전으로 프로젝트를 진행해 나갈 수 있다(branch)
-
version control system은
- 만들어진 모든 산출물들간의 이력을 '버전'이라는 태그로 유지 관리한다. 따라서 버전관리 시스템 사용자들은 개별 파일들에 대한 히스토리를 탐색하여 이전 상태로 돌아가 작업을 할 수 있으며, 이러한 과거 상태들 중 임의 버전들 간의 diff를 통해 통합(merge)를 할 수도 있다. 이러한 일들을 가능케 하기 위해서 버전관리시스템은 각 변경시점에 대한 로그를 유지한다. 또한 물리적으로 분산된 여러 사용자들이 한개의 프로젝트를 체계적으로 개발해 나가는데 있어서 최적의 환경을 구현해준다.
-
Trends of VCS
- 1세대 : 단독 컴퓨터에서 한개 파일에 대한 관리
- 2세대 : 중앙집중형 버전관리, 특정 중앙서버에 소스 저장소가 있고 그곳에서 통함 관리
- 3세대 : peer-to-peer 버전관리/분산형. 개개의 컴퓨터에서 소스저장소가 있어서 버전관리를 하며 다른 사람들의 코드와 통합을 해야할 경우 웹을 이용.
-
분산형 VCS이 오픈소스프로젝트개발에 좋은 점.
- 커미터와 일반 개발자 사이에서의 오픈소스프로젝트에 대한 완전한 개방.
- 버전관리소프트에 대한 다양한 관점
-
version control 용어를 통한 version control system의 이해
-
revision
- 모든 변경에 대한 내역. 각 revision은 고유 번호를 가짐
-
repository
- 버전관리를 하기위해 사용되는 소스파일들의 원격 저장소로 모든 파일들에 대한 모든 개정 이력을 가지고 있는 공용 데이터베이스
-
workspace(working directory)
- repository와는 별개로 개발자의 개발환경의 로컬에 존재하는 저장소. repository와의 sync는 개발자의 능동적인 행동으로 이루어진(버전관리)
-
check-in
- working directory 의 변경된 내용을 repository에 반영하여 새로운 버전으로 복사/저장.
-
check-out
- repository의 가장 마지막 revision을 나의 working directory애 복사.개별 파일에서부턴 저장소 단위로도 check-out을 받을 수 있음.
-
commit
- check-in과 동일. 보통 이 용어로 많이 쓰임.
-
update
- check-out 후에 repository에 있는 변경 이력을 workspace(working directory)에 방영시킴.
-
conflict
- 다수의 개발자들이 repository에 있는 동일 파일에 대한 변경 후 commit을 했을 경우 conflict가 발생. 발생했을 경우 커밋이 되지 않으며, 해결 후 커밋이 가능. 해결은 개발자에게 위임
-
resolving
- conflict가 일어난 후 개발자는 직접 파일을 적절하게 수정한다음 resolving을 해야지만 그 파일에 대한 변경(commit)이 허락됨
-
merging
- 동일 파일에 대한 변경이 다수의 개발자들의 working directory에서 이루어졌을때 이것을 합치는 작업. 이로 인해서 여러 개발자들이 동시에 작업이 가능함. merging은 행 단위로 일어나며
만약 같은 행에 대하여 동시에 변경이 가해졌을 경우 conflict가 발생함.
- 동일 파일에 대한 변경이 다수의 개발자들의 working directory에서 이루어졌을때 이것을 합치는 작업. 이로 인해서 여러 개발자들이 동시에 작업이 가능함. merging은 행 단위로 일어나며
-
- 일반적인 버전관리 주기
-
check out
- repository에 있는 소스 코드를 workspace(working directory)에 복사
-
변경
- workspace에 있는 소스코드를 변경. 개발.
-
update
- commit작업을 하기 전에 repository와의 conflict방지를 위해서 update 수행
-
commit
- workspace에서 이루어진 변경 이력을 repository에 반영
-
merging
- 만약 동시에 commit이 이루어 졌다면 merging작업.
mercurial
머큐리얼은
- 버전관리 툴
- 크로스 플랫폼
- 파이썬으로 개발됨(diff 부분은 C)
- 기본적으로 command line interface(대표 명령어는 수은(mercurial) 의 기호인 hg)
- GNU General Public License 하에 배포된 오픈소스
머큐리얼이 추구하는 것?
- high performance
- scalability
머큐리얼이 추구하는 것을 성립시키는 특징들
- 서버가 불필요(serverless)
- 분산 버전관리 시스템(distributed)
- 플레인 텍스트 및 바이너리를 견고히 지원
머큐리얼과 타 VCS와의 차이(장점)
Used by
- OpenSolaris
- OpenJDK
- Mozilla
- NetBeans
mercurial에 처음으로 프로젝트 올리기!
- 우선 서버로부터 아무것도 없는 빈 프로젝트를 로컬에 받아옵니다.
- mercurial이라는 프로젝트 디렉토리가 생겼을 것입니다. 이 디렉토리에 올리고자 하는 모든 파일들을 복사합니다. 복사한 후 커밋을 한 후, 서버에 push를 하여 올립니다. push를 하면 id와 pass를 물어봅니다. mercurial생성시 받은 id와pass를 입력하세요.
- hg add *
- hg commit -m 'import project'
- hg push
mercurial 실습
-
목표
- http://labs.openmaru.com/hg/mercurial 에 있는 프로젝트(?)에 자신의 이름을 남기는 !기여!를 해보자.
-
순서
- 조를 짜자 : 한 조에 5명씩
- 커미터를 정하자 : 한 조에 1명씩(가위바위보)
-
mercurial설치
-
소스코드 받아오기(check out)
- hg clone http://labs.openmaru.com/hg/mercurial
-
소스코드 고치기 - WoCSession.java
- //session.insertMember(new Mentee("이름","전화번호","자기소개"));
- 이 부분을 자신의 소개로 고치고 주석을 제거해주세요.
-
소스코드 커밋하기
- hg commit -m "code modified"
- 이때 커밋은 http://labs.openmaru.com/hg/mercurial 에 되는 것이 아니라 자신의 local 저장소에 되는 것입니다. 왜냐하면, 앞서 설명드린 바와 같이 머큐리얼은 분산VCS이기때문에 source repository가 여러분들의 local에 존재하기 때문입니다.
-
실제 프로젝트에 기여하기
- 프로젝트에 기여하기 위해서는 실제 프로젝트의 저장소(http://labs.openmaru.com/hg/mercurial)에 올려야 합니다. 올리기 위해서는 push권한을 가지고 있어야 합니다. 이 권한을 가지고 있는 자가 바로 커미터입니다.
- 자신이 커미터라면 "실 프로젝트에 반영(기여)하기" 단계에 가서 바로 실제 프로젝트의 저장소에 반영을 하면 됩니다.
- 자신이 커미터가 아니라면, 변경된 무언가를 커미터에게 전달해야겠죠. 몇가지 방법이 있지만, 실제로 많이 사용되는 patch를 만드는 방식을 설명하겠습니다.
다음과 같은 명령어로 패치를 만듭니다.
- hg patch tip > patch.diff
- 생성된 patch.diff 파일을 커미터에게 전달합니다.
- patch.diff를 받은 커미터는 다음과 같은 방식으로 변경사항을 workspace에 반영합니다.
- hg import patch.diff
- 커미터는 이렇게 workspace에 반영을 한 후 실 프로젝트 서버(http://labs.openmaru.com/hg/mercurial)에 적용해도 될정도로 문제가 없는지 파악한후 문제가 없으면
다음과 같이 실 프로젝트 서버에 적용을 합니다. 프로젝트에 적용을 할때는 머큐리얼 서버 담당자로 부터 받은 계정(아이디/비번)이 필요합니다.
- hg push http://labs.openmaru.com/hg/mercurial
- 자~! 반영이 잘 되었는지 직접 http://labs.openmaru.com/hg/mercurial를 clone해와서 실행을 시켜보죠~! 여기 모든 참석자 분들의 리스트를 띄어 볼까요?
- hg clone http://labs.openmaru.com/hg/mercurial
javac WoCSession.java
java WoCSession
- 리스트가 떴나요? 따로 적어두고 친해지세요~^^
- 수고하셨습니다~!
mercurial software
refer to
- mercurial home
- mercurial cheetsheet - pdf
- mercurial menual - pdf
- http://en.wikipedia.org/wiki/Mercurial_%28software%29
- 머큐리얼 한글 메뉴얼
- http://kldp.org/node/88260
- http://wiki.kldp.org/wiki.php/MercurialQuickStart
- http://hwsj.tistory.com/264
Comments (0)