Git, 분산버전 관리시스템(11) - Git으로 옮겨가기

1.         Git으로 옮겨가기

1.1.        SVN과 통신하기

 

서브버전 명령어에 해당하는 Git 명령어

svnadmin create	git init
svn checkout	git clone
svn update	git pull
svn add	git add
svn commit	git add git commit
svn status	git status
svn switch <branch>	git checkout <branch>
svn merge <branch>	git merge <branch>
svn revert <file>	git checkout <file>

 

CVS 명령어에 해당하는 Git 명령어

cvs –d<repo> init	git init
cvs –d<repo> checkout <module>	git clone
cvs update –dP	git pull
cvs add	git add
cvs commit	git add git commit
cvs status	git status
cvs co –r <branch>	git checkout <branch>
cvs update –j	git merge
cvs update –C	git checkout <file>

 

서브버전에서 Git으로 옮겨오는 방식에는 2가지가 있다.
첫 번째는 서브버전에서 모든 이력을 가져오고, 서브버전을 대체해서 Git을 버전 관리 시스템으로 이용하는 방식이다.

두 번째는 서브버전을 그대로 유지하고, Git을 활용해 서브버전에서 변경사항을 가져오고, 변경된 내용을 서브버전에 다시 푸싱하는 방식이다.

 

서브버전 저장소 가져오기
서브버전 저장소	git svn clone è	자신의 Git 저장소

 

서브저번 저장소를 상위 저장소로 이용하기
서브버전 저장소	git svn clone è   git svn rebase è çgit svn commit	자신의 Git 저장소

 

 

 

1.2.        git-svn 설치 확인하기

git-svn은 Git에서 서브버전 저장소와 통신할 때 사용하는 도구이다.
Git을 어떻게 설치했는지에 따라 git-svn이 이미 설치돼 있을 수도 있다.
다음 명령어를 실행하여 확인해 보자.

$ git svn –version git-svn version 1.6.0.2 (svn 1.4.4)

 

정상적인 메시지 대신 오류 메시지를 출력한다면 다음 2가지 중 하나이다.

l       Git에서 SVN이 명령어가 아니거나 치명적인 오류(fatal error)라고 알려주는 메시지.

l       SVN/Core.pm을 찾을 수 없다는 메시지

 

 

 

1.2.1.       Git 명령어가 아니거나 치명적인 오류인 경우

이 문제는 우분투의 apt-get이나 OS X의 MacPorts와 같은 패키지 관리자를 이용해 Git을 설치한 경우 흔히 발생하는데, 패키지 관리자를 통해 패키지를 설치할 때 의존 관계에 있는 패키지를 줄이려고 Git을 여러 개의 작은 패키지로 나눠두었기 때문이다.

리눅스에서 git-svn을 설치하려면 서브버전 하위 명령어를 포함하는 패키지를 찾아야 한다.
우분투에서는 apt-get을 이용해 git-svn을 지정하면 설치할 수 있다.

$ sudo apt-get install git-svn

 

2.1 ‘Git 설치하기’에서 설명한 대로 MacPorts를 이용해 설치했다면, 따로 git-svn을 설치하지 않아도 된다. 마찬가지로, 소스에서 컴파일해서 설치한 경우도 추가로 설치하지 않아도 된다.

 

 

 

1.2.2.       SVN/core.pm을 찾을 수 없는 경우

다른 오류로는 SVN/core.pm이 없다는 perl 메시지가 있으며, 설치된 서브버전에 대한 펄 바인딩이 없을 때 발생한다.

필요한 파일을 얻는 데는 몇 가지 방법이 있지만, 대부분의 경우 패키지 관리자를 이용하는 편이 가장 쉽다.

우분투에서는 누락된 페키지를 subversion-perl이라 부르며, 다음 명령어를 실행하여 설치한다.

$ sudo apt-get install subversion-perl

 

맥 사용자라면 MacPorts 패키지 관리자를 이용해 subversion-perlbindings를 설치한다.

$ sudo port install subversion-perlbindings

 

CPAN을 사용하여 펄 라이브러리를 최신 상태로 유지하고 있다면, 필요한 패키지를 바로 설치할 수 있다. 설치할 패키지는 SVN::Core이다.

$ sudo cpan install SVN::Core

 

 

 

1.3.        서브버전 저장소 가져오기

git svn clone 명령어를 이용한다는 차이를 제외하고, 기존에 Git에서 저장소를 가져오던 방식과 동일하게, 서브버전 저장소의 이력을 가져올 수 있다.

git svn clone은 서브버전 저장소의 전체 이력을 가져와서 자신의 Git 저장소에 저장한다.

 

맥에서 CPAN 사용에 주의할 사항.

