fossil-scm 사용법 정리
2013.03.25 첫 작성
2013.03.30 8, 9 추가
2013.05.06 10 추가
2013.06.29 11 추가
2014.10.19 6 보완
fossil-scm 의 기본적인 가이드는 공식 사이트인 www.fossil-scm.org 에 잘 나와 있으므로 여기서는 개인적으로 바로 써먹었던 것들만 정리해서 올려둡니다.
필요한 거 찾을 때마다 지속적으로 업데이트 예정입니다.
* [] 표시는 사용자 입력 항목을 위한 것으로, 실제 입력시에는 [, ] 부분은 제거해 사용합니다.
a [파일명]
이라면
a mydoc.fossil 이런 식으로
- Repository 생성
fossil init [Repository파일명]
예) fossil init mydoc.fossil - 확장자는 딱히 정해져 있지 않고, 굳이 붙이지 않아도 상관 없으나, 차후 서비스로 사용 시, fossil 이 지정된 디렉토리 내의 .fossil 파일만을 Repository 로 처리하기 때문에 .fossil 을 붙여두는 것이 이모저모로 유용하다.
- 생성 직후 자동 생성된 관리자 암호가 나타난다. 로컬에서 ui 를 호출하는 경우 (아래 설명할 fossil ui) 암호 없이 접근 가능하지만, 그럴 것이 아니라면 기억해 둘 것.
- 원격지로부터 Repository 가져오기
fossil clone [Repository접근주소] [Repository파일명]
예) fossil clone http://192.168.0.101:8081/mydoc mydoc.fossil - clone 된 Repository는 원본과 다른 관리자 계정을 가진다! 이 때문에 clone 직후 자동 생성된 관리자 암호가 표기되는 것을 확인할 수 있다. 따라서 필요한 경우 관리자 계정을 별도 설정할 필요가 있다.
- 만약 ID 가 hongildong, 비밀번호가 pungpung 이라면 주소를 다음과 같이 입력한다
예) http://hongildong:pungpung@192.168.0.101:8081/mydoc - 일단 원격지로부터 clone 을 수행하게 되면, 이렇게 생성된 Repository 에는 내부적으로 remote repository 정보가 남게 되며, open 을 통해 설정된 작업디렉토리에서 addremove, commit, update 시 자동으로 원격지 repository 와 동기화를 하게 된다. 이를 autosync 라 한다.
- autosync 를 수행할 지 말지를 설정하려면 작업디렉토리에서 아래와 같이 한다.
- autosync 비활성화 : fossil setting autosync off
- autosync 활성화 : fossil setting autosync on
- 원격지 url 을 바꾸려면, 작업디렉토리 안에서 다읍과 같이 한다.
fossil remote-url [새로운 주소]
예) fossil remote-url http://192.168.0.104:8081/mydoc - fossil 기본 UI 호출
fossil ui [Repository파일명]
예) fossil ui mydoc.fossil - 기본 UI 는 간단한 웹사이트로 구성되어 OS 상에 설정된 기본 웹 브라우저를 자동으로 호출하는 구조로 되어 있다.
- 이 방식으로 접근할 경우 관리자로 로그인한 것으로 간주한다. 따라서 관리자 암호 없이도 관리 기능을 사용 가능하다.
- 현재 경로에서 작업디렉토리 열기 (svn, git 에서 checkout 에 해당)
fossil open [Repository경로]
예) fossil open ../mydoc.fossil - 작업 디렉토리는 현재 위치한 디렉토리 기준으로 설정된다.
- 작업 디렉토리를 설정하면, 설정한 디렉토리 내에 .fslckout 이란 디렉토리가 생성되며 여기에 작업디렉토리 정보가 들어간다.
- 이것은 git 과 마찬가지. (git 은 .git 디렉토리로 생성)
- svn 은 git 와 fossil 과는 달리, 디렉토리별로 각각 재귀적으로 .svn 을 생성하는데, 이게 다양한 문제의 원인이 된다. 디렉토리 이동 시에는 고유성 보장으로 인해 히스토리가 잘 추적되는 장점이 있는 반면, 커밋 등의 시점에서 커밋 대상이 엉망이 되는 근본적인 원인이 되기도 한다.
- 개인적으로는 Repository 파일은 별도 관리할 필요성이 있어 상위 디렉토리에 모아서 관리하는 편인데, 이 때문에 보통은 디렉토리 하나 만들고 예와 같은 형태로 접근하는 편.
- 만약 바로 해당 경로에 오픈할 경우 repository 파일과 같은 위치에 root 가 존재하므로, remote 에 따로 관리 중인 게 아니라면 작업디렉토리 제거 시 repository 날려먹지 않도록 유의. remote 가 별도로 존재한다면 반대로 이쪽이 더 편할 수도 있다.
- 현재 경로에서 작업디렉토리 닫기
fossil close - svn, git 등과 가장 큰 차이 중 하나. (사실 내가 모르는 것일지도 모르지만 -_-) close 하면, 현재 작업 디렉토리 내의 작업 정보를 삭제하고 일반 디렉토리로 돌려놓는다!
- 실행하고 나면 .fslckout 디렉토리가 사라진 걸 확인할 수 있음
- 현재 작업 중인 것을 그냥 간단한 사본 하나로 끝내고 싶다거나, 다른 repository 에 연결하려 한다거나 할 때 매우 유용한 명령어.
- 파일 추가
fossil addremove
예) fossil addremove - 이 명령을 사용하면 알아서 추가된 파일과 삭제된 파일을 추적해서 설정해 준다.
- fossil revert 명령을 이용하여 addremove 를 취소시킬 수 있다. 단 revert 명령어 자체가 repository 의 마지막 버전 (옵션 지정 시는 특정 버전) 으로 되돌리는 것이므로, addremove 외에 다른 명령어를 더 수행했었다면 (예를 들면 rename 등) 이것 역시 모두 원래대로 돌아가 버린다. 수정했던 파일조차 모두 원상복귀 되므로 변경사항이 있었다면 반드시 대상을 지정하여 사용할 것! 대상을 지정하지 않으면 파일들의 수정된 내용이 다 날아가버린다 다만 이렇게 되돌아간 작업은 fossil undo 로 다시 원상복귀 시킬 수 있다. (변경된 사항도 모두 원상복귀됨)
- fossil undo 는 이 작업을 되돌리지 못함에 유의
- Repository 에 반영
fossil commit - 파일 및 디렉토리 이동
fossil mv 원본위치 이동위치 - 이 명령은 파일이나 디렉토리가 이동되었다는 것을 알리는 역할만 수행한다.
- 매우 주의해야 할 점은, 이것은 오직 이동 내역만 기록한다는 점이다. 물리적인 파일 이동을 동반하지 않는다. fossil-scm 명령어 설명에는 딱 이것만 나와 있어서 도대체 뭘 어쩌라는 건지 참 애매모호한데, 실제로는 다음과 같다.
- 만약 작업 디렉토리에서 특정 파일이나 폴더를 이동시킨 후, 바로 fossil addremove 명령을 수행하게 될 경우, 이전 위치의 파일이 삭제되고 새로운 위치에서 파일이 추가되었다고 인식하게 된다.
- 따라서 그렇게 된 대상 디렉토리나 파일이 실제로 삭제되고 새로 추가된 것이 아니라면, fossil addremove 를 수행하면 안 되고, fossil mv 로 이동했다는 표시를 해 주어야 한다.
- fossil mv 가 정상적으로 반영되었는지는 fossil change 명령을 통해 알 수 있다. 만약 정상적으로 이동이 되었다면 대상들이 RENAMED 로 지정되어 있을 것이고, 그렇지 않다면 파일이 사라졌다는 MISSING 표시 등 다른 형식으로 표기될 것이다.
- shell 의 mv 명령어 와는 작동방식이 좀 다르다. 다음과 같다.
- shell 의 mv 명령어는 전자가 원본이고 후자가 이동 위치인지라, a, b 가 디렉토리일 때 mv a b 하면 a 는 b 의 하부로 들어가지만, fossil mv 명령은 fossil mv a b 할 경우 a 가 가진 하부 파일들이 b 로 이동된다.
- 만약 mv a b 와 같이 동작시키려면 fossil mv a a/b 이렇게 입력해야만 한다.
- 여기까지 보면 알겠지만, fossil mv 명령어는 이동 명령이라기보다는 이름변경 명령에 가깝다. 사실 fossil mv 와 fossil rename 이 같은 동작을 수행하도록 되어 있다.
- 이건 사실 따지고 보면 shell 의 mv 명령어가 모호하기에 발생하는 차이이다. 이동과 이름 변경 기능을 동시에 가지고 있기 때문. 편리하긴 하지만.
- 현재 변경사항 확인
fossil change - commit 전에 한 번 쯤은 꼭 확인해 볼 것.
- Checkout 디렉토리 내에 다른 Repository 의 결과를 Checkout 하기
fossil open --nested [Repository위치] - 활용도는 좀 미묘. 이것보다는 partial checkout 기능이 오히려 더 필요하다 보는데.
wiki 에서 Repository 내의 파일들을 참조하기
/doc/[version]/파일경로
예) Repository 내에서 version 이 trunk 이고, 파일이 whereis/test.jpg 인 경우
이미지 태그 : <img src="/doc/trunk/whereis/test.jpg />
파일 직접 링크 : <a href="/doc/trunk/whereis/test.jpg> 이것은 이미지이다!</a>상대 경로가 아니라 doc 기준의 절대 경로로 지정된다는 점에 유의할 것. 즉 Repository 내의 파일을 외부에서 끌어쓰려면 항상 /doc 경로로부터 시작되어야만 한다.- 자원 참조하기 -> fossil site 내에서는 Managing Project Documentation 으로 언급
fossil-scm은 웹UI 상에서 현 Repository 내의 모든 자원뿐만 아니라, 현 웹 UI 를 실행한 위치에 존재하는 checkout 디렉토리 내의 모든 자원까지도 접근하는 것이 가능하다. 또한, 이렇게 문서에 접근할 경우, wiki를 포함한 fossil 사이트를 구성하는 모든 요소들의 렌더 규칙을 사용하여 해당 문서를 렌더해 준다. 대표적인 예로, markdown 포맷은 Repository 내 파일들 접근 시에는 plain text 로 보여 주나, 지금 언급하는 방식으로 접근할 경우 markdown 규격에 따라 렌더하여 화면에 표시해 준다. - 기본 문법
fossil-scm을 통해 관리되는 자원은 기본적으로 다음과 같은 방식으로 접근할 수 있다.
/doc/[version]/파일 경 로
여기서 [version] 은 다음 중 하나가 될 수 있다. - branch 명
branch 명은 해당 branch 를 가리킬 때 사용된다. 만약 사용자가 기본 branch 만 사용하였다면, 기본 생성 branch 인 trunk 를 입력하면 된다.
/doc/trunk/index.md - tip
해당 경로의 가장 최신 버전의 파일을 접근할 때 사용한다. branch 에 무관한 듯. - ckout
현재 실행중인 checkout 디렉토리 내에 있는 문서를 참조할 때 사용한다.
이 부분은 매우 중요하면서도 유용한데, 그 이유는 다음과 같다. - 현재 작업중인 문서를 실시간으로 모니터링 할 수 있다.
html 이나 wiki, markdown 형식의 문서들은 작업중인 문서의 렌더 상태를 실시간으로 확인하는 것이 불가능하다. 그나마 html 은 웹브라우저가 렌더해 주는 반면, wiki 나 markdown 문서는 그것이 되지 않는다는 것.
fossil은 위에 언급했던 대로 Repository 내의 파일들을 이 방식으로 접근할 경우 렌더해 주는 기능을 가지고 있는데, 만약 이 기능이 없다면 markdown 포맷이나 wiki 포맷은 commit 하기 전까지는 해당 문서의 결과를 확인할 방법이 없다. 따라서 이 기능은 이러한 관점에서 fossil 을 일종의 문서 렌더러에 가까운 역할을 하게 한다. - 일종의 간이 웹 호스팅 형식으로 사용할 수 있다.
말 그대로, fossil 의 checkout 디렉토리 내에 파일을 둔다면, 간이 웹 호스팅의 형태로 파일을 제공할 수 있다. 물론 많은 훌륭한 웹 서버들이 있는데 굳이 fossil 을 그러한 용도로 사용할 필요성이 있는가? 라는 의문이 들 수 있으나, 아무런 부가적인 서비스 설정 없이 단순히 실행파일 하나로 간단히 웹 서비스를 open 하고 close 할 수 있다는 점은 여러 관점에서 용도가 많다. 무엇보다 1번에서 언급한, wiki 포맷과 markdown 포맷의 렌더러로 사용할 수 있기에, 문서 렌더러로서 활용이 가능하다는 강력한 장점이 존재한다.
반응형