1Chapter. 저장소 관리

1.1.1. 트랜잭션(transaction)과 리비전의 이해

개념적으로 말하면 Subversion 저장소는 디렉토리 트리의 연속입니다. 각각의 트리는 저장소에 있는 파일이나 디렉토리가 특정 순간에 어떻게 보이는지에 대한 순간포착 사진(snapshot)입니다. 클라이언트의 조작에 의해 만들어지는 순간포착 사진을 리비전(revision)이라고 합니다.

각각의 리비전은 트랜잭션(transaction) 트리로서 태어납니다. 커밋하면 클라이언트는 로컬에서의 변경 사항(과 클라이언트의 커밋 처리를 시작할 때 저장소에 일어나는 부가적인 변경 사항)을 반영한 Subversion 트랜잭션을 만들어 그 트리가 일련의 연속포착 사진 중 마지막이 되도록 저장소에 저장하라고 명령합니다. 커밋이 성공하면 트랜잭션은 새로운 리비전 트리로 승격되고 새로운 리비전 번호를 받습니다. 커밋이 어떤 이유로 실패하면 트랜잭션은 파괴되고 클라이언트는 실패했다는 통지를 받습니다.

갱신 처리도 이와 같이 동작합니다. 클라이언트는 작업 카피 상태를 반영한 임시 트랜잭션 트리를 만듭니다. 저장소는 그 트랜잭션 트리와 요청된 버전의 리비전 트리(보통은 최신의 혹은 "가장 새로운" 트리)와 비교해서 작업 카피를 그 리비전의 트리로 변형하려면 어떠한 변경이 필요한지 정보를 되돌려줍니다. 갱신이 완료된 후 임시 트랜잭션은 삭제됩니다.

트랜잭션 트리를 이용하는 것이 저장소에서 관리되는 파일 시스템을 변경하는 유일한 방법입니다. 그러나 트랜잭션의 생존 시간이 완전히 임의인 것을 이해하는 것이 중요합니다. 갱신의 경우 트랜잭션은 곧바로 소멸하는 일시적인 트리 입니다. 커밋의 경우는 트랜잭션은 영구적인 리비전으로 바뀝니다(커밋이 실패했을 때는 삭제됩지만). 에러나 버그가 있으면 트랜잭션은 저장소에 남겨져 버릴지도 모릅니다(그러나 이것은 디스크 용량을 차지할 뿐 나쁜 영향을 주지는 않습니다).

이론적으로 언젠가는 통합된 작업 환경을 지원하는 어플리케이션은 트랜잭션의 생존 기간을 좀 더 유연하게 관리할 수 있게 될지도 모릅니다. 클라이언트가 저장소에 대한 수정 내용의 기술을 끝낸 후에도 리비전이 될 후보 트랜잭션이 정지한 상태에 머무르는 시스템을 생각할 수도 있습니다. 이것은 새로운 커밋을 다른 사람 예를 들어 관리자나 엔지니어링 QA팀이 재검토하는 것을 가능하게 해서 그 트랜잭션을 리비전으로 승격시키거나 철회하거나 할 수가 있게 되겠지요.

저장소를 관리할 때 반드시 하지 않으면 안 되는 것은 무엇일까요? 대답은 간단합니다. Subversion 저장소를 관리한다면 저장소의 상태를 살피는 일의 일부로서 리비전과 트랜잭션을 조사해야 한다는 것입니다.

1.1.2. 버전화 되지 않는 속성

Subversion 저장소에서 트랜잭션과 리비전은 그것에 딸린 속성을 가질 수가 있습니다. 그러한 속성은 일반적인 키·값의 대응으로 관련한 트리에 대한 정보를 보관하는데 이용됩니다. 속성의 이름과 값은 나머지 트리 데이터와 함께 저장소의 파일 시스템에 보관됩니다.

리비전과 트랜잭션의 속성은 작업 카피에 의해 관리될 수 없는 정보들 같이 파일이나 디렉토리에 강하게 관련되지 않은 트리의 정보를 기억해 두는데 편리합니다. 예를 들어 새로운 커밋 트랜잭션이 저장소에 만들어지면 Subversion은 그 트랜잭션에 svn:date라는 속성을 추가합니다. 트랜잭션이 만들어진 시각을 나타내는 표시입니다. 커밋이 완료되어 트랜잭션이 영구적인 리비전이 될 때 트리에는 리비전 작성자의 이름(svn:author)과 리비전에 붙여진 로그 메세지(svn:log)라는 속성이 추가됩니다.

리비전과 트랜잭션의 속성은 버전화 되지 않는 속성입니다. 속성은 수정되면 그 이전의 값을 영구히 잃게 됩니다. 마찬가지로 리비전 트리 자신은 불변입니다만 트리의 속성은 그렇지 않습니다. 언제라도 리비전 속성을 추가, 삭제, 수정 할 수 있습니다. 새로운 리비전을 커밋한 후에 잘못한 정보가 있거나 로그 메세지에 오타가 있는 것을 알았을 때에는 단지 svn:log 속성의 값을 올바른 로그 메세지로 바꾸기만 하면 됩니다.

1.2.1. 훅 스크립트(Hook Scripts)

훅(hook)은 새 리비전이 생성되거나 버전화되지 않은 속성이 수정되는 일(event)이 일어났을 때 실행되는 프로그램입니다. 각각의 훅은 어떤 일이 일어났는지, 작업 대상은 무엇인지, 그 일을 한 사람은 누구인지 알 수 있는 충분한 정보를 전달 받습니다. 훅의 출력이나 반환값에 따라 훅 프로그램은 처리를 계속하거나 종료하거나 몇 가지 방법으로 일시 중단하거나 합니다.

기본값에 따르면 hooks 디렉토리에는 다양한 저장소 훅의 템플릿이 있습니다.

$ ls repos/hooks/
post-commit.tmpl          pre-revprop-change.tmpl
post-revprop-change.tmpl  start-commit.tmpl
pre-commit.tmpl           

