made by C.L

Installation

YUM을 통한 설치
yum install subversion

기본 리파지터리 생성 및 설정

svnadmin create /리파지터리를_만들경로

vi /리파지터리경로/conf/svnserve.conf

아래의 내용을 삽입
(익명 액세스 불가, 액세스 유저 권한 = 쓰기가능, 패스워드디비 = 파일명)

[general]
anon-access = none
auth-access = write
password-db = fucking_plaintext
realm = This is my Repository

vi /리파지터리경로/conf/fucking_plaintext

[users]
root = 내루트비밀번호
사용자 = 비밀번호

서버 시작
혹시 바보가 있을까봐 쓴다만.. xinetd나 standalone 둘중 하나만 선택해서 해야한다 -_-
   
xinet.d 를 통한 서비스 운영시

vi /etc/xinetd.d/svn
(아래 화면은 VI모드에서 입력할 내용, -r의 절대경로는 자기꺼에 맞게 수정할것)
service svn
{
    socket_type = stream
    wait        = no
    user        = root
    server      = /usr/bin/svnserve
    server_args = -r /리파지터리경로 -i
    disable     = no
}

# echo "svn   3690/tcp   #svn" >> /etc/services
# echo "svn   3690/udp   #svn" >> /etc/services

# service xinetd restart

standalone daemon mode

# svnserve -d


USAGE

   add ,    blame (praise, annotate, ann) ,    cat
   checkout (co) ,   cleanup ,   commit (ci) ,   copy (cp),    delete (del, remove, rm)
   diff (di),    export,   import ,    info,    list (ls),    lock,    log ,   merge
   mkdir ,   move (mv, rename, ren) ,   revert ,    status (stat, st)
   update (up)


주로사용하는 명령어는 위와같다.

svn은 각 디렉토리에 .svn 이라는 폴더를 만들어 이 경로가 리파지터리와 싱크됨을 선언하게된다.
따라 그 파일을 지워버리면, working copy 가 아닌게 되므로 더이상 svn명령을 사용할수 없게되므로 주의해야한다.
이와 유사한 역할을 하는것이 export 명령어다.


최초사용시 -

svn import /소스파일폴더 svn://내svn주소/reposit경로 -m "first loading"

등을 통해 소스파일을 모두 reposit 에 업로드를 한다. import를 사용한 경우 현재 업로드한 디렉토리가 svn에 싱크되는 워킹카피가 되지 않는다.

checkout 명령어로 리파지터리의 자료를 받아옴 -
svn checkout svn://내svn주소/reposit경로 서버절대경로

예제)
cd /opt/devel/cryptolib
svn checkout svn://svn.dgtalx.net/aes2048/cryptoapi  .

커밋 (워킹디렉토리 내용을 저장소로 동기화, 애칭으로 체크인이라고 한다)
-m 은 커밋에 따르는 리비전 메시지를 입력하는란
svn ci -m "first committing"


checkout 이 된 뒤부터는 working copy (경로연동)이 되어있으므로 이상태에서 관리명령어는 그냥 디렉토리에서 치는것을 기준으로 한다.

워킹 copy 디렉 (/opt/devel/cryptolib/ 기준) 에서 새로운 파일을 만들어 repositary에 올릴때

#vi new_source.c
 - 내용 대충 만들고 저장  -
#svn add new_source.c
#svn ci -m "source modified"

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by LeCieL

SCM (통칭 버전컨트롤) 을 통해 소스를 관리하는것은 실수를 줄이고, 변화를 쉽게 파악하는 방법중의 하나다.

그래서 전체적인 문서작업과, 그래픽, 웹프로그램들의 소스를 쉽게 컨트롤하게 하기 위해 Subversion 의 설치를 위해 총 6시간이란 막대한 시간을 투자하였다.

SCM에는 CVS와 SVN으로 크게 나뉘고 있다. CVS는 느리지만 오랜기간 안정화가되어 이곳저곳에 많이 쓰인다.
그다음으로 최근에 들어 많이 사용하는것이 이 SVN이다. 여러 익스텐션거 인터그레이션을 통해 바이너리 비교등의 높은 호환성을 보여준다.

