SVN 사용하기 전 준비 문서

버젼 관리의 필요성

여러 사람이 함께 작업할 경우 작업 결과를 모아두는 곳이 필요하다. 이때 쉽게 떠올릴 수 있는 것이 FTP 서버나 공유 서버에 작업 결과물을 모아둘 저장소를 만들어 두는 것이다. 그 저장소에는 프로그램의 소스 코드도 있을 것이고, 개발 과정을 정리한 문서, 프로그램에서 사용하는 라이브러리 등도 있을 것이다.

각각의 개발자는 작업을 하기 위해서 그 저장소에 저장된 파일을 가져와서 자신의 로컬 PC에 복사본을 만들어서 작업을 수행한다. 그런 다음 작업이 끝나면 다시 그 결과물을 저장소에 넣어둘 것이다. 이런 상황에서는 몇 가지 문제점이 발견된다.

우선 서로 다른 두 명의 개발자가 동시에 같은 파일을 복사해서 작업한 다음 저장소에 올리는 경우를 생각해보자. 열심히 작업을 해서 한 명이 먼저 작업을 끝내서 저장소에 올렸다. 잠시 후에 그 사실을 모르고 있는 또 다른 개발자가 저장소에 자신의 작업 결과물을 저장소에 보내는 순간 덮어쓰기가 일어나며 앞선 개발자의 작업은 덧없이 날아가 버린다.

물론 저장소에 올리기 전에 내가 내려 받은 파일의 최종 수정일을 기록해뒀다가, 올리기 전에 서버의 최종수정일이 변하지 않았는지를 확인하면 되지만 너무나 귀찮은 일이다.

혹 그런 귀찮음을 무릅쓰고 철저하게 확인을 한다 하더라도, 날짜가 변경되어 있을 때 도대체 누가 어떤 목적으로 그 파일의 어떤 부분을 수정했는지 알아내려면 모든 개발팀에게 “누가 언제 왜 어떤 목적으로 어떤 부분을 수정했나요?”하고 일일이 물어봐야 한다.

물론 이러한 확인이 이뤄진 후에도 앞서 작업한 개발자와 상의해서 서로 다른 두 개의 결과물을 조정해서 합의된 최종 결과물을 만든 후에 서버에 올리는 것도 여러분의 몫이다.

또 다른 경우는 며칠 전의 상태로 작업 결과를 되돌려야 하는 상황이 발생할 때이다. 1차 개발을 완료한 시점에서 추가적인 요구 사항을 처리하기 시작했다고 가정해보자. 이 때 잘못된 판단으로 도저히 회복하기 힘든 큰 실수를 저질러서 차라리 1차 개발이 완료된 시점에서 다시 개발하는 것이 좋을 때도 있을 것이다.

단순한 공유 서버를 사용했을 때 이런 상황을 해결하기 위한 방법은 전체 작업 결과물을 특정 날짜 별로 복사해서 따로 관리하는 것이다.

이 방법은 물론 특정 날짜의 작업으로 되돌릴 수 있지만, 작업 결과물의 덩치가 크고 개발기간이 길수록 불필요한 디스크의 낭비가 심해진다. 만일 2시간 전의 상태로 저장소를 되돌리고 싶다면 어떻게 할까?

매 시간마다 또 특정 태그를 붙인 복사본을 만들면서 작업을 할 것인가? 또 어떤 내용은 그대로 두고 특정 파일만을 이틀 전의 상태로 되돌리고 싶을 때는 어떻게 할 것인가?

소프트웨어의 큰 특징 중 하나는 프로젝트가 진행되는 기간 동안 그 소프트웨어는 계속해서 변경된다는 것이다. 이 때 변경되는 것은 여러분이 작성한 코드 뿐 아니라, 관련된 문서나 적용하는 라이브러리를 포함한 프로젝트의 모든 산출물이다.

여러 명이 동시에 작업하는 프로젝트라면 그러한 변경으로 인해 모든 개발자의 작업이 영향을 받게 된다. 바로 이런 문제들을 해결하기 위해 등장한 것이 바로 버전관리 시스템이다.


요약하자면


개발 버전과 릴리즈 버전이 섞이지 않고 쉽게 관리 할 수 있습니다.
소스를 잘못 수정 했더라도 기록이 남고 되돌리기가 쉽습니다.(많은 파일의 경우 유용)
수정, 추가, 삭제 등의 기록이 모두 남고 변경 사항을 추적하기 쉽습니다.
개발자들이 따로 따로 백업을 하지 않아도 됩니다.