Subversion이 가지고 있는 훅에는 각각 하나의 템플릿이 있고, 템플릿 스크립트의 내용을 보면 그 스크립트가 어떤 트리거(trigger)를 실행하는지, 어떤 데이터가 그 스크립트에 전달되는지 알 수 있습니다. 또 많은 템플릿들에는 유용한 작업을 수행하기 위해서 Subversion이 제공하는 다른 프로그램들과 훅 스크립트를 어떻게 결합해서 쓰는지 보여주는 예제가 있습니다. 실제로 훅을 설치하는 것은 repos/hooks 디렉토리에 훅의 이름으로 (start-commit이나 post-commit 같이) 실행 프로그램이나 스크립트를 두기만 하면 됩니다.

유닉스(Unix)에서는 이 말의 의미는 스크립트나 프로그램(쉘 스크립트, 파이썬 프로그램, 컴파일된 C 실행파일 등)을 정확하게 훅의 이름과 똑같은 이름으로 가져다 놓으라는 말입니다. 물론 템플릿 파일들이 정보를 제공하기 위한 목적만으로 제공되는 것은 아닙니다. 유닉스에서 훅을 설치하는 가장 간단한 방법은 템플릿 파일을 .tmpl 확장자를 뗀 새 파일로 복사해서 내용을 고치고 그 파일에 실행권한을 주는 것입니다. 그러나 윈도우즈(Windows)에서는 실행가능한 파일임을 나타내기 위해서 특수한 확장자를 사용하기 때문에, 실행 프로그램에는 훅의 이름 뒤에 .exe나 .com를 붙이고 일괄작업(batch) 파일에는 .bat를 붙여야 합니다.

현재 Subversion 저장소에는 다섯 종류의 훅이 구현되어 있습니다.

Subversion은 저장소에 접근하는 프로세스의 소유자로서 훅을 실행하려고 합니다. 대부분의 경우 사용자는 아파치(Apache) HTTP 서버와 mod_dav_svn을 통해서 저장소에 접근하므로, 훅을 실행하는 사용자는 아파치를 실행하는 사용자와 같습니다. 훅을 실행하려는 사용자가 실행할 수 있도록 OS 수준에서 훅에 실행 권한을 주어야합니다. 또 그 말은 훅이 직·간접적으로 접근하는 모든 파일이나 프로그램(Subversion 저장소도 포함하여)에 같은 사용자로 접근한다는 뜻입니다. 훅이 지정된 작업을 수행하는데 권한 설정에 관련된 문제가 일어날 가능성이 있으므로 주의하시기 바랍니다.

1.2.2. 버클리 DB 설정

버클리(Berkeley) DB 환경에는 한 번에 몇 개의 잠금(lock)이 허용되는지, 저널링 로그 파일의 크기 제한은 얼만큼인지 등에 대한 기본 설정값이 있습니다. 거기에 더해서 Subversion의 파일 시스템 코드가 설정해놓은 Berkeley DB 설정의 기본값이 있습니다. 그러나 특징적인 데이터나 접근 패턴을 가지는 저장소가 있을 것이고, 그런 저장소는 다른 설정값을 가지는 것이 바람직합니다.

Sleepycat의 사람들(버클리 DB의 제작자들)은 다른 데이터베이스는 다른 요구를 처리해야 한다는 것을 알고있기 때문에, 실행시에 버클리 DB의 설정값을 바꿀 수 있는 방법을 제공해왔습니다. 버클리 DB는 환경 디렉토리에 DB_CONFIG 파일이 있는지 확인하고, 그 파일에 있는 옵션을 사용합니다.

당신의 저장소의 버클리 DB 설정 파일은 db 라는 환경 디렉토리 안의 repos/db/DB_CONFIG 파일입니다. Subversion이 저장소를 만들 때 이 파일도 만들어집니다. 이 파일에는 기본 설정과 함께 버클리 DB의 온라인 문서가 어디있는지에 대한 정보도 있으므로, 어느 옵션이 어떤 기능을 하는지에 대해 읽어볼 수 있습니다. 물론 지원되는 어떤 옵션이라도 DB_CONFIG에 추가할 수 있습니다. Subversion은 그 파일의 내용을 읽거나 해석하지도 않고 그 파일에 설정된 값을 전혀 사용하지도 않지만, Subversion의 나머지 코드가 예측할 수 없는 방식으로 버클리 DB가 작동할 수 있는 설정은 피해주세요. DB_CONFIG에 대한 변경은 데이터베이스 환경을 복구할 때까지(svnadmin recover 를 사용하여)는 효력을 발생하지 않습니다.

1.3.1. 관리자용 도구 모음

$ svnlook help
general usage: svnlook SUBCOMMAND REPOS_PATH [ARGS  OPTIONS ...]
Note: any subcommand which takes the '--revision' and '--transaction'
      options will, if invoked without one of those options, act on
      the repository's youngest revision.
Type "svnlook help subcommand" for help on a specific subcommand.

$ svnlook info /path/to/repos
$ svnlook info /path/to/repos --revision 19

$ svnlook youngest /path/to/repos
19

$ svnlook info path/to/repos
sally
2002-11-04 09:29:13 -0600 (Mon, 04 Nov 2002)
27
Added the usual
Greek tree.

$ svnlook tree path/to/repos --show-ids
/ 0. 0.1
 A/ 2. 0.1
  B/ 4. 0.1
   lambda 5. 0.1
   E/ 6. 0.1
    alpha 7. 0.1
    beta 8. 0.1
   F/ 9. 0.1
  mu 3. 0.1
  C/ a. 0.1
  D/ b. 0.1
   gamma c. 0.1
   G/ d. 0.1
    pi e. 0.1
    rho f. 0.1
    tau g. 0.1
   H/ h. 0.1
    chi i. 0.1
    omega k. 0.1
    psi j. 0.1
 iota 1. 0.1