간단하게 서론부터 말하면. 매우 피곤해진다. 아직 SVN (Subverion) 은 더 많은 개선이 필요하지만, 개선의 여지는 없어보인다.

일단 내가 필요로 하는 환경을 충족시켜주는지에 대해 검사를 했다.
몇가지 큰 이슈만을 집중적으로 검토하려고 한다.

프로젝트의 참여자 액세스컨트롤을 웹인터페이스등을 통해서도 지원안해
현버전은 프로젝트의 참여자 액세스 컨트롤등을 웹인터페이스에서 추가/삭제가 되지 않는다.
그렇다고 패스워드 연동이 되는가? 애석하게도 아직은 답이 없다.
기본상태의 솔루션을 사용할 경우 ldap 연동조차 지원하지 않는다. (별도의 플러그인이 있는지는 모르겠다)

본개발사인 collabnet 의 엔터프라이즈 에디션을 설치해보려 했다. (웹인터페이스로 프로젝트 acl등의 다양한 기능을 제공한다) 하지만 64비트 시스템에서는 사용할수가 없다고 나왔다.
또한 이는 open subversion 이 아닌 starsource 등의 별도의 프로그램을 설치하는것으로 나타났다.
따라 동떨어진 이야기다. 다운로드 받는데에만 약 40분의 시간이 소요되었고 용량은 350메가정도였다.


대량의 고용량 (5MB이상)급 이미지의 업로드 속도는 최악!
SVN은 CVS보다 빠르다. 조금더 편리하다. 그러나 이미지 처리는 개판이었다!
어도비사의 Version CUE 버전큐를 일반적 업무환경에서는 추천한다.
SVN 보다 이미지처리기준 약 150배가량 처리속도가 뛰어나며, 그래피컬하며 초보자도 매우 간단하게 쓸수 있는 인터페이스를 제공하고 있다. 심플한 Version Control 기능으로 SVN과 유사하게 사용할 수 있다. 모든 파일확장자를 지원하며 (어도비 브릿지상에서), PSD등의 파일은 섬네일까지 보인다. 물론 svn 브라우저들도 보이지만.. 윈도우용을 기준으로 보면 UI가 훨씬 불편하다.
또한 먹통되는 현상이 없으며 웹상에서 사용자를 쉽게 추가/삭제가 가능하며
프로젝트(폴더) 베이스로 권한을 체계적으로 관리할 수 있다.

본래 파일의 소유자,소유그룹,퍼미션이 보존되지 않아...
보통의 개발환경을 벗어나 웹사이트가 어느정도 상당한 기능제작이 이루어진 단계에서는 많은 CGI가 연동되기 마련이다.
작게는 Paygate의 결제솔루션, 특정 사이트의 인증을 위한 SSL 레이어 통신프로그램등이 있으며, 여기에 동작하는 키파일 등은 일단 소유자와 퍼미션 설정에 상당히 주의를 하여야 한다.

실제로 현재 내가 필요로 하는 다양한 환경들을 보존하기 위해서는 소유자,그룹, 퍼미션이 현행 그대로 저장되어야 한다. 예를들어보자

중계중인 pg 시스템의 솔루션은 cgi이므로 실행권한 을 필요로 한다. 그러나 svn 을 통해 checkout 하면 644 (rw-r-r-) 상태로 변경된다. 따라서 퍼미션이 꼬여 서비스가 중단되는등의 문제가 생긴다.

자체적으로 개발한 암호화 소프트웨어는 매우 민감한 컨트롤을 받고있는 소프트웨어다.
pg솔루션도 마찬가지지만, 이 파일은 웹서버가 읽기, 쓰기를 해서는 안되며 오직 실행권한만을 획득하여야 한다.
따라서 소유자는 루트, 아파치그룹 이고 퍼미션은 710 으로 설정하여야 한다.
여기에 연결된 계층파이프 프로그램 (권한과 서버의 CPU값, 고유 인식자를 확인하는 소프트웨어) 가 연동되므로 suid 퍼미션을 받아올 수 있어야 한다.

