버전 컨트롤 시스템 황당

버전 컨트롤 명령어를 사용하면서 이해가 힘들었던 몇가지,

• 왜 cvs merge는 merge하지 않는 걸까?
• 왜 svn move는 move하지 않는 걸까?
• 왜 git revert는 revert하지 않는 걸까?

merge는 또 다른 modify로 기록될 뿐이며, move는 delete와 add로 기록될 뿐이다.

cvs/subversion에 익숙해 지고 나서 착각하기 쉽지만 git revert는 로컬 변경사항을 버리는 명령이 아니다.  명령어부터 시작해서 지난 버전컨트롤 프로그램들의 관례를 무시한 git, 알아갈 수록 당황스럽다.

glibc 2.7

당장 눈에 보이는 건 이 정도.

리눅스 커널 2.4 지원 중단
- 과거에 80386에 대한 지원 중단이라든지, 마이너 아키텍쳐에 대한 사실상의 지원 중단, 몇몇 아키텍쳐에서 바이너리 호환성 깨는 등등 호환성 문제에서 바람잘날 없던 glibc가 이번엔 커널 2.4에 대한 지원을 중단했다.

번역 보충
- 게으른 glibc 메인테이너 덕분에, (그리고 제대로 안정된 릴리즈가 없었던 까닭에) Translation Project에 몇년간 번역문을 요청하지 않고 있다가 최근에야 새로 번역문을 업데이트했다.

SVN branching/tagging

왜 CVS에서 한 개의 이름으로 표현되었던 branch와 tag가 SVN에서는 repository의 directory copy로 바뀐 걸까?  branch/tag/merge가 난무하는 프로젝트에서는 이렇게 branch와 tag에 사용자가 정의한 policy가 동원되어야 하는 점은 큰 불편으로 다가온다.  예를 들어 SVN 매뉴얼의 가이드라인을 따라서 branch를 /branches, tag를 /tags에 copy한다고 할 때, 무슨 branch가 있는 지 살펴본 다음 어떤 branch와 trunk 사이의 diff를 뽑아내고 싶다라면

svn info (URL이 뭐더라?)
svn ls svn+ssh://server.name/project/branches/ (무슨 branch가 있더라?)
svn diff svn+ssh://server.name/project/branches/branch-stable svn+ssh://server.name/project/trunk

문제는 branch/tag/merge와 관련된 작업을 하기 위한 모든 명령에 URI를 입력해야 한다는 점이다. 그리고 매번 이 project가 branch/tag에 어떤 copy policy를 쓰고 있는지 상기해야 한다.

svn merge svn+ssh://server.name/project/tags/branch-stable-merged-YYYYMMDD \
        svn+ssh://server.name/project/branches/branch-stable

merge할 때도 역시 repository의 위치와 project의 tag/branch policy를 머리속에 떠올리면서 절대 URI를 입력해야 한다. merge한 포인트가 어디인지 기록이 남지 않는다는 (그래서 별도 tag로 남기기도 하는) 점은 CVS랑 똑같으니까 어쩔 수 없다고 해도, 더 명령을 입력하기 불편해졌다.


애초부터 tag와 branch가 directory와 copy라는 단일한 기능으로 커버한다는 게 어색한 이야기이다. CVS에서는 분명한 branch와 tag 기능들을 (CVS의 branch가 딱히 쓰기 좋은 것도 아니지만) SVN에서는 directory 구조와 copy로 일반화하면서 구분이 없어지고 사용자의 재량에 맡겨 버리고 말았다. 왜 사용자가 tag되어 있는 파일들을 checkout받아서 고쳐서 커밋할 수 있는 걸까?  왜 branch 아래에 있는 디렉토리를 다른 branch로 mv할 수 있는 걸까?  물론 이렇게 쓰면 안 되지만, 이렇게 쓰면 안 된다는 정책을 소프트웨어에서 제공하는 게 아니라 사용자의 정책에 맡겨 놓는 바람에 사용하기가 복잡해졌다.

CVS에서 Subversion으로 바꾸기, 좋을까

그놈 CVS가 subversion으로 전환한 이후 얼마가 지났으나 사실 큰 장점을 못 느끼는 게 사실이다.  애초에 subversion은 cvs와 같은 모델의 vc를 만들면서 cvs의 단점을 보완하는 게 목적이었고, 사용법부터 시작해서 크게 다르지 않다.  흔히 cvs와 비교해 장점이라고 하는 것들을 살펴보면:

1. renaming, file property 따위의 versioning

안정된 프로젝트일 수록 디렉토리 이름을 바꾸는 일은 그리 많지 않다.  (과거에 회사에서 오타가 섞인 이름마저 끝내 바꾸지 못했던 기억이 있다.)

2. atomic commit/tag

CVS의 commit/tag가 atomic이 아니라고 해서 문제가 될 상황도 별로 많지 않다.  오히려 (사람이 직접 신경 쓰지 않으면 해결할 방법이 없는) 논리적인 충돌이 더 많이 발생한다.

3. lightweight branching

이 부분은 서버의 로드와 관련된 것이므로, 알기 어렵다.  분명히 장점이다.

4. diff/revert에 네트워크 연결이 필요없다

이것만은 확실히 좋다는 걸 느낀다.  cvs는 diff를 할 때마다 해당 파일의 전체 내용을 전송받는데, 유럽에 있는 gnome cvs 서버에서 이 내용을 받는 건 만만치 않은 일이다.  심심풀이 해커도 그리 느끼는데 업으로 삼는 사람들은 더더욱 좋다고 생각할 듯.


