Subversion

You are currently browsing articles tagged Subversion.

게임 개발이란 굉장히 소모적인 작업이다. 일단 게임 어플리케이션을 만들어야 하고, 또 그 위에 컨텐츠까지 생산해내야 하기 때문이다.

일반적인 응용 어플리케이션 개발은 프로그램을 만들어서 사용자들이 컨텐츠를 생산해내는데 도움을 주는 것이 목적인 반면, 게임과 같은 엔터테인먼트 관련 개발은 프로그램은 물론 컨텐츠 생산까지 개발자가 다 하고 사용자는 오로지 그것들을 소비하기만 하기 때문이다.1

게임을 만드는 일에서 프로그래머가 해야 하는 일은 크게 두가지로 분류할 수 있다.

우선 첫번째로 외부 고객, 즉 유저들을 상대로 하는 부분들을 제작하는 일이다. 보통 바깥에서 보면 개발의 전부라고 생각할 수 있는 부분이다. 예를 들면 프로그램의 UI 작성, 내부 로직 작성 등이다.

그리고 앞서 이야기했던 게임 제작의 특성상 두번째 일이 추가된다. 즉, 내부의 고객(기획파트와 그 외 파트들)을 상대로 하는 부분들을 만드는 일이다. 예를 들면 새 캐릭터를 추가하는 캐릭터 에디터, 맵을 만드는 맵 에디터, 퀘스트를 작성하는 퀘스트 에디터, 몬스터를 추가하는 몹 에디터 등이 있을 것이다.

이러한 내부 고객용 프로그램의 경우 비 프로그래머가 사용하는 프로그램이긴 하지만, 굉장히 특정한 소수의 사람들만 사용하기 때문에 불특정 다수가 사용하는 게임처럼 자동 업데이트를 공들여 만드는 것은 약간 비효율적이다. 하지만 그렇다고 매 변경시마다 바이너리를 수동으로 배포하는 방식은 문제가 많다.

  1. 소스 변경시 개발자가 빌드해서 새 바이너리를 만든다.
  2. 이 바이너리를 사용자들이 접근할 수 있는 공간에 업로드 한다.
  3. 바이너리가 변경되었음을 사용자들에게 알린다.
  4. 사용자들은 새 바이너리가 릴리즈 된 것을 확인하고 다시 다운로드를 한다.

보다시피 이런 일련의 과정은 자동화가 되어 있지 않아서 위 과정 중 한 군데에서만 문제가 발생해도 제대로 작동하지 않는다. 그리고 바이너리의 버전 관리가 되지 않으므로 문제가 발생하면 원인을 파악하기 어렵다.

원활하고 신속한 게임 개발을 위해서는 내부툴들의 자동 업데이트 기능이 필수적이다. 하지만 앞서 이야기했듯이 이 자동 업데이트 기능은 게임 어플리케이션의 그것과는 달리 특정 소수의 인원만 사용하므로 게임 패처처럼 잘 만들 필요는 없다.

따라서 이 포스트의 초점은 쓸만한 자동 업데이트 기능을 간단하게 구현하는 것에 있다.

Read the rest of this entry »


  1. 그래서 현실 세계에서는 UCC 나 MOD 같은 개념들이 등장하고 있다. []

Tags: , ,

Subversion 1.5.0 이 6월 19일자로 릴리즈 되었습니다. 이전 버전인 1.4.6 은 2007년 12월 20일에 릴리즈 되었으니 약 6개월만입니다.

이번에 새로 추가된 기능은

  1. 머지 트래킹 (Merge tracking)
  2. 부분 체크아웃 (Sparse checkouts)
  3. 인터랙티브 컨플릭 해결
  4. 체인지리스트 (Changelist)
  5. svn:externals 개선
  6. 그 외 여러가지 개선 및 버그 수정

입니다. 자세한 내용은 SVN 1.5 릴리즈 노트를 참고하면 됩니다.

서버 1.5.0 버전에 대응되는 윈도우용 클라이언트인 TortoiseSVN 1.5.0 도 21일자로 나왔습니다.  자세한 클라이언트 변경 사항은 TSVN 1.5 릴리즈 노트 를 참고하면 됩니다.

이번 릴리즈에서는 머지 트래킹이 주요 추가 내용입니다. 써보신 분들은 아시겠지만 섭버전은 브랜치에서 리비전을 올려가며 작업하다가 다시 트렁크로 merge 를 해도 트렁크에서 로그를 보면 merge 한 바로 그 리비전만 보이고 브랜치에서 작업한 리비전들은 보이지 않습니다.

