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가 발생함.
• 일반적인 버전관리 주기

• 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에 처음으로 프로젝트 올리기!

• 우선 서버로부터 아무것도 없는 빈 프로젝트를 로컬에 받아옵니다.

1. hg clone http://labs.openmaru.com/hg/mercurial

• mercurial이라는 프로젝트 디렉토리가 생겼을 것입니다. 이 디렉토리에 올리고자 하는 모든 파일들을 복사합니다. 복사한 후 커밋을 한 후, 서버에 push를 하여 올립니다. push를 하면 id와 pass를 물어봅니다. mercurial생성시 받은 id와pass를 입력하세요.

1. hg add *
2. hg commit -m 'import project'
3. hg push 

mercurial 실습

• 목표

  • http://labs.openmaru.com/hg/mercurial 에 있는 프로젝트(?)에 자신의 이름을 남기는 !기여!를 해보자.

• 순서

  • 조를 짜자 : 한 조에 5명씩
  • 커미터를 정하자 : 한 조에 1명씩(가위바위보)

• mercurial설치

  • http://www.selenic.com/mercurial/wiki/index.cgi/Download

• 소스코드 받아오기(check out)

  1. hg clone http://labs.openmaru.com/hg/mercurial

• 소스코드 고치기 - WoCSession.java

  1. //session.insertMember(new Mentee("이름","전화번호","자기소개")); 
  • 이 부분을 자신의 소개로 고치고 주석을 제거해주세요.

• 소스코드 커밋하기

  1. hg commit -m "code modified"
  • 이때 커밋은 http://labs.openmaru.com/hg/mercurial 에 되는 것이 아니라 자신의 local 저장소에 되는 것입니다. 왜냐하면, 앞서 설명드린 바와 같이 머큐리얼은 분산VCS이기때문에 source repository가 여러분들의 local에 존재하기 때문입니다. 

• 실제 프로젝트에 기여하기

  • 프로젝트에 기여하기 위해서는 실제 프로젝트의 저장소(http://labs.openmaru.com/hg/mercurial)에 올려야 합니다. 올리기 위해서는 push권한을 가지고 있어야 합니다. 이 권한을 가지고 있는 자가 바로 커미터입니다.
  • 자신이 커미터라면 "실 프로젝트에 반영(기여)하기" 단계에 가서 바로 실제 프로젝트의 저장소에 반영을 하면 됩니다.
  • 자신이 커미터가 아니라면, 변경된 무언가를 커미터에게 전달해야겠죠. 몇가지 방법이 있지만, 실제로 많이 사용되는 patch를 만드는 방식을 설명하겠습니다.
    다음과 같은 명령어로 패치를 만듭니다.
  1. hg patch tip > patch.diff
  • 생성된 patch.diff 파일을 커미터에게 전달합니다.
  • patch.diff를 받은 커미터는 다음과 같은 방식으로 변경사항을 workspace에 반영합니다.
  1. hg import patch.diff
  • 커미터는 이렇게 workspace에 반영을 한 후 실 프로젝트 서버(http://labs.openmaru.com/hg/mercurial)에 적용해도 될정도로 문제가 없는지 파악한후 문제가 없으면
    다음과 같이 실 프로젝트 서버에 적용을 합니다. 프로젝트에 적용을 할때는 머큐리얼 서버 담당자로 부터 받은 계정(아이디/비번)이 필요합니다.
  1. hg push http://labs.openmaru.com/hg/mercurial
  • 자~! 반영이 잘 되었는지 직접 http://labs.openmaru.com/hg/mercurial를 clone해와서 실행을 시켜보죠~! 여기 모든 참석자 분들의 리스트를 띄어 볼까요?
  1. hg clone http://labs.openmaru.com/hg/mercurial
     javac WoCSession.java
     java WoCSession
  • 리스트가 떴나요? 따로 적어두고 친해지세요~^^
  • 수고하셨습니다~!

mercurial software

• mercurial GUI tools 

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