출처 : http://hanavy.egloos.com/256959
- 2008/12/27 16:35
- hanavy.egloos.com/256959
- 덧글수 : 0
Subversion을 계속 1.4 버전대를 쓰다가 1.5 버전이 나온걸 보고 이동하려고 했다.
그런데 개인적으로는 주로 bdb 버전을 쓰고 있는데 일반적으로 공식버전으로 보는 CollabNet의 Binary는 더이상 bdb를 지원하지 않고 fsfs 만을 지원하기로 한 듯 하다.
예전부터 의견들을 살펴보면 bdb 는 DB 오류가 많이 발생하여 점점 쓰는 사람들이 줄어드는 추세인 듯 하기는 한데..
어차피 아직까지 개인적으로 사용하는데 아직까진 별 문제가 없기도 하고 일단은 내가 문제를 겪기 전에는 bdb로 하려고 하니(업로드 하는 파일별로 줄줄히 생성하는게 갠적으로 맘에 안들기도 하여...) CollabNet은 쓸 수가 없었다.
그렇다고 하여 소스를 다 받아서 build 하자니 자바 개발만 주로 하는지라 windows 빌드 하기도 만만치 않을듯 하고..
하던 차에 혹시나 그 밑에 나온 SlikSVN을 보니 bdb를 지원하는 듯 하여 이걸로 받았다.
기존 쓰던 놈들 백업하고 갠적인 취향으로 인스톨을 싫어하는지라 uniExtract로 풀어서 복사한 다음 돌리니 잘 되는 듯 하다가 기존 bdb 소스를 받을 때 svnserve가 죽는 증상이 발생했다.
귀찮아서 dump/load를 안했더니 그 문제인듯 하여 dump/load 방법을 찾아본 후 그 내용을 정리한다.
1. svnserve나 apache 등의 서비스 제공자를 다 종료한다. 덤프중에 누가 접근하면 곤란하겠지..
2. svnadmin dump /path/to/repository > dumpfile.txt 명령으로 dumpfile.txt 파일로 덤프를 받는다.
물론 덤프받는 파일명이야 자기 맘대로 설정.
혹시나 몰라 /path/to/repository라는건 서버상의 실제 경로이다.
예를들어 이번에 나 같은 경우는 svnadmin dump E:/Repository/SVN/ows 라는 경로에 있는 내용을 덤프받았다.
3. 기존 repository 경로를 다른 이름으로 변경한다. 일종의 백업.
4. Subversion을 업그레이드 한다. 충돌할 수도 있으니 기존 내용은 삭제를 하고 완전히 새로 설치하도록 한다.
5. svnadmin 명령으로 새 repository 를 생성한다.
svnadmin create /path/to/repository
6. 역시 svnadmin 명령으로 아까전에 받은 파일을 로드한다.
svnadmin load /path/to/repository < dumpfile.txt
7. 기존 repository에 있는 hook scripts나 기타 등등을 새 repository 로 복사한다.
나도 많이 써보지는 않아서 hook script라는게 뭘 의미하는지 확실히는 모르겠는데 나 같은 경우는 권한 등이 저장되는 conf 폴더를 다시 복사해 놨다.
8. 종료. 다시 서버를 기동하고 제대로 작동하는지 확인한다.
그런데 개인적으로는 주로 bdb 버전을 쓰고 있는데 일반적으로 공식버전으로 보는 CollabNet의 Binary는 더이상 bdb를 지원하지 않고 fsfs 만을 지원하기로 한 듯 하다.
예전부터 의견들을 살펴보면 bdb 는 DB 오류가 많이 발생하여 점점 쓰는 사람들이 줄어드는 추세인 듯 하기는 한데..
어차피 아직까지 개인적으로 사용하는데 아직까진 별 문제가 없기도 하고 일단은 내가 문제를 겪기 전에는 bdb로 하려고 하니(업로드 하는 파일별로 줄줄히 생성하는게 갠적으로 맘에 안들기도 하여...) CollabNet은 쓸 수가 없었다.
그렇다고 하여 소스를 다 받아서 build 하자니 자바 개발만 주로 하는지라 windows 빌드 하기도 만만치 않을듯 하고..
하던 차에 혹시나 그 밑에 나온 SlikSVN을 보니 bdb를 지원하는 듯 하여 이걸로 받았다.
기존 쓰던 놈들 백업하고 갠적인 취향으로 인스톨을 싫어하는지라 uniExtract로 풀어서 복사한 다음 돌리니 잘 되는 듯 하다가 기존 bdb 소스를 받을 때 svnserve가 죽는 증상이 발생했다.
귀찮아서 dump/load를 안했더니 그 문제인듯 하여 dump/load 방법을 찾아본 후 그 내용을 정리한다.
1. svnserve나 apache 등의 서비스 제공자를 다 종료한다. 덤프중에 누가 접근하면 곤란하겠지..
2. svnadmin dump /path/to/repository > dumpfile.txt 명령으로 dumpfile.txt 파일로 덤프를 받는다.
물론 덤프받는 파일명이야 자기 맘대로 설정.
혹시나 몰라 /path/to/repository라는건 서버상의 실제 경로이다.
예를들어 이번에 나 같은 경우는 svnadmin dump E:/Repository/SVN/ows 라는 경로에 있는 내용을 덤프받았다.
3. 기존 repository 경로를 다른 이름으로 변경한다. 일종의 백업.
4. Subversion을 업그레이드 한다. 충돌할 수도 있으니 기존 내용은 삭제를 하고 완전히 새로 설치하도록 한다.
5. svnadmin 명령으로 새 repository 를 생성한다.
svnadmin create /path/to/repository
6. 역시 svnadmin 명령으로 아까전에 받은 파일을 로드한다.
svnadmin load /path/to/repository < dumpfile.txt
7. 기존 repository에 있는 hook scripts나 기타 등등을 새 repository 로 복사한다.
나도 많이 써보지는 않아서 hook script라는게 뭘 의미하는지 확실히는 모르겠는데 나 같은 경우는 권한 등이 저장되는 conf 폴더를 다시 복사해 놨다.
8. 종료. 다시 서버를 기동하고 제대로 작동하는지 확인한다.