$ svnadmin help
general usage: svnadmin SUBCOMMAND REPOS_PATH  [ARGS  OPTIONS ...]
Type "svnadmin help subcommand" for help on a specific subcommand.

Available subcommands:
   create
   dump
   help (?, h)

$ svnshell.py /path/to/repos
rev: 2 /$  help
Available commands:
  cat FILE     : FILE의 내용을 보여줍니다.
  cd DIR       : DIR이라는 디렉토리로 이동합니다.
  exit         : 쉘을 종료합니다.
  ls [PATH]    : 현재 디렉토리에 포함된 파일 목록을 보여줍니다.
  lstxns       : 내용을 볼 수 있는 트랜잭션의 목록을 보여줍니다.
  setrev REV   : 살펴볼 리비전을 설정합니다.
  settxn TXN   : 살펴볼 트랜잭션을 설정합니다.
  youngest     : 살펴볼 수 있는 가장 최신 리비전 번호를 보여줍니다.
rev: 2 /$

rev: 2 /$ ls
   REV   AUTHOR  NODE-REV-ID     SIZE         DATE NAME
----------------------------------------------------------------------------
     1    sally      2.0. 1          Nov 15 11:50 A/
     2    harry      1.0. 2       56 Nov 19 08:19 iota
rev: 2 /$ cd A
rev: 2 /A$ ls
   REV   AUTHOR  NODE-REV-ID     SIZE         DATE NAME
----------------------------------------------------------------------------
     1    sally      4.0. 1          Nov 15 11:50 B/
     1    sally      a. 0.1          Nov 15 11:50 C/
     1    sally      b. 0.1          Nov 15 11:50 D/
     1    sally      3.0. 1       23 Nov 15 11:50 mu
rev: 2 /A$ cd D/G 
rev: 2 /A/D/G$ ls
   REV   AUTHOR  NODE-REV-ID     SIZE         DATE NAME
----------------------------------------------------------------------------
     1    sally      e. 0.1       23 Nov 15 11:50 pi
     1    sally      f. 0.1       24 Nov 15 11:50 rho
     1    sally      g. 0.1       24 Nov 15 11:50 tau
rev: 2 /A$ cd ../..
rev: 2 /$ cat iota
This is the file 'iota'.
Added this text in revision 2.

rev: 2 /$ setrev 1; cat iota
This is the file 'iota'.

rev: 1 /$ exit
$

$ svnadmin list-unused-dblogs /path/to/repos
/path/to/repos/log. 0000000031
/path/to/repos/log. 0000000032
/path/to/repos/log. 0000000033

$ svnadmin list-unused-dblogs /path/to/repos | xargs rm
## disk space reclaimed!

1.3.2. 저장소 청소

Subversion 저장소는 일반적으로 일단 한 번 설정하면 그다지 주의를 기울일 필요는 없습니다. 그러나 관리자에 의한 몇개의 보조가 필요할지도 모릅니다. svnadmin 유틸리티 에는 다음과 같은 작업을 돕기 위한 기능이 있습니다.

• 커밋 로그 메시지 수정

• 죽은 트랜잭션(transaction) 삭제

• "굳어져 버린" 저장소(repository) 복구

• 저장소의 내용을 다른 저장소로 옮기기

svnadmin의 하위 명령어로 가장 자주 사용되는 것은 아마 setlog일 것입니다. 트랜잭션이 저장소(repository)에 커밋되어 새로운 리비전을 만들었을 때, 로그 메시지는 그 리비전 자체의 버전화 되지 않은 속성으로서 저장됩니다. 바꾸어 말하면 저장소는 그 속성의 마지막 값만을 기억하고 있고 이전 것은 버리게 됩니다.

가끔 사용자는 로그 메세지에서 실수를 찾아냅니다(오자나 잘못된 정보 등). 만약 저장소가( pre-revprop-change 와 post-revprop-change 훅을 사용해. >참조) 커밋 완료 후 이 로그 메시지의 변경을 받아들이도록 설정되었다면 사용자는 svn 프로그램의 propset 명령어를 사용해 로그 메시지를 원격으로 "수정" 할 수 있습니다. (>참조) 그러나, 정보가 영원히 없어지는 일을 막기 위해 Subversion 저장소는 기본값으로 그 기능이 꺼져있습니다. 버전화 되지 않는 속성은 관리자만 변경할 수 있도록 기본값으로 설정되어 있습니다.

만약 관리자가 로그 메시지를 변경할 필요가 있는 경우 svnadmin setlog를 사용합니다. 이 명령어는 저장소(repository)의 지정한 리비전의 로그 메세지(svn:log 속성 )을 지정한 파일로부터 읽어들인 값으로 바꿉니다.

$ echo "Here is the new, correct log message" > newlog.txt
$ svnadmin setlog myrepos newlog.txt -r 388

다른 자주 있는 svnadmin 의 사용법은 종료하고 있지 않다 아마 죽어 버린Subversion 트랜잭션(transaction)에 관한 저장소(repository)에의 문의입니다. 커밋이 실패했을 때 보통 트랜잭션(transaction)는 예쁘게 소거됩니다. 즉 트랜잭션(transaction) (은)는 저장소(repository)로부터 삭제되어 그 트랜잭션(transaction)에(인 만큼) 관련했다 데이터도 이와 같이 삭제됩니다. 그러나, 자주 트랜잭션(transaction)의 청소가 일어나지 않고 실패하는 것이 있습니다. 이것에는 몇개의 이유가 생각됩니다: 아마 클라이언트의 조작이 유저에 의해 난폭하게 종료되었는지 네트워크의 이상등이 처리의 도중에 일어났을 경우입니다. 이유에 관계없이 이러한 죽었다 트랜잭션(transaction)는 저장소(repository)를 어질러 디스크를 먹을 뿐입니다.

svnadmin의lstxns 커멘드 (을)를 사용해 그 시점에서의 미완료의 트랜잭션(transaction)의 이름의 일람표시 할 수가 있습니다.