subversion은 cvs와 비교해 분명한 장점이 있으나 멀쩡히 안정적으로 잘 돌아가는 닫힌 프로젝트의 vcs를 cvs에서 svn으로 바꾸는 일은 별로 추천하지 못하겠다.  옮겨가는 데 별로 무리도 없지만 얻는 장점도 별로 없기 때문이다.  (gnome처럼 vcs 이용자가 워낙 많고 세계 여기저기에 퍼져 있는 경우라면 위의 3/4 항목으로 큰 이득을 볼 수도 있겠지만)

Nexuiz - 일인칭 슈팅 게임

DDTP 번역 작업을 하는 중 우연히 Nexuiz라는 게임의 패키지 설명을 번역하게 되었다.  FPS 게임도 재미있게 했었고, 또 데비안에 들어 있는 GPL로 배포되는 게임을 안 깔아볼 이유가 없다!  (그런데 데이터 패키지 파일 하나가 무려 130메가)

딱 플레이해보면 하나부터 열까지 연상되는 게임이 "언리얼 토너먼트"였다.  분위기부터가 으슥하면서 여기저기 점프대와 워프할 수 있는 문이 보인다.  형형색색의 갑옷을 입은 미래전사들이 화면을 가르는 뿅뿅 소리를 내면서 광선으로 상대방을 가루로 만들고 다닌다.  각종 아이템으로 무기와 탄환을 먹고 체력을 회복하고 파워업을 하며 전우좌후로 여기저기 재빠르게 움직이며 상대가 보이자 마자 인정사정 보지 않고 달려들며 총부터 쏜다.

http://www.alientrap.org/nexuiz/public/2.jpg

오히려 최근 FPS의 추세는 이러한 퀘이크나 언리얼 토너먼트와 같은 게임과는 달리 사실적인 사격과 사실적인 움직임을 구현한 게임들이 주도하고 있다.  총을 한 두방만 맞아도 죽고, 총구가 흔들리고, 캐릭터나 무기에 따라 적중 확률이 달라지고, 연사보다 점사의 정확도가 높고, 총을 쏘는 자세에 따라 집탄도가 다르다.  사실적인 게 꼭 좋다기 보다는, 매니아들을 위한 게임보다는 좀 더 대중화될 수 있는 게임을 만드는 게 이익이니까. 

어쨌든 충분히 FPS를 즐길 수 있는 상당히 높은 완성도로 구현되어 있다.  멀티플레이를 위한 게임이라서 더 그럴 수도 있지만 특별히 다듬어야 할 부분이 보이지 않는다.  (하지만 괜히 싱글플레이해보려다가 꽤 높은 수준의 봇때문에 당황했다.  언리얼류에 비해서는 꽤 어렵다...) 

그나저나 이제 FPS를 할 때는 아닌가보다.  멀티플레이 해 보려고 접속하자 마자 이렇게 총도 얼마 못 쏴보고 계속 학살당하다니..  (자동 조준 기능이라도 집어 넣은 클라이언트를 쓰는 건가;;)

freedoom 센스

며칠 전에 FreeDoom을 플레이해 보게 되었다..  (둠의 엔진은 이미 오래전에 GPL로 공개되었지만 데이터인 WAD 파일은 여전히 non-free였기에 자유롭게 배포할 수 있는 데이터를 만드는 프로젝트가 FreeDoom이다.)  어차피 FreeDoom의 몬스터 동작 방식은 엔진에 코딩되어 있기 때문에 사실 맵과 그래픽만 다르고 몬스터의 동작이나 게임 방식은 똑같다.  아직 FreeDoom의 데이터는 미완성인 상태로, 아직 완성되지 않아서 치트코드를 쓰지 않고는 클리어가 불가능한 스테이지도 있고 난이도 조절이 안 된 부분도 많이 보인다.  (대체 엄폐물도 없는 좁은 통로에 Mancubus 여러마리를 놔 두면 어떻게 하라는 건지..)

Doom II를 플레이해 봤다면 마지막 보스, Icon of Sin을 기억할 것이다.  무시무시한 짐승의 모습을 하고 벽에 붙어 있으면서 마구 재생성되는 강력한 몬스터들.  유일한 클리어 방법은 로켓을 exposed brain에 정확히 꽃아 넣는 것이었다.  처음엔 타이밍을 맞추기 상당히 어려웠지만 나중에 가서는 재미를 위해 일부러 몬스터가 몇마리 생성될 때까지 기다리곤 했다.  :D  (재빠르게 두 번 꽃아 넣으면 끝나기 때문에 난이도를 높여봤자 의미가 없었다.)  재미있는 점은 둠의 IDCLIP 치트코드를 이용해 벽을 뚫고 Icon of Sin의 내부를 들여다 보면, 괴상한 얼굴이 꼬챙이에 꽃혀 있는 걸 보게 된다.  그 얼굴의 주인공은 John Romero로..  John Carmack과 함께 ID 소프트웨어를 만들었던 둠의 개발자 중의 하나이다.  (Icon of Sin이 처음 등장할 때 중얼거리는 이상한 소리는 "To win the game, you must kill me, John Romero!"라는 말을 거꾸로 한 것이다.)

FreeDoom도 몬스터 체계는 Doom과 똑같기 때문에..  30레벨에 가서 Icon of Sin을 만날 수 있었다.  Doom II와는 달리 Icon of Sin을 만나는 과정이 상당히 험난했다..  하지만 IDDQD / IDKFA 치트키를 이용해서...

그러면 과연 저 안에는 누가 있을까?  John Romero를 그려 넣지는 못했을 텐데...

이런 엉뚱한 놈들..  -_- 

(어쩌면 Icon of Sin 얼굴이 gnu같기도?)