그래서 브랜치에서 여러명이 작업하다가 트렁크로 merge 를 하면 변경된 코드에 대한 문의가 merge 를 한 유저에게로만 오는 경우가 많습니다. :( 실제로 그 유저는 merge 만 했을 뿐이라도 트렁크에서 로그를 보거나 blame 을 하면 그 리비전만 보이기 때문이죠.

http://tortoisesvn.tigris.org/tsvn_1.5_releasenotes.html

위 스크린샷이 바로 이전 버전에서 로그를 봤을 때 상황입니다. r9 와 r14 사이에 브랜치에서 작업이 있었음에도 트렁크에서 로그를 보면 r14 에서 merge 한 기록만 보입니다. 따라서 그 사이에서 변경된 코드 블럭의 경우 블레임을 하면 r14 로만 나오게 됩니다.

http://tortoisesvn.tigris.org/tsvn_1.5_releasenotes.html

위 스크린샷은 이번에 1.5.0 에서 추가된 머지 트래킹 기능을 사용했을 때의 모습입니다. TSVN 1.5 에서는 로그창에서 왼쪽 하단의 체크박스를 체크함으로써 볼 수 있습니다. 이전 스크린샷과는 달리 r11 에서 r13 까지 브랜치에서 작업한 리비전들도 같이 보여집니다.

그리고 체인지리스트는 아래와 같이 한 working copy 에서 파일별로 그룹을 나누어서 커밋 등을 할 때 작업 단위를 분리하는 기능입니다. 여러가지 작업을 동시에 할 때 유용합니다. Read the rest of this entry »

Tags:

Subversion 의 로그 메시지를 수정하는 기능은 기본적으로 막혀있습니다.

왜냐하면 로그 메시지를 바꾸는 일은 리비전이 남지 않기 때문입니다. 즉, 데이터를 날릴 수 있는 가능성이 존재하므로 이는 롤백조차 리비전으로 남기는 섭버전의 타임머신 철학상 그다지 추천할만한 기능이 아닙니다.

그래서 섭버전은 로그 메시지 수정, 즉 리비전 속성 변경 (revision properties change) 의 경우에는 무조건 pre-revprop-change 훅 스크립트가 있어야 실행됩니다. 만약 스크립트가 없다면 로그 메시지를 수정할려고 할 때 아래와 같은 에러 메시지를 볼 수 있습니다.

섭버전 배포판에 기본적으로 pre-revprop-change 예제가 포함되어 있지만 이것은 리눅스 계열의 쉘 스크립트이기 때문에 윈도우 기반에서는 따로 작성해야 합니다.

정말 새로 작성해야 될까 하는 의문을 품고 섭버전 유저들의 제 2의 바이블인 TortoiseSVN 의 도움말을 뒤져보다 보면 “4.3. Hook Scripts” 섹션에서 아래와 같은 윈도우 용 pre-revprop-change.bat 예제를 찾을 수 있습니다.

rem Only allow log messages to be changed.
if "%4" == "svn:log" exit 0
echo Property '%4' cannot be changed >&2
exit 1

pre-revprop-change.bat

이렇게 pre-revprop-change.bat 를 만들어주면 로그 수정이 가능해집니다.

trac 을 같이 쓰고 있을 때

trac 을 같이 사용하고 있다면 로그 수정을 해도 트랙의 Timeline 이나 Browse Source 에서 표시되는 섭버전 로그들은 수정되지 않는다는 것을 발견하게 될 겁니다. 따라서 로그 수정시 trac 과 자동으로 싱크를 맞춰주는 기능을 구현해줘야 합니다.

이 기능은 수정된 로그를 반영하는 것이므로 pre-revprop-change 가 아닌 post-revprop-change 에 구현해야 합니다. 안그러면 수정된 로그 메시지가 반영되지 않습니다. trac 과 subversion 다시 싱크 맞추기를 참고해서 아래와 같이 post-revprop-change 스크립트를 만들어주면 됩니다.

rem Only resync when log messages are changed.
if "%4" == "svn:log" C:\Python25\scripts\trac-admin.exe (trac_proj_dir) resync

post-revprop-change.bat

파이썬 경로와 (trac_proj_dir) 은 자신의 환경에 맞게 수정해주도록 합니다. :)

Tags: , ,