$ svnadmin lstxns myrepos
19
3a1
a45
$

출력 결과의 각각의 항목은svnlook (와 그--transaction 옵션)(으)로 사용할 수가 있어 누가 트랜잭션(transaction)를 만들어 그것은 언제로 어떠한 변경이 트랜잭션(transaction)에 일어났는지 를 알 수가 있습니다. 바꾸어 말하면(자) 그 트랜잭션(transaction)는 삭제 대상으로 해 안전한 후보인가 부디라고 하는 것을입니다. 만약 그러면 트랜잭션(transaction)의 이름을svnadmin rmtxns 에 건네줄 수가 있어 그 트랜잭션(transaction)는 예쁘게 삭제 됩니다. rmtxns 하위 명령어는 lstxns의 출력을 그대로 입력으로서 취할 수도 있습니다!

$ svnadmin rmtxns myrepos `svnadmin lstxns myrepos`
$

이러한 두 하위 명령어를 사용하는 경우 저장소(repository)를 일시적으로 클라이언트로부터 액세스 할 수 없게 할 필요가 있습니다. 이것으로 아무도 당신이 클린 업을 시작하기 전에 올바른 트랜잭션(transaction) (을)를 개시할 수 없게 됩니다. 이하는 저장소(repository)내의 미해결의 트랜잭션(transaction) 의 각각 붙은 정보를 재빠르게 생성하기 위한 약간의 스크립트입니다:

#! /bin/sh

### Generate informational output for all outstanding transactions in
### a Subversion repository

SVNADMIN=/usr/local/bin/svnadmin
SVNLOOK=/usr/local/bin/svnlook

REPOS=${1}
if [ x$REPOS = x ] ; then
  echo "usage: $0 REPOS_PATH"
  exit
fi

for TXN in `${SVNADMIN} lstxns ${REPOS}`; do 
  echo "---[ Transaction ${TXN} ]-------------------------------------------"
  ${SVNLOOK} info ${REPOS} --transaction ${TXN}
done

이 스크립트를 /path/to/txn-info.sh /path/to/repos와 같이 해 실행할 수 있습니다. 출력은 기본적으로는svnlook info 출력의 여러가지 단편을 이은 것 같은 것이 됩니다. (>참조) 이하와 같은 느낌입니다:

$ txn-info.sh myrepos
---[ Transaction 19 ]-------------------------------------------
sally
2001-09-04 11:57:19 -0500 (Tue, 04 Sep 2001)
0
---[ Transaction 3a1 ]-------------------------------------------
harry
2001-09-10 16:50:30 -0500 (Mon, 10 Sep 2001)
39
Trying to commit over a faulty network.
---[ Transaction a45 ]-------------------------------------------
sally
2001-09-12 11:09:28 -0500 (Wed, 12 Sep 2001)
0
$

보통은 로그 메세지를 갖고 있지 않은 죽은 트랜잭션(transaction)가 보이는 경우 갱신(혹은 거기에 닮은) 조작에 실패한 결과입니다. 이러한 조작은 작업 카피 상태가(hood to mimic)상태하 그리고 Subversion의 트랜잭션(transaction)를 이용합니다. 커밋하는 의도가 전혀 없기 때문에 Subversion은 그러한 트랜잭션(transaction)에 대한다 로그 메세지를 요구하지 않습니다. 로그 메세지가 도착한 트랜잭션(transaction) (은)는 아마 확실히 어떤 종류의 커밋에 실패했을 경우입니다. 또 트랜잭션(transaction)의 타임 스탬프는 흥미로운 정보가 됩니다 예를 들어 어째서 9개월이나 전에 시작한 조작이 아직 액티브하겠지 인가? 그렇다고 하는 상태입니다.

간단하게 말해 트랜잭션(transaction)의 클린 업의 결정은 무분별하게 할 필요는 없습니다. 여러가지 정보원아파치의 에러 로그나 액세스 로그 성공한 Subversion의 커밋 로그 등 등가 어떻게 하면 좋은가를 결정하는데 있어서 도움이 됩니다. 마지막으로 관리자는 자주 죽은 트랜잭션(transaction)의 소유자라고 생각되는 사람과(email등으로) 그 죽음에 걸린 트랜잭션(transaction) 상태를 확인할 수가 있습니다.

1.3.3. 저장소(repository)의 복구

저장소(repository)의 데이터를 지키기 위해서 데이타베이스 연구 최종 단계는 락의 구조를 이용합니다. 이 구조는 데이타베이스가 있다 부분은 복수의 데이타베이스에 액세스 하고 있는 사람으로부터 동시에 변경되는 것이 없는 것을 프로텍션해 각각의 프로세스는 데이타베이스 (으)로부터 읽힌 데이터가 항상 올바른 상태에 있는 것처럼 보이는 것을 프로텍션합니다. 프로세스가 데이타베이스중의 무엇인가를 변경할 필요가 있다 경우 그것은 우선 목적의 데이터가 락되어 있지 않은지 어떤지를 확인 합니다. 만약 데이터가 락되어 있지 않으면 그 프로세스는 데이터를 잠그어 필요한 변경을 더해 마지막에 락을 뗍니다. 다른 프로세스는 데이타베이스의 그 부분에 액세스 하는 허가를 얻는다 전에 락의 해제를 기다리는 것을 강요당합니다.

Subversion 저장소(repository)를 사용하는데 있어서 치명적인 에러(디스크가 가득 되거나 메모리가 없어지거나)나 세치기에 의해 데이타베이스에 걸친 락을 삭제할 기회를 없애 버리는 일이 있습니다. 그 결과 연구 최종 단계의 데이타베이스는"굳어져"버립니다. 이렇게 되었을 때에는 저장소(repository)에의 어떠한 액세스도 영구히 기다리게 된다 것으로 되어 버립니다. (라고 하는 것은 모든 새로운 액세스는 락 하지만 해제되는 것을 기다립니다만 그것은 결코 오지 않기 때문입니다)