버전 관리 시스템의 종류
현재 나와 있는 소프트웨어 버전 관리 시스템은 여러 종류가 있습니다. 각각 장단점이 있습니다.


- CVS (Concurrent Version System) : 가장 널리 사용되며 역사가 깊은 버전 관리 시스템입니다. http://www.cvshome.org

- Subversion : CVS의 단점을 개선하고 CVS를 대체할 목적으로 개발 되었습니다. 이 문서에서 설명할 버전 관리 시스템입니다. http://subversion.tigris.org

- Visual Sourcesafe : Microsoft에서 만든 버전 관리 시스템입니다. CVS와는 버전 관리 관점에서 조금의 차이점이 있습니다. 윈도우 기반 소프트웨어의 버전 관리를 할 때 자주 사용됩니다. http://msdn.microsoft.com/ssafe/

- Clear Case : Rational이라는 회사에서 만든 버전 관리 시스템입니다. 지금은 IBM에 합병되었습니다. 상용 소프트웨어입니다. http://www-306.ibm.com/software/rational

- BitKeeper : 리눅스 커널이 BitKeeper를 이용해서 개발 하고 있습니다. 상용 소프트웨어입니다. http://www.bitkeeper.com


SVN 과 CVS의 차이점

- 소스 코드 뿐 아니라 바이너리 파일, 문서 지원 - 커밋의 단위가 파일이 아니라 변경된 작업 단위
- 디렉토리, 파일별로 세밀한 접근 가능
- CVS에 비해서 빠르다.



SVN 기본 용어 정리

리비전 (rivision) : 변경들의 논리적인 단위(?), 변경 집합이라고 해석한 책도 있음 리비전 번호 (rivision %d) : 변경들의 논리적인 증가, 0부터 새로운 변경 집합이 발생하면 1 증가

저장소 (repository) : 여러 가지 버전들을 저장하는 하나의 장소 작업본 (working copy) = 작업 디렉토리 (working directory) = 작업장 (workspace) : 저장소의 파일들은 직접 변경할 수 없다. 변경하기 위해서는 저장소의 파일들을 작업하는 컴퓨터 시스템(즉, 로칼)으로 받아 사용해야 한다. 이런 저장소의 파일들이 로칼에 저장되는 공간을 workspace라고 한다. 체크 아웃 (check out) : 작업장을 처음 사용하기 위해서는 저장소에서 필요한 파일들을 받아야 한다. 처음으로 작업장에 파일을 채우는 과정을 "체크 아웃"이라 한다. 체크 아웃(쉽게 다운로드)을 통해 작업장에 최신 파일이 저장된다. 체크 아웃의 주어를 "파일들"이라고 생각하면 이해가 쉽다. 파일이 호텔(=저장소)에 들어가 숙박(=저장) 후 호텔을 나와 직장(=작업장)에 일하러 가기 위해 프런트에서 "체크 아웃"한다고 생각해보자. 그러면 이해가 쉽다. 커밋 (cummit) : 작업 후에 작업장의 파일은 변경된다. 이 변경된 파일들을 다시 저장소에 저장하고 싶을 때, 저장소에 다시 올려 보내는 것(쉽게 업로드)을 '커밋'이라 한다. 커밋하게 되면 리비전의 번호가 증가하게 된다. 갱신 (update) : 지난 작업을 마치고 커밋한 이후에 다른 사람이 저장소의 파일을 변경(커밋)할 경우가 있다. 있든 없든, 변경 여부를 확인하기 위해(=변경 여부를 작업장에 반영하기 위해) 작업장의 파일들을 갱신 하는 과정을 거친다. 이를 체크 아웃이라고 설명하는 책, 문서 등등도 있다. 태그 (tag) : 특정 시점(리비전)에 태크(=이름)을 부여하여 기억하기 쉽게 할 수 있다. 그 태크를 이용해서 체크 아웃할 수 있다. 체크 인 (check in) : commit Import : 저장소에 파일들을 집어 넣는다. svn import 명령 차이 (diff) : 리비전 간의 코드의 차이점, 작업중인 버전과 HEAD(=저장소의 최신버전)을 비교할 때 [ + ] 기호는 작업장에서 변경된 부분, [ - ] 기호는 다른 사용자에 의해 변경된 부분을 표시하는데 사용 svn diff 명령 패치 (patch) : svn diff 명령의 출력을 파일에 저장하면 그 자체가 패치다. 패치를 이용한 갱신은 patch 명령


윈도우에서 SVN을 사용하기 위해 필요한것들

1. SVN

2. 아파치

3. Tortoise http://beehone.egloos.com/1945767