본 포스트는 실패에 대한 기록입니다. 기록성이며, 개인적인 견해가 대부분이니 읽으실 때 주의 바랍니다.
상황
PMS를 도입하려고 하는 상황이다.
기존에는 PMS 없이 SVN으로 형상관리만 하고 있었으나, history에 대한 정리, 일률적인 자료정리, 편리한 접근권한 설정 등 여러 목적을 위해 PMS 도입을 하려 한다.
- 기존에는 SVN으로 형상관리 중
- 별도 PMS 없음
- 도입하는 PMS는 SVN과 Git 모두 지원
계획
PMS 도입에 있어 지켜야 할 포인트로 꼽은 것은 아래와 같다.
- 기존 소스 이동은 지양(보존)
- 형상관리는 기존처럼 SVN으로
이에 따라 SVN “미러링” 방식을 알아보도록 한다.
SVN 미러링
SVN 명령어에 대한 내용은 아래 포스트 참조
SVN 명령어
테스트 폴더는 아래와 같이 구성되어 있다.
- 2_svn : 기존에 존재하는 svn repository
- 5_relay_repo : 중계 svn repository
- 6_new_local : 5_relay_repo를 바라보는 로컬 폴더
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
### 기존의 svn repo가 있는 상황입니다. (2_svn)
### 이 svn repo는 2개의 png, 1개의 mov를 포함한 저장소입니다.
$ svn list file:///C:/Users/USER/Desktop/test_workspace/svn/2_svn
>>> test1.png
>>> test2.png
>>> 01.mov
### 새로운 저장소를 만듭니다. 이 저장소는 중계용으로 사용됩니다.
$ mkdir 5_relay_repo
$ svnadmin create ./5_relay_repo
### new_local 디렉토리는 5_relay_repo 저장소를 바라보게 합니다.
$ mkdir 6_new_local
$ svn checkout file:///C:/Users/USER/Desktop/test_workspace/svn/5_relay_repo ./6_new_local
### new_local 디렉토리는 update를 해도 빈 디렉토리일 겁니다.
$ svn update ./6_new_local
### 중계 저장소와 기존 svn repo를 synchronize 합니다.
$ svnsync initialize ~/5_relay_repo ~/2_svn
$ svnsync synchronize ~/5_relay_repo
### 중계 저장소로부터 update를 받습니다.
$ cd ./6_new_local
$ svn update
소회
이 방법은 중계 저장소에 기존 저장소의 소스를 동일하게 저장하는 방식이다.
이에 동일한 자료를 두 번 저장하는, 저장공간의 비효율성이 발생한다.
풀어서 말하면
svnsync initialize 를 통해 2_svn의 소스를 5_relay_repo에 가져오고,
svnsync synchronize 를 통해 2_svn의 변경사항을 바로 5_relay_repo에 반영할 수는 있지만,
이 방법은 중복저장되므로 저장 공간의 비효율성이 발생된다.
SVN는 중앙 집중식 버전 관리 시스템이라 Git과 같은 중계 저장소 운영은 어려운 듯..
지금 하려는 PMS 도입에 기존 SVN 방식의 형상관리를 그대로 받아들여오려고 했지만, 그러려면 이번처럼 중복된 저장소를 만들거나, 소스폴더 자체를 옮기거나, 혹은 PMS에 기존 repo들 내역을 하나하나 넣어줘야 하는 번거로움이 발생할 것 같다.
아무래도 Git 방식으로 remote 하여 기존 소스코드 저장 장소는 그대로 두고, PMS에서는 빈 repo를 운영하여, Git의 remote로 기존 소스코드에 접근하고, 형상관리를 할 수 있도록 해야겠다는 생각이 든다.
아니 그런데, SVN은 완성된 파일형태로 저장이 아니라서.. Git으로 해도 되려나..?
이에 대한 물음은 아래를 참고해서 다음 기회에 알아봐야겠다.
https://github.com/yona-projects/yona/issues/78