필자는 MacPorts에서는 필요한 것이 모두 설치됐다고 알려주는데도 Git에서는 왜 인식하지 못하는지 이유를 알아내려고 이틀을 허비했다.
원인은 시스템에 펄 서브버전 바인딩이 2가지 버전으로 설치돼 있었기 때문이다.
오래된 버전은 처음 컴퓨터에 서브버전을 설정하면서 함께 설치되었고, 새로운 버전은 MacPorts를 이용해 설치됐다.
상황이 나빠지려고 그랬는지 문제를 파악하지도 못한 상태에서 CPAN을 통해서 하나를 더 설치해버렸다. 그래서 총 3가지 버전의 펄 서브버전 바인딩이 설치되었다.
CPAN을 통해 설치한 버전은 잘 동작했지만, Git에서 이용하려고 하면 의존성 오류가 발생했다. CPAN 라이브러리가 필요한 모든 라이브러리를 설치하지 않는다는 사실을 안 후에는 쉽게 해결할 수 있었지만, 결국 이 문제를 해결하는 데 몇 시간 이상을 소비했다.

 

서브버전 저장소를 복제할 때는 Git에 서브버전 저장소의 구조를 알려줘야 한다.
저장소가 서브버전 저장소의 레이아웃으로 권장되는 구조를 따르고 있다면, -s 매개변수를 지정해서 표준 레이아웃을 이용하고 있다고 Git에게 알려준다.

 

branches와 tag 디렉터리가 다른 위치에 있다면, -b옵션과 -t옵션을 이용해서 위치를 지정할 수 있다. 마찬가지로 트렁크가 trunk말고 다른 이름을 이용하고 있다면 -T옵션으로 위치를 지정할 수 있다.

$ git svn clone –prefix svn/ -s svn://svnrepo/sunshine …

 

저장소 크기 줄이기

100여개 이상의 커밋 이력을 포함하는 서브버전 저장소를 복제하면, 디스크 공간이 현저히 줄어드는 것을 볼 수 있다. 저장소에 수백 건을 커밋할 때와 마찬가지로, 새로 받은 서브버전 복제본에도 가능하면 빨리 git gc를 실행하여 디스크 공간을 절약하자. 저장소를 복제하고 다른 동작 없이 바로 git gc를 실행할 때는 안심하고 --aggressive 옵션을 지정해도 된다. 물론 옵션을 지정하면 시간이 걸리기는 한다. 개인적으로는 31,000개 이상의 커밋을 가진 복제된 저장소를 압축하는데 14시간 이상 소요되는 경우도 봤다.

 

서브버전은 ‘전체 이력 가져오기’와 같은 요청을 처리하지 못한다.
따라서, git-svn은 한 번에 하나의 리비전만 가져온다.
때문에 저장소가 수만 개의 이력을 포함할 정도로 크다면, 가져오는데 거의 하루 종일 걸릴 수도 있다.

앞에서는 git svn clone 명령어에 --prefix 매개변수를 포함시켰다.
--prefix 매개변수는 서브버전에서 가져온 모든 브랜치에 접두어를 추가한다.
이를 테면, 원격 브랜치의 이름 앞에 원격 저장소임을 나타내는 이름을 붙일 수 있다.
매개변수를 지정하지 않으면, 이름으로는 원격 브랜치와 지역 브랜치를 구별하기 어렵다.
--prefix 매개변수를 지정하지 않으면, git branch –a를 통해 지역 저장소와 원격 저장소를 모두 볼 때 알아보기 어려워진다.

오래된 커밋이 별로 중요하지 않다면, -r옵션을 이용해서 복제를 시작할 리비전을 지정할 수 있다. 리비전을 지정하면, 지정한 리비전의 이력만 복제하므로 이후의 변경 사항을 가져오려면 다른 명령어를 더 실행해야 한다.
프로젝트를 초기에 가져온 다음 ‘상위’서브버전 저장소에서 변경 사항을 가져올 때는 git svn rebase 명령어를 이용한다.

 

 

 

1.4.        서브버전 저장소를 최신 상태로 유지하기

현재 사용 중인 서브버전 저장소를 이용하든지, git svn clone –r …을 이용해서,
초기에 한 번 최신 사항을 가져와야 한다면,
서브버전 저장소의 변경 사항을 가져오는 2가지 방법이 있다.

첫 번째 방법은 git svn fetch이다.
이 명령어를 이용하면, 모든 원격 변경 사항을 원격 브랜치에 풀링 하지만, 로컬 브랜치와 합치지는 않는다. 이 명령어는 서브버전에 추가된 새로운 브랜치를 가져올 때도 사용한다.

둘째는 git svn rebase를 이용한 방법이며, 더 많이 사용된다.
이 명령어는 git svn fetch를 실행한 다음에 바로 git rebase를 실행하는 것과 동일하다.
명령어를 실행하면 상위 서브버전 저장소에서 모든 커밋을 가져오고 원격 브랜치에 맞춰서 현재 브랜치를 재정렬한다.

git rebase를 이용할 때와 마찬가지로, 이미 서브버전에 적용한 지역 커밋이 있다면 재정렬할 때 다시 적용하지 않으며, 작업 트리에 커밋 하지 않은 변경 사항이 있다면 git svn rebase를 실행할 수 없다.

 

이 오류는 무슨 의미지?

