Java 프로젝트를 빠른 분산소스관리도구 Mercurial를 이용해 버전 관리 하기 간단버전- Windows 버전
Java 프로젝트를 빠른 분산소스관리도구 Mercurial를 이용해 버전 관리 하기 간단버전- Windows 버전 by Ko,jinhuyk
0) 환경
1) 설치하기
2) 기존에 있던 (Java) 프로젝트를 Mercurial 프로젝트로 만들기
이렇게 한뒤 다른곳에 사본을 만들거나 중앙서버로 만들곳에 사본을 만들어주는 것이 서버에 import 해주는것과 같게된다. 기존에는 서버/클라이언트 관계가 분명해서 중앙서버에만 실제리파지토리 파일이 올라가고 관련 entry 정보만 클라이언트에 있는 구조였다면 Mercurial을 각 관리위치별 클라이언트 하나하나가 바로 리파지토리 하나가 되고 이 리파지토리는 다른 곳에 http나 ssh로 공유 되는 구조로 관리되는 것이다. 특별히 서버 클라이언트가 정해지는 구조가 아니라는 점이다. 여러 리파지토리(클라이언트들)들중 하나(또는 여러개)를 서버라고 생각하면 되는 것이다.
실제로 서버 리파지토리를 구성할때 현재 내가 만든 로컬리파지토리에서 http 서버를 띄워 이곳에서 부터 clone을 만드는 방식으로 하게될 것이다.
3) 서버실행과 클라이언트 작업
4) 서버쪽에 실제 작업소스에 반영하기
5) 끝으로
간단히 PC 2대에서 각각 서버 , 클라이언트로 가상해서 기존의 소스리파지토리를 구성해서 변경된 소스의 반영을 해볼수있는 테스트수준으로 정리해보았다.
Mercurial을 분산소스관리를 지원하는 개념이라 실제 각 작업환경에 리파지토리를 갖고 있는 형태로 각 로컬내에서 commit/update를 하고 다른 서버나 pc 와는 push/pull 을 통해 동기화를 해주는 형태라고 보면된다.
이것은 본사에서 작업하던 프로그램을 (네트워크 단절, 보안, 성능 등의 이유로) 외부프로젝트로에서 분리하여 버전관리를 진행하고 다시 본사로 push해주는 것 (실제로는 변경된 부분을 뜻하는 tip 이라는 개념을 이용한 변경의 동기화를 하는 방법등도 활용하여)도 손쉽게 가능하게 해줄수있는 솔루션이 될것으로 보인다.
---------------참고자료------------------------------------
또다른 분산 소스관리도구 Arch 라고..
http://www.gnuarch.org/revc/index.html
분산소스관리에 대한 소개
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
버전관리에 대한 이해
http://betterexplained.com/articles/a-visual-guide-to-version-control/
http://www.selenic.com/mercurial/wiki/
0) 환경
1) 설치하기
윈도우즈 버전은 간단히 사이트에서 윈도우용 바이너리를 설치하면된다. 바이너리 다운로드 하기 http://mercurial.berkwood.com/
설치가 끝나면 (다른경로를 선택하지 않았다면) C:Mercurial에 설치가 되고 (path에 추가되어)cmd 화면에서 hg 명령이 실행가능해진다.
여기까지 설치끝이고
가) 사용자 명 설정
기본적으로 Mercurial에 접속하는 사용자 정보를 %USERPROFILE%Mercurial.ini 에 넣어준다.
============ 파일 - 1) %USERPROFILE%Mercurial.ini ================
===========================================================
이렇게 넣어준 파일은 commit 에 대한 기록과 Repository 로 접근 하는데 기본적인 접속 정보로 사용된다.
설치가 끝나면 (다른경로를 선택하지 않았다면) C:Mercurial에 설치가 되고 (path에 추가되어)cmd 화면에서 hg 명령이 실행가능해진다.
여기까지 설치끝이고
가) 사용자 명 설정
기본적으로 Mercurial에 접속하는 사용자 정보를 %USERPROFILE%Mercurial.ini 에 넣어준다.
============ 파일 - 1) %USERPROFILE%Mercurial.ini ================
[ui] |
이렇게 넣어준 파일은 commit 에 대한 기록과 Repository 로 접근 하는데 기본적인 접속 정보로 사용된다.
2) 기존에 있던 (Java) 프로젝트를 Mercurial 프로젝트로 만들기
가) 리파지토리준비
cvs 에 init 명령을 수행하는 것과 같은 작업이라고 보면된다. Mercurial 는 간단히 해당위치에서 'init' 명령을 실행해주면 되고 초기화된 디렉토리에 .hg 라는 디렉토리를 생성하고 메타파일들을 준비하게 된다.
============ 실행 - 1) ================
===========================================================
이렇게 해주면 기존 프로젝트 디렉토리내에 .hg 라는 간단히 리파지토리영역이 (메타정보및 commit된 파일들 보관소) 마련된다.
| pc1>cd ProjectMyProject pc1>hg init |
이렇게 해주면 기존 프로젝트 디렉토리내에 .hg 라는 간단히 리파지토리영역이 (메타정보및 commit된 파일들 보관소) 마련된다.
나) 버전관리 제외 파일 설정하기
프로젝트 소스를 관리하는 경우 해당 경로에는 바이너리나 특정 자동 생성 파일들과 같이 버전관리가 필요없는 파일또는 경로가 있게 된다. 이러한 파일을 설정하기위해서는 프로젝트의 루트 디렉토리 (.hg 디렉토리가 보이는)에 .hgignore파일을 생성해주면된다.
java 프로젝트 같은 경우 build나 bin 같은 바이너리 디렉토리가 여기에 해당 되는 경우이다.
java 프로젝트 같은 경우 build나 bin 같은 바이너리 디렉토리가 여기에 해당 되는 경우이다.
============ 파일 - 2) projectRoot.hgignore ================
===========================================================
위 파일을 만들어 넣어주면 파일에 있는 패턴에 해당되는 영역이나 파일은 add 대상에서 제외 된다.
| syntax: glob *.orig *.rej *~ *.o build/* syntax: regexp .*#.*#$ |
위 파일을 만들어 넣어주면 파일에 있는 패턴에 해당되는 영역이나 파일은 add 대상에서 제외 된다.
다) 파일들 최초 리파지토리에 저장하기
============ 실행 - 2) ================
===========================================================
============ 실행 - 2) ================
| pc1>hg add pc1>hg commit |
.hg 디렉토리안에 store 밑으로 파일들이 저장된다.
이렇게 한뒤 다른곳에 사본을 만들거나 중앙서버로 만들곳에 사본을 만들어주는 것이 서버에 import 해주는것과 같게된다. 기존에는 서버/클라이언트 관계가 분명해서 중앙서버에만 실제리파지토리 파일이 올라가고 관련 entry 정보만 클라이언트에 있는 구조였다면 Mercurial을 각 관리위치별 클라이언트 하나하나가 바로 리파지토리 하나가 되고 이 리파지토리는 다른 곳에 http나 ssh로 공유 되는 구조로 관리되는 것이다. 특별히 서버 클라이언트가 정해지는 구조가 아니라는 점이다. 여러 리파지토리(클라이언트들)들중 하나(또는 여러개)를 서버라고 생각하면 되는 것이다.
실제로 서버 리파지토리를 구성할때 현재 내가 만든 로컬리파지토리에서 http 서버를 띄워 이곳에서 부터 clone을 만드는 방식으로 하게될 것이다.
3) 서버실행과 클라이언트 작업
가) 다음은 방금 만든 리파지토리를 웹서버로 제공하기
============ 실행 - 3) ================
===========================================================
나) 다른 PC 또는 리파지토리에서 로컬 리파지토리 구성하기
============ 실행 - 3) ================
===========================================================
위는 pc1 을 서버로 하여 실행하고 pc2에서 클라이언트가 되어 서버쪽의 리파지토리에 대한 clone을 구성하게 된다. 이후 pc1 에서 작업을 하고 난뒤 pc1으로 push 해주면된다. (pc1에서 pull로 pc2의 것을 가져올수도 있다.)
다) pc2에서 소스 변경된 뒤에 서버에 반영하기
============ 실행 - 4.1) ================
===========================================================
위의 경우는 정상적인 경우이고 처음에 실행하면 다음과 같은 에러가 발생할것이다.
============ 실행 - 3) ================
| pc1>hg serve -n "MyLocalRep" -p 8001 |
나) 다른 PC 또는 리파지토리에서 로컬 리파지토리 구성하기
============ 실행 - 3) ================
| pc2>hg clone http://pc1:8001/path/ newname pc2>cd newname |
위는 pc1 을 서버로 하여 실행하고 pc2에서 클라이언트가 되어 서버쪽의 리파지토리에 대한 clone을 구성하게 된다. 이후 pc1 에서 작업을 하고 난뒤 pc1으로 push 해주면된다. (pc1에서 pull로 pc2의 것을 가져올수도 있다.)
다) pc2에서 소스 변경된 뒤에 서버에 반영하기
============ 실행 - 4.1) ================
| pc2>hg commit pc2>hg push http://pc1:8001/path/ pushing to http://pc1:8001/path searching for changes adding changesets adding manifests adding file changes added 1 changesets with 1 changes to 1 files |
위의 경우는 정상적인 경우이고 처음에 실행하면 다음과 같은 에러가 발생할것이다.
============ 실행 - 4.2) ssl required error 발생의 경우 ================
===========================================================
이것은 기본적으로는 ssl을 사용하는 프로토콜을 이용하도록 하고 있어서 발생하는 문제 이다. 파일3) 처럼 보면 push_ssl = false 해서 무시하게 할 수 도있다.
============ 실행 - 4.3) 사용자 에러 ================
===========================================================
이 에러는 사용자 인증 실패 인경우 나타나게 되는데 실제 사용자관리를 서버쪽에서 해주거나 간단하게 실험적형태로 사용해보려는 경우에는 allow_push = * 를 해주면된다.
| pc2>hg commit pc2>hg push http://pc1:8001/path/ pushing to http://pc1:8001/path searching for changes ssl required |
이것은 기본적으로는 ssl을 사용하는 프로토콜을 이용하도록 하고 있어서 발생하는 문제 이다. 파일3) 처럼 보면 push_ssl = false 해서 무시하게 할 수 도있다.
============ 실행 - 4.3) 사용자 에러 ================
| pc2>hg push http://pc1:8001/path/ pushing to http://pc1:8001/path searching for changes push not authorized |
이 에러는 사용자 인증 실패 인경우 나타나게 되는데 실제 사용자관리를 서버쪽에서 해주거나 간단하게 실험적형태로 사용해보려는 경우에는 allow_push = * 를 해주면된다.
============ 파일 - 3) projectRoot.hghgrc ================
간단하게 서버구성을 해보려는 경우에는 아래처럼 해주면된다. 실제 운영환경에서 허락된 사용자의 접근만을 허용하려는 경우에는 allow_push = 사용자명1,사용자명2 형태로 넣어주면된다.
간단하게 서버구성을 해보려는 경우에는 아래처럼 해주면된다. 실제 운영환경에서 허락된 사용자의 접근만을 허용하려는 경우에는 allow_push = 사용자명1,사용자명2 형태로 넣어주면된다.
[web] |
===========================================================
4) 서버쪽에 실제 작업소스에 반영하기
============ 실행 - 5) pc1 작업영역 소스에 반영하기 ================
| pc1>update 1 files updated, 0 files merged, 0 files removed, 0 files unresolved |
===========================================================
pc2에서 pc2로 push 해준내용은 pc2의 .hg영역에 저장되어있다. 이를 실제 작업소스에 반영하기 위해서는 다시 update를 해주어야한다.
pc2에서 pc2로 push 해준내용은 pc2의 .hg영역에 저장되어있다. 이를 실제 작업소스에 반영하기 위해서는 다시 update를 해주어야한다.
5) 끝으로
간단히 PC 2대에서 각각 서버 , 클라이언트로 가상해서 기존의 소스리파지토리를 구성해서 변경된 소스의 반영을 해볼수있는 테스트수준으로 정리해보았다.
Mercurial을 분산소스관리를 지원하는 개념이라 실제 각 작업환경에 리파지토리를 갖고 있는 형태로 각 로컬내에서 commit/update를 하고 다른 서버나 pc 와는 push/pull 을 통해 동기화를 해주는 형태라고 보면된다.
이것은 본사에서 작업하던 프로그램을 (네트워크 단절, 보안, 성능 등의 이유로) 외부프로젝트로에서 분리하여 버전관리를 진행하고 다시 본사로 push해주는 것 (실제로는 변경된 부분을 뜻하는 tip 이라는 개념을 이용한 변경의 동기화를 하는 방법등도 활용하여)도 손쉽게 가능하게 해줄수있는 솔루션이 될것으로 보인다.
---------------참고자료------------------------------------
또다른 분산 소스관리도구 Arch 라고..
http://www.gnuarch.org/revc/index.html
분산소스관리에 대한 소개
http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/
버전관리에 대한 이해
http://betterexplained.com/articles/a-visual-guide-to-version-control/
http://www.selenic.com/mercurial/wiki/