OddPoet's βetalog

부서에서 소스형상관리툴로 PVCS를 사용하고 있었다.
써본사람은 알겠지만 Subversion과 비교하면 도대체가 장점을 찾기 힘든 툴이다.
오래된 툴이라서 그러려니 하고 살아보려 했으나, 요상한 Archive 관리에 파일 삭제와 관련된 문제들,
그리고 결정적으로 매우 조악한 수준의 eclipse plugin은 내 인내력의 한계를 넘어버렸다.

개인적인 용도로 Subversion을 몇년동안 써왔던 터라 Subversion으로 옮겨가자고 건의도 해봤지만,
오픈소스 프로그램에 대한 근거없는 불신과 관리조직의 회사표준툴 강요 등의 이유로 묵살당했다.
결국 시스템 전체 소스들을 Subversion으로 이주시키는 것은 포기하고(50여개의 서브프로젝트들로 구성),
내가 관리하는 5개 서브프로젝트들만 PVCS에서 Subversion으로 옮겼다.

소스의 현재 상태만 옮겨간다면야 그리 복잡할 것도 없는 작업이지만, 3년 가까이 쌓여있는 변경 히스토리를 통채로 가지고 가야 하기 때문에 마이그레이션 작업은 필수적이었다.

구글링을 통해 PVCS -> Subversion 컨버전 툴을 2개 정도 찾을 수 있었다.

1. SVNImporter
SVNImporter는 Eclipse subversion plugin인 Subversive를 만드는 Polarion.org의 프로젝트로,
PVCS 뿐만아니라 CVS, VSS, ClearCase, MKS, StarTeam 등의 리파지토리로 부터 Subversion으로의
conversion을 지원한다. (jdk1.4 이상에서 실행)
SVNImporter는 PVCS에서 리비전 별로 파일들을 받아서, subversion dump file로 만든 후에
'svnadmin load' 명령을 사용하여 subversion 리파지토리에 로드하는 방법으로
리비전 히스토리를 컨버전한다.

2. pvcs2svn.pl
Thomas Wolkenstein이 만든 perl script이다.
이 스크립트는 PVCS에서 파일을 get 한 후에, subversion에 commit하는 것을 리비전 별로 반복적으로
수행하므로써 컨버전 작업을 수행한다.

속도면에서는 SVNImporter의 경우가 다소 빠른 것 같았으나, 한글이름의 파일들을 정상적으로 처리하지
못하는 문제가 있었다. 그리고 변경 comment의 한글 일부가 깨지는 문제가 있었다.
반면, pvcs2svn.pl 스크립트는 한글이름의 파일에는 문제가 없으나, SVNImporter와 마찬가지로
comment의 한글 일부가 깨지는 문제가 있었다.

컨버전 시간은 프로젝트의 파일 수, 파일 리비전의 수, 파일의 크기 등에 영향을 받을 수 있으니
단정적으로 말할 수는 없지만 Subversion으로 변환 후 리비전 번호가 1000, 파일 갯수가  7000여개 정도되는
프로젝트의 경우 컨버전에 10시간이 넘는 시간이 소요되었다. (pvcs2svn.pl로 작업)

마이그레이션에 소요됐던 시간과 수고는 Subversion으로 옮겨온 후에 얻을 수 있는 이점을 생각하면,
충분히 상쇄될만 하니 개인적으로는 만족스럽다. 다만 최근 회사에서 PVCS대신 Dimension으로
소스형상관리툴을 교체해나가고 있는데, 어떻게 버텨야 할지가 문제......

최근 Ruby와 Rails를 공부하고 있는데, Ruby의 Symbol이라는 게 잘 이해가 되지 않았다.
기존에 내가 배웠던 언어들 중에는 그와 비슷한게 없었던 터라 도무지 감이 안 잡혔다.
구글링 결과 대략 감을 잡았으니, Ruby Symbol의 정체에 대해 간단히 정리해본다.

String vs. Symbol

puts :hello　 #symbol
puts "hello" 　 #string

위의 두 문장 모두 'hello'라는 문자열을 출력한다. 이런 이유로 Symbol을 String의 오리타입(duck type) 클래스로 오해하기도 한다. 하지만, 아래 코드를 보면 알겠지만, Symbol은 절대로 String이 아니다.
puts :hello.size　 # NoMethodError
puts :hello[0,2]　 # NoMethodError
puts "hello".size　 #5
puts "hello"[0,2]　 # "he"

Symbol이 String의 사촌 쯤으로 오해받는 것은 Symbol을 immutable string 용도로 많이 사용하기 때문이다. 나처럼 Lisp 언어에 대한 경험이 없는 사람이라면, 대충 예제코드들을 보면서 그렇게 생각할 가능성이 매우 높다.

Java등의 언어에서는 String이 immutable Class이므로 Hash의 키로 사용했을 경우 그다지 문제될 것이 없지만, Ruby에서는 String이 mutable class이므로 Hash의 키로 쓰일 때, 키로 쓰인 객체의 값이 변경될 경우 rehash 메소드를 호출해줘야 하는 경우가 생긴다. 따라서 Ruby에서는 가능하면 Hash의 키로 String대신 Symbol을 쓰는 것을 선호한다. 그러니 나 같은 놈은 처음부터 Symbol = Immutable String 으로 이해하고는 그 뒤부터는 미궁으로 빠져버린다.

Symbol을 그 정의대로 '이름을 가진, 그리고 그 이름에 대해서 유니크(unique)한 객체'이다. String이 따옴표로 둘러쌓인 문자열로 표기되듯이, Symbol은 :name의 형태로 표기되며, name이 문자열로 표기될 수 있지만 그 자체는 String이 아닌 Symbol객체이다. 그리고 아래 코드에서 보여지듯이, 특정 이름을 갖는 Symbol 객체는 유일하다.
puts :hello.class 　 # Symbol
puts "hello".class 　 # String
puts :hello.object_id == :hello.object_id 　 # true
puts "hello".object_id == "hello".object_id 　 #false


Symbol의 용도

그렇다면 Symbol은 언제 사용하는 것이 좋을까?
Ruby의 String이 mutable 객체이므로, 성능상의 이유로 Symbol이 immutable string의 대체물로 사용되곤 하지만, Symbol은 garbage collect가 되지 않으므로 자칫하면 메모리 누수가 발생할 수 있음을 유의해야 한다. 대충 아래와 같은 용도로 사용하는 것이 추천된다.

1. 메소드의 argument list에 옵션 키워드의 이름
   link_to 'Show', :action=>'show', :id= product
2. C의 enum와 같은 값을 표현할 때
   /* C code*/
enum BugStatus { OPEN, CLOSED };
BugStatus original_status = OPEN;
BugStatus current_status = CLOSED;

# Ruby
original_status = :open
current_status = :closed
3. Hash의 키 이름
   foo = {
:host => 'localhost',
:port => 80 }
   

특히 위 3번의 예는 String을 사용하는 아래의 예보다, Symbol이 사용자 정의 식별자(user defined identifier)로 사용됨으로써 코드의 의도가 명확히 드러난다 점에서도 더 낫다.
foo = {　 # String을 사용한 경우, 속성-값의 관계가 덜 명확해 보인다.
'host' => 'localhost',
'port' => 80}

Reference

• 13 Wasy of Looking at a Ruby Symbol
• Symbols are not immutable strings
• Using Symbols for wrong reason
• Understanding Ruby Symbols