우선 그런 것이 저장소(repository)에 일어나도 비명을 지르지 마 주세요. Subversion의 파일 시스템은 데이터베잇 트렌섹션 (와)과 체크 포인트 거기에 사전 저널 기입의 구조를 잘 이용하고 있어 정말로 파멸적인 사건 이외는 [2] 데이타베이스 환경을 영구히 매장해 떠날 수 없는 것을 프로텍션합니다. 충분히 신경질적인 저장소(repository) 관리자는 무슨응등이나 방법으로 저장소(repository) 데이터의 오프 라인 백업을 취하고 있을지도 모르지 않습니다만 백업 테이프를 restore 해 주고와 시스템 관리 책임자를 부르는 것은 아직입니다.

다음에 이하의 순서를 사용해 저장소(repository)의"복구" (을)를 시험해 보세요:

1. 저장소(repository)에 액세스 하고 있는(혹은 하려고 하고 있다) 프로세스가 하나도 없는 것을 확인해 주세요. 네트워크 액세스 가능한 저장소(repository)에서는 이것은 Apache HTTP 서버를 슛다운 한다 일도 의미합니다.

2. 저장소(repository)를 소유해 관리하고 있는 유저가 되어 주세요.

3. svnadmin recover /path/to/repos커멘드를 실행해 주세요. 이하와 같은 출력이 표시된다고 생각합니다:

   Acquiring exclusive lock on repository db, and running recovery procedures. Please stand by... Recovery completed. The latest repos revision is 19.

4. Subversion 서버의 재기동

이 방법은 대부분의 저장소(repository) 락을 해소합니다. 이 커멘드는 단지 root가 되는 것이 아니라 데이타베이스 (을)를 소유해 관리하고 있는 유저로 실행하는 것에 주의해 주세요. 복구 작업은 상처를 입은 여러가지 데이타베이스 파일 (으)로부터의 재작성의 작업도 포함합니다. (예를 들어 공유 메모리 area 등입니다) root 에서의 복구는 root 가 소유하고 있는 파일을 작성하는 것으로 이것은 저장소(repository)에의 접속 상황이 복구한 다음에도 통상의 유저는 이것에 대해서 액세스 한다 일을 할 수 없는 것을 의미합니다.

만약 지금 말한 작업이 무엇인가의 이유로 잘 저장소(repository)를 정상적으로 되돌릴 수 없는 경우 둘을 해야 합니다. 우선 망가진 저장소(repository)를 치워 마지막 백업을 restore 합니다. 그리고 Subversion 의 개발 리스트에 email 합니다. (이것은 <dev@subversion.tigris.org>입니다) 이 때 문제점을 자세하게 설명해 주세요. 데이터의 일관성은 Subversion 개발자에게 있어 매우 높은 priority입니다.

1.3.4. 저장소(repository)의 이행

Subversion 파일 시스템은 다양한 데이타베이스 테이블에 분산되었다 데이터를 가집니다만 이것은 일반적으로는 Subversion 개발자만이 알고 있다 (라고 흥미가 있다) 일입니다. 그러나 모든 혹은 일부의 데이터를 하나의 운반에 편리한 단순한 파일 형식에 정리하고 싶은 것이 있습니다. Subversion 는 그러한 구조를svnadmin 하위 명령어 의 조에 의해 실장하고 있습니다: dump 와 load입니다.

Subversion 저장소(repository)를 덤프 하거나 로드하거나 하는 제일 자주 있는 이유는 Subversion 자신의 변경에 있습니다. Subversion이 완성에 가까워지는 것에 따라 어떤 종류의 변경이 연구 최종 단계 데이타베이스의 schema로 변경될 때 저장소(repository)의 전의 버전과의 호환성이 없어져 버립니다. 이러한 호환성의 경계를 넘어 업그레이드 할 경우에 권하는 방법은 비교적 단순한 것입니다:

1. 현행 버전의svnadmin (을)를 사용해 저장소(repository)를 덤프 파일에 덤프 해 주세요.

2. Subversion의 새로운 버전에의 업그레이드.

3. 낡은 저장소(repository)를 치워 새로운 하늘의 저장소(repository)를 거기에 만듭니다만 이것에는새로운 svnadmin (을)를 사용해 주세요.

4. 한번 더새로운svnadmin를 사용해 덤프 파일을 각각 만든지 얼마 안된 저장소(repository)에 로드해 주세요.

5. 마지막에 낡은 저장소(repository)로부터 새로운 것에 필요한 커스터마이즈 부분을 모두 카피해 주세요. 이것에는DB_CONFIG 파일과 훅의 스크립트가 포함됩니다. 새로운 릴리스의 Subversion의 릴리스 노트에 주의해 마지막 업그레이드로 훅 (이)나 설정 옵션으로 변경이 있는지 없는지를 봐 주세요.

svnadmin dump 는 저장소(repository) 리비전이 있다 범위를 출력합니다만 그것은 Subversion의 커스텀 파일 시스템 덤프 형식이 되어 있는 것입니다. 덤프 형식은 표준 출력에 표시되어 진행 상황등의 메세지는 표준 에러 출력에 표시됩니다. 이것으로 출력을 파일에 리디렉트 할 수가 있어 그 한편으로 스테이터스 의 출력에 대해서는 단말 윈도우상에서 볼 수가 있습니다. 예를 들어:

$ svnlook youngest myrepos
26
$ svnadmin dump myrepos  dumpfile
* Dumped revision 0.
* Dumped revision 1.
* Dumped revision 2.

* Dumped revision 25.
* Dumped revision 26.

처리의 최후로 지정한 범위의 저장소(repository) 리비전의 데이터 모두 하지만 보존된 하나의 파일(전의 예에서는 dumpfile) (을)를 손에 넣을 수가 있습니다.

