레이블이 VCS인 게시물을 표시합니다. 모든 게시물 표시
레이블이 VCS인 게시물을 표시합니다. 모든 게시물 표시

2013년 1월 10일 목요일

Subversion에서 Private Depot 사용하기(Mercurial을 이용)

Private Depot 얼마나 오랫동안 꿈꾸어 오던 것인지... -_-;

SVN과 같이 중앙 public depot을 사용하면 잘못된 코드를 체크인 했을때 그 때문에 피해를 입는 사람이 많다. 고로 제대로 작동안하는 코드를 집어넣으면 졸 욕을 쳐먹는다 -_-;

그래서 보통 코드가 제대로 돈다고 확인할때까지, 또는 코드를 보기 좋게 잘 다듬을 때까지 check-in을 안하곤 한다..... 이것의 문제는 한 1주일정도 체크인 없이 로컬 컴퓨터에서 계속 작업하는 경우가 있는데.. 그러다가 어느순간...

'아... 3일전에 만들어놨다가 제대로 안돌아서 지워버린 코드를 다시 쓰고 싶은데...'

라는 후회가 드는 경우가 있다는 것.... 이걸 미리 체크인 해놓았다면 단순히 버전 되돌리는 걸로 끝날 일... 중앙 depot시스템 때문에 못한거지... 퉤... - _-;

그래서 git이나 mercurial(hg)등의 DVCS (Distributed Version Control System)이 나름 각광을 받고 있었다. 하지만 게임개발을 하는 나에게 중앙서버가 없는 중구난방식의 분산 방식은 좀 별로였다. 내가 원한 것은 완전한 분산방식이 아니라.... 개인(private) depot에는 아무때나 내 맘대로 체크인 해놓고..... 나중에 준비가 되면 여태까지 해왔던 일들을 한번에 중앙 서버에 집어넣는 거였다. 한마디로 매일밤

"오늘까지 한 일. 어쩌구 저쩌구... 현재 컴파일은 안됨 ㅋㅋ"

이라는 commit log를 작성하고 싶었다고나 할까....

Perforce에서는 perforce sandbox를 사용하여 이 문제를 해결했었다. 하지만 Subversion을 사용할 때는 마땅히 어떻게 할 방법이 없었다. git-svn이라던가 hg-svn 등의 놈들이 있지만 이렇게 그다지 믿음이 가지 않았다. 난 모든간에 단순하고 간단한걸 좋아해서 이렇게 두가지 기능을 대충 합치는 프로그램을 안좋아한다. 사용하다가 말도 안되는 곳에 문제가 생겨서 골치만 아픈 경우가 너무 많거든...

하드디스크에 체크아웃 해둔 SVN 루트 디렉토리에 git이나 mercurial을 local depot를 만드는 법도 한 때 생각해봤으나.. 각 폴더마다 들어가 있던 .svn 폴더때문에 그것도 쉽지 않았다... 그래서 한동안 손을 들고 있었으나... 이게 왠일 SVN 1.7부터 폴더 구조가 바뀌었다. 이젠 루트폴더에 .svn폴더 하나만 넣는다.

이거 때문에 신나서 재빨리 시도해보았다.. 잘된다.. ㅠ_ㅠ

방법은 간단... 난 mercurial(HG)를 사용했다. 윈도우즈에서 git 쓸려면 SSH 설치며 뭐며 머리가 졸라 아픈데.. mercurial은 그냥 TortoiseHg만 깔면 된다.. 다른거 신경쓸거 하나도 없다...

모든간에 졸 간단한 방법:
  1. SVN checkout이 되어있는 root folder로 간다. SVN 버전이 1.7 미만이라면 1.7이상으로 업글한 뒤 현재 checkout 되어있는 소스트리를 최신버전으로 업데이트 해줘야 한다.
  2. 빈공간에 오른쪽 버튼을 누르고 TortoiseHg > Create Repository Here를 해준다.

  3. Init 대화창이 나오면. 뭐 다른 거 손 볼 필요 없다. 그냥 Create를 눌러준다.
  4. 이제 모든 파일이 제대로 보인다....

  5. 이제 private depot에 체크인 할때는 Hg Commit을... 중앙 depot에 체크인할때는 SVN Commit을 해주면 된다.
아, 정말 단순하고.. 깔끔한 방법이다.... 맘에 들어.. ㅠ_ㅠ

이 방법의 단점은 mercurial로 private depot에 체크인 했던 것은 changelist description을 자동으로 복사해올 방법이 없다는건데... 음.... 난 차라리 이 방법이 낫다. 매일 일하며 체크인 해 놨던 내용들을 쭈욱 살펴보면서 요약해서 적을 수 있으니까. 중앙서버까지 mercurial로 만들어 놓으면 local depot에 체크인 했던 changelist들이 전부다 개별적으로 submit된다. 맘에 안든다.... 뭐 collapse 익스텐션을 쓰면 이것도 해결 된다지만.. 역시 기본기능이 아닌 건 사람들이 그닥 많이 사용안하니 제대로 검증되지 않아서... 골치아픈 일이 많기 마련.... 따라서 extension은 그닥 쓰고 싶지 않아.....

어쨌든 이 방법 좋다... 만세~


2012년 5월 23일 수요일

P4SandBox를 3주간 사용해본 소감

몇주전에 말씀드린 것처럼 P4SandBox를 한 3주 사용했습니다. 매우 만족스럽네요. private repo가 꽤 좋아요. 새로운 스트림(브랜치라고 생각하세요)를 만들고 여러 스트림 사이에서 switch하는것도 빠르구요. (뭐 내부적으로 당연히 Perforce의 shelve 기능을 이용하죠). 스트림을 그냥 브랜치 + 자동 shelving이라고 생각하시면 될 거 같아요.

내가 찾은 버그 하나:
  • 스트림안에서 손수(manually) shelving을 해주면 이걸 다시 unshelve 할수가 없네요 -_-; 따라서 현재 저는 스트림 안에서 아예 manual shelving을 안합니다. 작업중이던걸 shelving하고 다른 작업을 해야 한다면 그냥 간단히 새로운 스트림을 추가하고 말죠. 참고로 이 버그는 P4SandBox에서만 발생하는 버그입니다. 퍼포스의 전통적인 방법은 중앙관리방식을 쓰면 이런 문제는 없어요.
한가지 짜증나는 점:
  • copy 또는 merge(Git 에서 push/pull의 개념입니다)를 할 때 change 히스토리를 자동으로 넣어주지 않네요. Perforce측 말로는 다음 버전에 이 기능을 구현한답니다.



2012년 2월 27일 월요일

P4SandBox 쓸만해 보이는걸...?

게임개발용 버전 컨트롤 시스템으로는 Perforce만한게 없다. 바이너리 지원도 짱~ 문제는 언제나 서버에 연결되어있어야 한다는 거였는데..그래서 원격으로 작업하면 좀 느렸는데.. P4SandBox란 놈이 조만간 나온단다.. 이게 나오면 그 문제도 해결될듯 하다.

P4Sandbox는 GIT처럼 private local branching을 가능하게 해주는 것 (단 Distributed Version Control Syste 은 아니다.. 여전히 중앙관리..)

자세한 내용은 여기참조: http://www.perforce.com/blog/110826/p4sandbox-private-local-branching-distributed-dev