이런 관련파일들이 셀수없이 튀어나오는 상황에서 SVN을 사용할수는 없다.
SVN이 유행처럼 퍼지고 있는 시점에서 버전 컨트롤이라는 목적에서는 극단적으로 적은 호환성밖에 제공하고 있지 않다.

그렇다면 사용할 수 있는 방법이 있는가? postroll 스크립트 (수동으로 구동하여야함) 를 실행하여야 하나 이또한 전체적인 퍼미션을 정상적으로 인식하지 못한다. 일부 블락디바이스로 설정된 디바이스맵등은 무시하는 경향이 있으며 setuid 쪽에 문제가 있다는것.

관련 스크립트는 ASVN 과 SSVN 이 있으며, 테스트결과 SSVN이 개중 좋은 호환성을 보여주었다.

meta-data-versioning 이라는 희안한 패치가 있긴하지만, 이것은 패치형식이 아닌 완성된 소스를 컴파일하는식으로 사용하여야 한다. 그러나 몇가지 언급된 버그들과 개발사이트의 svn관리허술로 1.43 버전으로 업포스팅하는 과정에서 바뀐버전을 찾을수 없는 (아마도 개발자가 귀찮아서 전체커밋을 한게 아닌가싶다) 문제로 모듈하나를 끝마치고 중단을 하게되었다. (한도끝도없어보인다)

그렇다고 현재 개발해서 사용하고 있는 암호화 소프트웨어의 경우 SVN으로 버전관리가 될까?

내가 사용하는 C소스의 경우를 예로 들어보았다.
컴파일후엔 suid 를 필요로하는 바이너리와 일반 바이너리 (보안설정필요)등 바이너리 4개가 생성되며 이러한 바이너리 역시 버전컨트롤로 관리되어 쉽게 롤백시킬수 있는 이점이 있어야한다.
또한 적재되는 모듈들 또안 주 프로그램에서 퍼미션을 확인하게 한다. (해킹당했을 경우에도 root소유권으로 설정되어 내용을 읽거나 가져갈수 없어야한다)

하지만 SVN으로는 이 소스의 형상관리만 가능할 뿐 바이너리는 관리가 되지 않는다. 매번 체크아웃 할때마다 퍼미션 바까줘야하는 중노가다를 하게만들거나, 거기에 따른 스크립트를 붙이게 만든다.


총평
Subversion 은 단순한 프로그램들의 버전컨트롤로써는 쓰기에 충분하다. 그러나 복잡한 웹개발환경에서는 무용지물이라는 사실과, 개발사는 meta-data-versioning 등의 브랜치가 충분히 있으며, 언젠가 개발자의 메일링 답변을 보니 곧 포함할것이다 라는 의견을 밝힌점과 그로부터 2년이 지난 지금..
아직도 포함하지 않고 버전업만 한다는것은 포함할 의사가 없다는것을 나타내는것으로 보인다.

단순한 리눅스의 C소스나 고정화된 배포형식의 버전컨트롤 (현재 freshmeat이나 sf등이 사용하는 형식) 으로 보이기 위함만을 추구하는곳에야 편리하게 깔아 쓸수 있지만,
말그대로 버전컨트롤, 바이너리 관리등을 위한 목적으로 제작된 프로그램은 아닌것이 확실했다.

SVN은 단순한 배포용 소프트웨어다.  webdav 인터페이스를 통해 wc 등으로 누군가 무엇을 했고 누가 참여를 했느냐등을 집계내는 플러그인으로 소스작업과 배포 이외에는 전혀 고려되어있지 않다.

CVS를 통해 편법을 동원해가며 user mapping을 거는것이 오래된 방식이지만 가장 많은 호환성을 나타내는것으로 판단된다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by LeCieL