조가 된 이제(벌써) 한편의 하위 명령어인svnadmin load는 표준 입력을 Subversion 저장소(repository)의 덤프 파일과 해 해석해 덤프 된 리비전을 목적의 저장소(repository)에 재현합니다. 그것은 또 경과 정보등을 돌려줍니다만 이쪽은 표준 출력에 표시합니다:

$ svnadmin load newrepos  dumpfile
 Started new txn, based on original revision 1
     * adding path : A ... done.
     * adding path : A/B ... done.
     
------- Committed new rev 1 (loaded from original rev 1) 

 Started new txn, based on original revision 2
     * editing path : A/mu ... done.
     * editing path : A/D/G/rho ... done.

------- Committed new rev 2 (loaded from original rev 2) 



 Started new txn, based on original revision 25
     * editing path : A/D/gamma ... done.

------- Committed new rev 25 (loaded from original rev 25) 

 Started new txn, based on original revision 26
     * adding path : A/Z/zeta ... done.
     * editing path : A/mu ... done.

------- Committed new rev 26 (loaded from original rev 26) 

svnadmin 는 표준 입력과 표준 출력을 저장소(repository)의 덤프 (와)과 로드 처리에 사용하므로 멋이 있는 사람은 이하와 같은 방식을 시험한다 일도 할 수 있습니다(아마 파이프의 양측의svnadmin (은)는 다른 버전일지도 모릅니다):

$ svnadmin create newrepos
$ svnadmin dump myrepos | svnadmin load newrepos

전에 주의한 것처럼svnadmin dump 는 리비전의 범위를 출력합니다. --revision 옵션을 사용하면 하나의 리비전의 덤프나 리비전 범위의 덤프가 생깁니다. 이 옵션을 생략 하면 모든 존재하는 저장소(repository) 리비전이 덤프 됩니다.

$ svnadmin dump myrepos --revision 23 > rev-23.dumpfile
$ svnadmin dump myrepos --revision 100:200 > revs-100-200.dumpfile

Subversion은 각각의 새로운 리비전을 덤프 하므로 그 출력에는 다음에 실행되는 로더가 전의 리비전을 바탕으로 해 그 리비전을 재 작성하는데 필요한 충분한 정보가 있습니다. 바꾸어 말하면(자) 덤프 파일중에서 어떠한 리비전이 지정되어도 리비전중에서 변경이 있던 아이템만이 덤프에 나타난다고 하는 것 입니다. 이 규칙의 유일한 예외는 현재의svnadmin dump 하지만 덤프 하는 최초의 리비전입니다.

디폴트에서는 Subversion은 전의 리비전에 대한 단순한 차분으로서 최초의 덤프 리비전을 표현할 것은 없습니다. 이 이유의 하나는 덤프 파일에는 직전의 리비전이 없기 때문입니다! 두번째에 Subversion (은)는 덤프 데이터가 로드 되는 저장소(repository) 상태에 대해 아무것도 모른다 (으)로부터입니다. (만약 로드가 일어난다고 하면 입니다만. ) svnadmin dump 의 개별의 실행의 출력이 자기 충족 해 있는 것을 프로텍션하기 위해(때문에) 최초의 덤프 리비전은 디폴트에서는 모든 디렉토리 파일, 저장소(repository)에 있는 그 리비전의 속성 의 완전한 표현이 되어 있습니다.

그러나 이 디폴트의 행동을 바꿀 수도 있습니다. 저장소(repository)를 덤프 할 경우에--incremental 옵션을 추가하면(자) svnadmin 는 최초의 덤프 리비전과 저장소(repository)중의 직전 리비전과의 차분을 이라고 깔때기 합니다. 나머지의 모든 덤프 되는 리비전에도 같은 방법으로 취급합니다. 그리고 덤프 범위에 있는 나머지의 리비전이 출력하는 것과 같이 최초의 리비전을리비전중에 일어나는 변경만을 고려해 출력합니다. 이 이점은 큰 하나의 덤프 파일의 대신에 로드에 성공하는 것 같은 작은 얼마든지의 덤프 파일을 만들 수가 있는 것입니다. 이런 느낌입니다 :

$ svnadmin dump myrepos --revision 0:1000 > dumpfile1
$ svnadmin dump myrepos --revision 1001:2000 --incremental > dumpfile2
$ svnadmin dump myrepos --revision 2001:3000 --incremental > dumpfile3

이러한 덤프 파일은 이하와 같은 커멘드가 흘러 나오고 새로운 저장소(repository)중에 로드 됩니다:

$ svnadmin load newrepos < dumpfile1
$ svnadmin load newrepos < dumpfile2
$ svnadmin load newrepos < dumpfile3

--incremental 옵션을 사용한 다른 근사한 방법은 벌써 존재하고 있는 덤프 파일에 새로운 덤프 리비전 범위를 추가하는 것입니다. 예를 들어 post-commit 훅이 있어 그것은 단지 훅을 트리거하는 것 같은 하나의 리비전의 저장소(repository) 덤프를 추가하는 것입니다. 혹은 이하와 같은 스크립트 (이)가 있어 매일 저녁 마지막에 이 스크립트를 실행하고 나서 리포지트 리에 추가된 모든 리비전의 덤프 파일 데이터를 추가하는 것입니다.

#! /usr/bin/perl

$repos_path  = '/path/to/repos';
$dumpfile    = '/usr/backup/svn-dumpfile';
$last_dumped = '/var/log/svn-last-dumped';
 
# Figure out the starting revision (0 if we cannot read the last-dumped file,
# else use the revision in that file incremented by 1).
if (open LASTDUMPED, "$last_dumped")
{
    $new_start = LASTDUMPED;
    chomp $new_start;
    $new_start++;
    close LASTDUMPED;
}
else
{
    $new_start = 0;
}

# Query the youngest revision in the repos.
$youngest = `svnlook youngest $repos_path`;
chomp $youngest;

# Do the backup.
`svnadmin dump $repos_path --revision $new_start:$youngest --incremental >> $dumpfile`;

