FAQ에 이어 이 문서에 궁금한 점과 비판들을 정리해 놓았다.

• Mercurial을 안 쓰고 왜 fossil을 새로 만들었나?
  • 자체 내장된 wiki, bug tracking, single excutable file, 웹 인터페이스를 가진 DVCS가 없었기 때문에 만들었다.
• Trac대신 왜 fossil을 쓰는가?
  • Fossil은 분산 시스템이다. 네트웍이 연결안 되어 있는동안에도 ticket을 보거나 편집할 수 있다. ( 음, git나 mercurial같은 시스템에서 얻을 수 있는 장점 중에 하나여서 끌리는 feature다 )
  • Fossil은 경량이고, 프로그램 하나에 모두 포함되어 있어서 세팅이 편하다.
  • Code versioning과 wiki, ticket을 하나의 repository에 통합했다.
• 개념은 좋아보이는데, 실제 작업에 사용하는 사람이 있나?
  • 아직 git나 mercurial처럼 많은 user 층을 확보하지 못했지만, sqlite와 fossil이 fossil을 통해 document를 관리하고 있다.
• 리파리토리를 Sqlite DB와 같은 binary blob에 저장하는 게 걱정이 된다. ( 나도 또한 궁금 )
  • SQLite가 트랜잭션을 지원하기 때문에 다른 방법보다 안정적이고 안전하다.( 과연? ) 또한 내부적으로 데이타 손실을 방지하기 위한 자체 체크 루틴을 구현했다.
• VCS내에 wiki나 bugtracker를 내장하는 장점에 대해서 잘 모르겠다. - Trac같은 시스템에 비해 기능이 떨어지거나, VCS가 Subversion이나 Bazaar등에 비해 너무 무거워지는 단점이 있지 않을까? ( 궁금했던 내용 )
  • Trac이 기능이 많다는 점은 부인하지 않지만, disconnected operation이 지원되지 않는다. 나는 이것이 더 필요하다. ( 하긴 trac의 기능을 다 쓰고 있지 않잖아 )
  • 무거워진다는 점에 대해서 … Fossil은 실행파일 하나다. 이 실행파일하나로 다른 패키지들(diff, patch, merge, cvs, svn, rcs, git, python, perl , tcl, apache, sqlite등) 전혀 필요없이 fossil을 수행할 수 있다. ( 이것도 큰 장점 중에 하나, mac용 binary크기가 820k 정도 밖에 안 된다. )

중요한 프로젝트에 사용하기는 아직은 좀 꺼려지지만, 개인용 project에는 한번 시도를 해 보는 것도 괜찮을 듯 싶다. Sqlite와 같은 중규모의 프로젝트에서도 몇년간 계속 운영을 해 오고 있다고 한다. 웹 인터페이스나 관리자 툴, 권한 설정 등은 편하게 되어 있다.

하지만, 웹에서 검색해 본 결과 emacs integration이 없어서 나도 당분간 안 쓸거 같다.

• http://traustithor.blogspot.com/2009/03/fossil-version-control-system.html
• http://atheorist.livejournal.com/145002.html