복제하려는 프로젝트가 서브버전 저장소의 가장 오래된 리비전에 없다면, 다음과 같은 에러가 발생한다.

W: Ignoring error from SVN, path probably does not exist: (175002): RA layer request failed: (경고: SVN에서 발생한 오류를 무시했음. 요청한 경로가 존재하지 않는 것으로 보임: ) REPORT request failed on ‘/test/!svn/bc/100’: REPORT of ‘/test/!svn/bc/100’:Could not read chunk size: Secure connection truncated (svn://svnrepo) W: Do not be alarmed at the above message git-svn is just searching aggressively for old history. (경고: 겁먹지 말 것. git-svn이 오래된 이력을 계속 찾기 때문에 나오는 메시지다)   두번째 경고 메시지에서 알 수 있듯이 걱정할 필요가 없다. git-svn은 서브버전 저장소를 복제할 때 접근할 수 있는 가장 오래된 리비전부터 요청한 코드를 포함하는 리비전을 찾을 때가지 최신 리비전 방향으로 이동한다. 경고 메시지는 단지 가장 오래된 리비전에서 요청한 코드를 찾을 수 없을 때 발생한다. 이후 복제하기로 한 프로젝트가 처음 존재하는 리비전을 찾을 때까지 계속해서 이력을 조사한다.

 

서브버전 저장소 복제하기의 대안

서브버전 저장소를 복제하는 일은 시간이 많이 걸린다.
필자는 복제하는 데에 20시간 이상 소요된 큰 저장소를 복제한 적이 있다.
기존의 저장소가 크다면 복제를 시작하기 전에 먼저 부트스트랩(bootstrap) 저장소를 찾아보자.

부트스트랩 저장소는 추적하려는 서브버전 저장소를 복제한 Git 저장소를 tar 파일로 묶어둔 형태다. 오픈 소스 커뮤니티에서는 부트스트랩 저장소를 보통 매주 업데이트한다.

부트스트랩 저장소를 이용하면, git svn rebase를 실행해서 부트스트랩 저장소 이후의 변경 사항만 가져오면 된다. 전체 이력을 복사하는 것보다 훨씬 빠르다.

 

 

 

1.5.        변경 사항을 SVN에 푸싱하기

다른 유명한 분산 버전 관리 시스템과 비교해서, Git이 가지는 장점은,
서브버전 저장소에서 풀링 해 올 수 있을 뿐만 아니라,
변경한 내용을 다시 푸싱할 수도 있다는 점이다.

변경 사항을 다시 서브버전 저장소로 푸싱하는 명령어는 git svn dcommit이다.
이 명령어를 이용하면, 자신의 컴퓨터에서 커밋한 내용을 서브버전 저장소에 하나씩 커밋한다.

커밋하는 동안 지역 커밋이 서브버전 서버에서 가져온 정보를 반영하도록 복사본을 재정렬한다.
git svn rebase와 마찬가지로 git-svn이 이미 동기화된 이력을 파악하기 쉽게 해준다.

-n 옵션을 지정하면 ‘가상 수행(dry run)’을 수행할 수도 있는데, 이를 통해 모든 이력과 서브버전 저장소에 보낼 수 있는 커밋 목록을 확인할 수 있다.

 

 

 

1.6.        CVS에서 가져오기

CVS 저장소를 Git으로 변환하는 가장 확실한 방법은,
cvs2svn 명령어를 이용해서 CVS 저장소를 먼저 서브버전 저장소로 변환하는 것이다.
cvs2svn는 CVS 저장소를 서브버전 저장소로 변환하는 도구이다. (http://cvs2svn.tigris.org)

Git에는CVS 저장소를 가져오기 위한 git cvsimport 도구도 있지만, cvs2svn 명령어를 이용하는 편이 더 안정적이기에 cvs2svn의 사용법만 다룬다.

 

변환을 시작하려면 CVS 저장소에서 리비전 제어 시스템(Revision control System, RCS)파일을 가져와야 한다.
이 파일들을 가져온 다음 cvs2svn 도구를 이용해 svn 덤프 파일로 변환한다.

$ cd /path/to/cvs-rcs-files $ cvs2svn –dumpfile=svndump

 

도구를 이용해 덤프 파일을 생성하면, svndumpfilter와 같은 불필요한 데이터를 필터링 해준다.
새로운 svndump가 준비됐다면, 이 정보를 가져와서 서브버전 저장소를 생성한다.
svnadmin create 명령어를 이용해서 새로운 저장소를 생성한다.

$ cd .. $ svnadmin create ./tmpsvn $ svnadmin load ./tmpsvn < /path/to/cvs-rcs-files/svndump

 

tmpsvn 저장소로 전체 이력을 불러오는데 성공했다면, 이제 Git 저장소로 가져올 준비가 됐다. tmpsvn 저장소의 내용을 Git 저장소로 옮기는 절차는 10.1 ‘SVN과 통신하기’에서 다룬 내용과 동일하다.

$ git svn clone file:///path/to/tmpsvn

 

출처 : http://youmin3.egloos.com/1990844