# Store a new last-dumped revision
open LASTDUMPED, " $last_dumped" or die;
print LASTDUMPED "$youngest\n";
close LASTDUMPED;

# All done!

이와 같이 이용하는 것으로 svnadmin의 dump 와 load 커멘드는 가치가 있는 수단이 됩니다만 이것에 의해 저장소(repository)의 변경을 시간을 들여 백업 해 시스템 크래쉬나 다른 괴멸적인 사건에 갖춘다는 것입니다.

마지막으로 Subversion의 저장소(repository) 덤프 파일 형식의 다른 이용 방법과 해서는 다른 보존의 구조나 버전 콘트롤 시스템으로부터의 변환입니다. 덤프 파일 형식은 대부분이 인간이 읽을 수 있는 형태가 되어 있으므로 [3] 이 파일 형식을 사용하면(자) 비교적 간단하게 일반적인 변경점세트를 표현할 수가 있는 각각의 변경은 새로운 리비전으로서 다루어집니다

1.3.5. 저장소(repository)의 백업

현대적인 컴퓨터가 태어나고 나서 기술적으로는 매우 발전해 왔지만 유감스럽게 하나의 일만은 틀림없이 진실합니다가끔 모든 것은 완전히 엉망이 되어 버린다 라고 하는 것입니다. 정전 네트워크 절단 RAM의 파괴 하드 디스크의 크래쉬는 마귀 이외의 누구이기도 하지 않습니다. 운명은 가장 뛰어난 관리자에게조차 닥칩니다. 그래서 매우 중요한 토픽에 도착합니다어떻게 저장소(repository)의 백업을 취하는지 입니다.

일반적으로 Subversion의 저장소(repository) 관리자에게 있어 두 백업 방법이 있습니다차등 백업과 풀백 업입니다. 이 장의 전의 마디로 어떻게svnadmin dump --incremental 를 사용해 차분 백업을 취하는지를 논의했습니다 (>참조). 본질적으로 이 아이디어는 마지막에 백업을 취하고 나서 둔 저장소(repository)의 변경 부분만큼을 백업 하는 방법입니다.

저장소(repository)의 풀백 업은 문자 그대로 저장소(repository) 디렉토리 전체의 복제를 만드는 것입니다(이것은 Berkeley 데이타베이스 환경도 포함됩니다) 그런데 일시적으로 저장소(repository)에 대한 모든 액세스를 금지하지 않으면 단순한 재귀적인 디렉토리 카피의 실행은 죽은 백업을 만들어 끝내는 위험을 갖고 있습니다. 그렇다고 하는 것은 누군가가 병행해 데이타베이스에 기입해 있을지도 모르기 때문입니다.

행운의 일로 Sleepycat의 BerkeleyDB 문서에서는 있는 정해진 카피의 순서가 쓰여져 있습니다. 그 순서에 따르면 데이타베이스 파일은 올바른 백업 카피가 되는 것을 프로텍션하는 형태로 카피할 수 있습니다. 한층 더 능숙한 것에 그 알고리즘은 당신이 실장할 필요는 없고 벌써 Subversion 개발 팀이 하고 있다고 하는 것입니다. hot-backup.py 스크립트는 Subversion의 소스 패키지의tools/backup/ 디렉토리에 있습니다. 저장소(repository) 패스와 백업 위치를 지정하면(자) hot-backup.py (은)는 동작중의 저장소(repository)를 핵 올라가는데 필요한 스텝을 실행합니다 당신에게 저장소(repository) 액세스를 금지하는 것 없이 입니다 그 다음에 동작중의 저장소(repository)로부터 죽어 있는 Berkeley 로그 파일을 예쁘게 삭제합니다.

차등 백업이 있다고 해도 규칙적으로 이 프로그램을 실행하고 싶고 될지도 모릅니다. 예를 들어hot-backup.py 를 프로그램 스케쥴러에 추가하려고 생각할지도 모릅니다 (Unix 이면crond 와 같은 것). 혹은 세세한 입도의 백업을 좋아하면 hot-backup.py (을)를 부르는 것 같은 post-commit 푹스 클립트를 쓸 수도 있습니다. (>참조). 이것은 새로운 리비전이 작 히에 저장소(repository)의 새로운 백업이 생기는 방식입니다. 단지 이하를 동작중의 저장소(repository) 디렉토리에 있다 hookspost-commit 에 추가해 주세요:

(cd /path/to/hook/scripts; . /hot-backup.py ${REPOS} /path/to/backups )

결과의 백업은 완전하게 기능하는 Subversion 저장소(repository)로 현행의 저장소(repository)이 무엇인가 심하게 되었을 때에는 옮겨놓아 사용하는 것이 할 수 있는 것입니다.

양쪽 모두의 백업 방법에는 각각 이점이 있습니다. 제일 간단한 것은 풀백 업으로 그것은 항상 현행 저장소(repository)의 완전한 카피입니다. 반복이 됩니다만 무엇인가 안되는 일이 동작중의 저장소(repository)에 일어났다 때로는 단순한 재귀적인 디렉토리 카피로 이 백업을 복원할 수가 있습니다. 유감스럽게 만약 저장소(repository)의 복수의 백업 (을)를 관리하고 있는 경우 이러한 풀 카피는 실행중의 저장소(repository)와 같은 정도 각각이 디스크를 먹는다고 하는 것입니다.

저장소(repository) 덤프 형식을 사용한 차등 백업은 데이타베이스 schema 하지만 계속하는 Subversion 자신의 버전간에 변경될 때에는 매우 도움이 됩니다. 저장소(repository)의 풀 덤프와 로드는 일반적으로 저장소(repository)를 새로운 schema에 업그레이드 하는 것이 필요합니다. 그러한 작업의 반(즉 덤프의 부분)에 대해서는 벌써 끝나고 있으므로 매우 편리합니다. 불행하게도 차등 백업의 작성그리고 그 restore는 긴 시간이 걸립니다만 그것은 각각의 커밋이 덤프 파일 또는 저장소(repository)의 안으로 실제로 재실행되기 때문입니다.

어느 쪽의 백업의 경우도 저장소(repository) 관리자는 어떻게 해 버전화 되지 않는 속성에의 변경이 백업에 영향을 줄까에 주의할 필요가 있습니다. 이러한 변경은 새로운 리비전을 그 자체로 만들어 내는 것은 아니기 때문에 post-commit 훅을 호출하는 계기 에는 안되어 pre-revprop-chage 이나 post-revprop-change 훅의 계기 에조차 되지 않을 것입니다. [4] 그리고 시간의 순서에 따르지 말고 리비전 속성을 변경할 수가 있다 언제라도 어느 리비전 속성을 변경할 수가 있는 의로 마지막 몇개의 리비전의 차등 백업은 그 이전의 백업의 일부로서 행해진 리비전 속성의 수정은 거두어 들인다 일을 할 수 없습니다.

자주 저장소(repository)의 백업에 대한 최선의 방법은 분산 시키는 것입니다. 풀백 업과 차등 백업에 커밋 email의 어카이브(archive)를 추가할 수가 있습니다. 예를 들어 Subversion 개발자는 Subversion 원시 코드 저장소(repository)를 새로운 리비전 하지만 만들어질 때마다 백업 합니다. 그리고 모든 커밋과 속성 변경의 통지 email를 어카이브(archive) 해 취해 둡니다. 같은 방법을 취해 주세요. 다만, 필요한 범위에서 편리함과 안전성의 미묘한 장미 스를 취해 주세요. 그리고 이러한 일을 전부 해도 운명 의 철권으로부터 하드웨어를 지킬 수 없는 것에 주의해 주세요. [5] 백업은 확실히 그러한 시련때부터 당신을 구할 것입니다.

1.4.1. httpd Apache HTTP 서버

Subversion의 주된 네트워크 서버는 WebDAV/deltaV 프로토콜로 통신한다 일을 할 수 있는 Apache HTTP 서버입니다(httpd). 이 프로토콜은(HTTP 1.1의 확장입니다만 http://www.webdav.org/참조) World Wide Web 의 핵심이 되는 흔히 있던 HTTP 프로토콜을 필요로 해 게다가 글기능특수한 버전화 된 글기능를 추가 한 것입니다. 그 결과는 표준화 된 견뢰한 시스템이며 Apache2. 0 의 일부로서 패키지화되고 있습니다. 이것은 많은 유명한 오퍼레이팅(operating) 시스템이나 서드 파티 제품의 일부로서 서포트되고 있습니다. 되어에 그것은 특별한 관리자를 필요로 하지 않습니다. [6]

이하의 논의는 Apache 설정의 레퍼런스도 포함하고 있습니다. 몇개의 예는 그러한 인스트럭션의 사용법입니다만 완전한 사용법은 이 장의 범위를 넘고 있습니다. Apache 팀은 매우 우수한 문서를 관리하고 있어 그들의 웹 사이트 그리고 공개하고 있습니다. 그것은 http://httpd.apache.org입니다. 예를 들어 설정에 관한 일반적인 레퍼런스는 http://httpd.apache.org/docs-2. 0/mod/directives.html.

게다가 Apache의 설정을 변경하는 경우 도중에 잘못하는 일도 있습니다. Apache 의 로그 하부조직에 자세하지 않다면 거기에 조심해 주세요. httpd.conf파일에는 Apache 가 생성하는 액세스 로그와 에러 로그의 디스크상의 장소를 지정하는 인스트럭션이 있습니다. (각각CustomLog 와 ErrorLog 인스트럭션이 됩니다. ) Subversion의 mod_dav_svn 는 Apache의 에라로그인타페스도 사용합니다. 간단하게는 모르는 것 같은 문제를 분명히 하려면 정보원 (으)로서 그러한 파일의 내용을 언제라도 볼 수가 있습니다.

LoadModule dav_svn_module     modules/mod_dav_svn.so

Location /repos
  DAV svn
  SVNPath /absolute/path/to/repository
/Location

Location /svn
  DAV svn
  SVNParentPath /usr/local/svn
/Location

$ ### First time: use -c to create the file
$ htpasswd -c /etc/svn-auth-file harry
New password: ***** 
Re-type new password: *****
Adding password for user harry
$ htpasswd /etc/svn-auth-file sally
New password: *******
Re-type new password: *******
Adding password for user sally
$

Location /svn
  DAV svn
  SVNParentPath /usr/local/svn
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file
/Location

Location /svn
  DAV svn
  SVNParentPath /usr/local/svn
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /path/to/users/file
  LimitExcept GET PROPFIND OPTIONS REPORT
    Require valid-user
  /LimitExcept
/Location

ServerName svn.red-bean.com

Location /svn
  DAV svn
  SVNParentPath /usr/local/svn
  SVNIndexXSLT "/svnindex.xsl"
  
/Location

1.4.2. svnserve, 커스텀 Subversion 서버

Apache의 대체로서 Subversion은 스탠드얼론의 서버 프로그램 svnserve 도 준비해 있습니다. 이 프로그램은 Apache보다 훨씬 가볍게 만들어지고 있어 설정도 훨씬 간단합니다. 보통 TCP/IP접속을 통해서 Subversion 클라이언트와 고유의 프로토콜 그리고 이야기합니다.

svnserve가 이용한다 일을 할 수 있는 두 개의 기본적인 방식이 있습니다:

이 두 개의svnserve의 이용 방법은 서로 배타적인 물건은 아닌 것에 주의해 주세요; 양쪽 모두의 구조를 서버상에서 동시에 이용하는 것 하지만 할 수 있습니다.

$ svnserve
( success ( 1 1 ( ANONYMOUS ) ( ) ) ) 

$ svnserve -d
$ # svnserve is still running, but the user is returned to the prompt 

$ svnserve -d -r /usr/local