1. SVN 개요
1.1 버전 관리 시스템의 필요성
# 개발 버전과 릴리즈 버전이 섞이지 않고 쉽게 관리 할 수 있다.
# 소스를 잘못 수정 했더라도 기록이 남으며, 되돌리기가 쉽다.
# 수정, 추가, 삭제 등의 기록이 모두 남고 변경 사항을 추적하기 쉽다.
# 개발자들이 따로 따로 백업을 하지 않아도 된다.
1.2 버전 관리 시스템 선택
1.2.1 VSS 와 SVN (어느 개발자의 두 버전관리 시스템의 평가)
VSS는 유료이며, VSS의 큰 문제는 깨지는 저장소이다. CS구조가 아닌 NFS 방식으로 파일을 공유하기 때문에 그런 문제가 있었던 것으로 보인다. 안정성이 가장 중요한 요소 중 하나인 SCM에서 자주 깨지는 저장소는 신뢰성을 떨어트린다.
매일 백업을 받고 있었으므로 몇 시간 분량의 손실만 있을 뿐 복구는 할 수 있었지만, 개발 시간을 낭비하게 만드는 것은 아주 짜증나는 일이다. 그리고 허약한 Branch기능은 부족한 기능 중에 하나였다.
SVN은 일단 무료이며, 어느 개발자는 그 오랫동안 사용하면서 저장소는 단 한번도 깨진 적이 없다고 한다. 그리고 빠르다. 아무리 큰 디렉터리를 태깅하거나 브랜치를 해도 시간은 몇 십초 안 걸린다.
CVS에서 엄청나게 큰 디렉터리 태깅하면서 기다려보신 분은 알것이다. 그렇게 빠른 이유는 SVN은 기존의 SCM의 파일 시스템과 완전히 다른 방식을 사용하고 있기 때문이다. 기존의 대부분의 SCM들이 RCS(Revision Control System)에서 기초한 파일시스템을 사용하는데 반해서 SVN의 파일시스템은 기존의 단점을 없애고 새로 만들었다 즉 각 Revision의 Diff만 저장하는 방식이다. 따라서 태그나 브랜치를 만들 때는 Diff가 없으므로 순식간에 이루어진다.
그리고 SVN의 VSS와 비교한 장점 중의 하나가 협업이 훨씬 쉬워졌다는 것이다. SVN도 Lock기능이 있지만, 이걸 사용하지 않고도 협업에 문제가 없다. 왜냐하면 하나의 파일을 동시에 수정할 경우에는 Merge를 해주기 때문이다. 기존에 VSS를 사용할 때는 물론 Multi-lock 기능이 있기는 하지만, 며칠씩 Lock을 걸어 놓고 풀지 않는 사람 때문에 보통 귀찮은 게 아니었다. SVN을 사용하면서 이런 문제는 사라졌다.
결국 SVN의 빠른 속도, 안전한 저장소, 뛰어는 브랜치 기능, 머지기능 등은 저와 저희 팀이 즐겁게, 제대로 일하는데 많은 도움을 주었다. (* 출처 : http://allofsoftware.net/50)
1.2.2 CVS 와 SVN
# 커밋 단위가 파일이 아니라 체인지셋이라는 점이다. CVS에서라면 여러 개의 파일을 한꺼번에 커밋하더라도 각각의 파일마다. 리비전이 따로 붙는다. 반면 Subversion에서는 파일별 리비전이 없고 한번 커밋할 때마다 변경 사항별로 리비전이 하나씩 증가한다.
# CVS에 비해 엄청나게 빠른 업데이트/브랜칭/태깅 시간.
# CVS와 거의 동일한 사용법. CVS 사용자라면 누구나 어려움 없이 금방 배울 수 있다.
# 파일 이름변경, 이동, 디렉토리 버전 관리도 지원.
# 원자적(atomic) 커밋. CVS에서는 여러 파일을 커밋하다가 어느 한 파일에서 커밋이 실패했을 경우 앞의 파일만 커밋이 적용되고 뒤의 파일들은 그대로 남아있게 된다. Subversion은 여러개의 파일을 커밋하더라도 커밋이 실패하면 모두 이전 상태로 되돌아 간다.
# 양방향 데이터 전송으로 네트워크 소통량(트래픽) 최소화.
# 트리별, 파일별 접근 제어 리스트. 저장소 쓰기 접근을 가진 개발자라도 아무 소스나 수정하지 못하게 조절할 수 있다.
# 저장소/프로젝트별 환경 설정 가능
# 확장성을 염두에 둔 구조, 깔끔한 소스
(* 출처: http://www.pyrasis.com/main/Subversion-HOWTO)
1.2.3 SVN 관련 용어 설명
저장소 : 리포지토리(Repository)라고도 하며 모든 프로젝트의 프로그램 소스들은 이 저장소 안에 저장이 된다. 그리고 소스뿐만이 아니라 소스의 변경 사항도 모두 저장된다. 네트워크를 통해서 여러 사람이 접근 할 수 있다.
체크아웃 : 저장소에서 소스를 받아오는 작업.
커밋(Commit) : 체크아웃 한 소스를 수정, 파일 추가, 삭제 등을 한 뒤 저장소에 저장하여 갱신 하는 것입니다. 커밋을 하면 CVS의 경우 수정한 파일의 리비전이 증가하고 Subversion의 경우 전체 리비전이 1 증가하게 된다.
업데이트(Update) : 체크아웃을 해서 소스를 가져 왔더라도 다른 사람이 커밋을 하였다면 소스가 달라졌을 것입니다. 이럴 경우 업데이트를 하여 저장소에 있는 최신 버전의 소스를 가져온다.
리비전(Revision) : 소스 파일등을 수정하여 커밋하게 되면 일정한 규칙에 의해 숫자가 증가 한다. 저장소에 저장된 각각의 파일 버전이라 할 수 있다. Subversion의 경우 파일별로 리비전이 매겨지지 않고 한번 커밋 한 것으로 전체 리비전이 매겨 진다. 리비전을 보고 프로젝트 진행 상황을 알 수 있다.
임포트(Import) : 아무것도 들어있지 않은 저장소에 맨 처음 소스를 넣는 작업이다.
익스포트(Export) : 체크아웃과는 달리 버전 관리 파일들을 뺀 순수한 소스 파일을 받아올 수 있다. 오픈소스 프로젝트의 경우 소스를 압축하여 릴리즈 할 때 사용한다.
(* 출처: http://www.pyrasis.com/main/Subversion-HOWTO)
2. SVN과 VSS의 차이점
A팀의 VSS 사용 방법을 보니 이제 새로 사용할 SVN과는 다소 차이점이 있어 그 차이점을 간략하게 설명한다.
2.1 SVN은 하나의 프로젝트를 하나의 저장소에 저장한다.
VSS를 보니 여러 A팀 프로젝트를 하나의 저장소에서 조회하고 저장소에서 직접 등록/수정/삭제도 하는 것 같다.물론 SVN도 여러 A팀 프로젝트를 하나의 저장소에서 조회하는 것이 가능하다.
그러나 그 수많은 프로젝트를 하나의 저장소에서 관리하면 1. 저장소가 비대해지는 등의 이유로 관리하기 어려움점이 있다.(이점은 VSS도 동일한 문제라고 생각함) 2. SVN을 잘 사용하려면 사용 방법에 대해 묵시적인 관례를 따라야 하는데 SVN 관례중 하나는 프로젝트 단위별로 저장소를 관리하는 것이다.
2.2 여러 프로젝트에서 공통적으로 SVN을 사용하는 관례는 처음 한번 모든 프로젝트를 로컬에 다운받는 것이다.
SVN이던 CVS던 버전관리 저장소의 프로젝트를 개발자가 사용하려면 일단 개발자 로컬에 모든 소스를 다운로드 받고 로컬에서 작업하고 저장소로 동기화 하는 구조로 되어 있다.
그래서 최초에 한번은 저장소의 모든 소스를 로컬에 다운로드 받아야 한다. 그 다음부터는 변경된 건에 대해서만 저장소로부터 update 받고 로컬의 소스를 commit 할 수 있다.
만약 개발자가 아닌 단순 '조회(View)' 목적으로 저장소의 파일을 보길 원한다면, SVN 클라이언트의 저장소 뷰 기능을 통해 VSS처럼 저장소의 최신 소스를 조회 할 수 있다.
2.3 SVN 클라이언트 프로그램은 여러 종류가 있는데 그중 우리가 사용할 클라이언트는 탐색기에 Add 된 형태로 사용한다.
SVN 클라이언트는 여러 종류가 있는데 우리가 사용하는 클라이언트 툴은 그림 파일을 보면 알 수 있겠지만, 탐색기에 Add된 형태로 사용한다.
3. SVN 설치방법
3.1 SVN 클라이언트를 설치한다.
http://tortoisesvn.net/downloads 에서 TortoiseSVN-1.6.5.16974-win32-svn-1.6.5.msi 를 다운로드 받는다.
TortoiseSVN-1.6.5.16974-win32-svn-1.6.5.msi 을 실행하여 설치한다.
설치 후 restart는 굳이 할 필요 없다.
설치가 완료된후 탐색기 오른쪽 마우스를 클릭하면 다음의 메뉴가 추가되었다.
1.1 버전 관리 시스템의 필요성
# 개발 버전과 릴리즈 버전이 섞이지 않고 쉽게 관리 할 수 있다.
# 소스를 잘못 수정 했더라도 기록이 남으며, 되돌리기가 쉽다.
# 수정, 추가, 삭제 등의 기록이 모두 남고 변경 사항을 추적하기 쉽다.
# 개발자들이 따로 따로 백업을 하지 않아도 된다.
1.2 버전 관리 시스템 선택
1.2.1 VSS 와 SVN (어느 개발자의 두 버전관리 시스템의 평가)
VSS는 유료이며, VSS의 큰 문제는 깨지는 저장소이다. CS구조가 아닌 NFS 방식으로 파일을 공유하기 때문에 그런 문제가 있었던 것으로 보인다. 안정성이 가장 중요한 요소 중 하나인 SCM에서 자주 깨지는 저장소는 신뢰성을 떨어트린다.
매일 백업을 받고 있었으므로 몇 시간 분량의 손실만 있을 뿐 복구는 할 수 있었지만, 개발 시간을 낭비하게 만드는 것은 아주 짜증나는 일이다. 그리고 허약한 Branch기능은 부족한 기능 중에 하나였다.
SVN은 일단 무료이며, 어느 개발자는 그 오랫동안 사용하면서 저장소는 단 한번도 깨진 적이 없다고 한다. 그리고 빠르다. 아무리 큰 디렉터리를 태깅하거나 브랜치를 해도 시간은 몇 십초 안 걸린다.
CVS에서 엄청나게 큰 디렉터리 태깅하면서 기다려보신 분은 알것이다. 그렇게 빠른 이유는 SVN은 기존의 SCM의 파일 시스템과 완전히 다른 방식을 사용하고 있기 때문이다. 기존의 대부분의 SCM들이 RCS(Revision Control System)에서 기초한 파일시스템을 사용하는데 반해서 SVN의 파일시스템은 기존의 단점을 없애고 새로 만들었다 즉 각 Revision의 Diff만 저장하는 방식이다. 따라서 태그나 브랜치를 만들 때는 Diff가 없으므로 순식간에 이루어진다.
그리고 SVN의 VSS와 비교한 장점 중의 하나가 협업이 훨씬 쉬워졌다는 것이다. SVN도 Lock기능이 있지만, 이걸 사용하지 않고도 협업에 문제가 없다. 왜냐하면 하나의 파일을 동시에 수정할 경우에는 Merge를 해주기 때문이다. 기존에 VSS를 사용할 때는 물론 Multi-lock 기능이 있기는 하지만, 며칠씩 Lock을 걸어 놓고 풀지 않는 사람 때문에 보통 귀찮은 게 아니었다. SVN을 사용하면서 이런 문제는 사라졌다.
결국 SVN의 빠른 속도, 안전한 저장소, 뛰어는 브랜치 기능, 머지기능 등은 저와 저희 팀이 즐겁게, 제대로 일하는데 많은 도움을 주었다. (* 출처 : http://allofsoftware.net/50)
1.2.2 CVS 와 SVN
# 커밋 단위가 파일이 아니라 체인지셋이라는 점이다. CVS에서라면 여러 개의 파일을 한꺼번에 커밋하더라도 각각의 파일마다. 리비전이 따로 붙는다. 반면 Subversion에서는 파일별 리비전이 없고 한번 커밋할 때마다 변경 사항별로 리비전이 하나씩 증가한다.
# CVS에 비해 엄청나게 빠른 업데이트/브랜칭/태깅 시간.
# CVS와 거의 동일한 사용법. CVS 사용자라면 누구나 어려움 없이 금방 배울 수 있다.
# 파일 이름변경, 이동, 디렉토리 버전 관리도 지원.
# 원자적(atomic) 커밋. CVS에서는 여러 파일을 커밋하다가 어느 한 파일에서 커밋이 실패했을 경우 앞의 파일만 커밋이 적용되고 뒤의 파일들은 그대로 남아있게 된다. Subversion은 여러개의 파일을 커밋하더라도 커밋이 실패하면 모두 이전 상태로 되돌아 간다.
# 양방향 데이터 전송으로 네트워크 소통량(트래픽) 최소화.
# 트리별, 파일별 접근 제어 리스트. 저장소 쓰기 접근을 가진 개발자라도 아무 소스나 수정하지 못하게 조절할 수 있다.
# 저장소/프로젝트별 환경 설정 가능
# 확장성을 염두에 둔 구조, 깔끔한 소스
(* 출처: http://www.pyrasis.com/main/Subversion-HOWTO)
1.2.3 SVN 관련 용어 설명
저장소 : 리포지토리(Repository)라고도 하며 모든 프로젝트의 프로그램 소스들은 이 저장소 안에 저장이 된다. 그리고 소스뿐만이 아니라 소스의 변경 사항도 모두 저장된다. 네트워크를 통해서 여러 사람이 접근 할 수 있다.
체크아웃 : 저장소에서 소스를 받아오는 작업.
커밋(Commit) : 체크아웃 한 소스를 수정, 파일 추가, 삭제 등을 한 뒤 저장소에 저장하여 갱신 하는 것입니다. 커밋을 하면 CVS의 경우 수정한 파일의 리비전이 증가하고 Subversion의 경우 전체 리비전이 1 증가하게 된다.
업데이트(Update) : 체크아웃을 해서 소스를 가져 왔더라도 다른 사람이 커밋을 하였다면 소스가 달라졌을 것입니다. 이럴 경우 업데이트를 하여 저장소에 있는 최신 버전의 소스를 가져온다.
리비전(Revision) : 소스 파일등을 수정하여 커밋하게 되면 일정한 규칙에 의해 숫자가 증가 한다. 저장소에 저장된 각각의 파일 버전이라 할 수 있다. Subversion의 경우 파일별로 리비전이 매겨지지 않고 한번 커밋 한 것으로 전체 리비전이 매겨 진다. 리비전을 보고 프로젝트 진행 상황을 알 수 있다.
임포트(Import) : 아무것도 들어있지 않은 저장소에 맨 처음 소스를 넣는 작업이다.
익스포트(Export) : 체크아웃과는 달리 버전 관리 파일들을 뺀 순수한 소스 파일을 받아올 수 있다. 오픈소스 프로젝트의 경우 소스를 압축하여 릴리즈 할 때 사용한다.
(* 출처: http://www.pyrasis.com/main/Subversion-HOWTO)
2. SVN과 VSS의 차이점
A팀의 VSS 사용 방법을 보니 이제 새로 사용할 SVN과는 다소 차이점이 있어 그 차이점을 간략하게 설명한다.
2.1 SVN은 하나의 프로젝트를 하나의 저장소에 저장한다.
VSS를 보니 여러 A팀 프로젝트를 하나의 저장소에서 조회하고 저장소에서 직접 등록/수정/삭제도 하는 것 같다.물론 SVN도 여러 A팀 프로젝트를 하나의 저장소에서 조회하는 것이 가능하다.
그러나 그 수많은 프로젝트를 하나의 저장소에서 관리하면 1. 저장소가 비대해지는 등의 이유로 관리하기 어려움점이 있다.(이점은 VSS도 동일한 문제라고 생각함) 2. SVN을 잘 사용하려면 사용 방법에 대해 묵시적인 관례를 따라야 하는데 SVN 관례중 하나는 프로젝트 단위별로 저장소를 관리하는 것이다.
2.2 여러 프로젝트에서 공통적으로 SVN을 사용하는 관례는 처음 한번 모든 프로젝트를 로컬에 다운받는 것이다.
SVN이던 CVS던 버전관리 저장소의 프로젝트를 개발자가 사용하려면 일단 개발자 로컬에 모든 소스를 다운로드 받고 로컬에서 작업하고 저장소로 동기화 하는 구조로 되어 있다.
그래서 최초에 한번은 저장소의 모든 소스를 로컬에 다운로드 받아야 한다. 그 다음부터는 변경된 건에 대해서만 저장소로부터 update 받고 로컬의 소스를 commit 할 수 있다.
만약 개발자가 아닌 단순 '조회(View)' 목적으로 저장소의 파일을 보길 원한다면, SVN 클라이언트의 저장소 뷰 기능을 통해 VSS처럼 저장소의 최신 소스를 조회 할 수 있다.
2.3 SVN 클라이언트 프로그램은 여러 종류가 있는데 그중 우리가 사용할 클라이언트는 탐색기에 Add 된 형태로 사용한다.
SVN 클라이언트는 여러 종류가 있는데 우리가 사용하는 클라이언트 툴은 그림 파일을 보면 알 수 있겠지만, 탐색기에 Add된 형태로 사용한다.
3. SVN 설치방법
3.1 SVN 클라이언트를 설치한다.
http://tortoisesvn.net/downloads 에서 TortoiseSVN-1.6.5.16974-win32-svn-1.6.5.msi 를 다운로드 받는다.
TortoiseSVN-1.6.5.16974-win32-svn-1.6.5.msi 을 실행하여 설치한다.
설치 후 restart는 굳이 할 필요 없다.
설치가 완료된후 탐색기 오른쪽 마우스를 클릭하면 다음의 메뉴가 추가되었다.
3.2 프로젝트 체크아웃(다운로드 받기)
1. 자신의 컴퓨터에서 프로젝트 용도의 폴더를 생성한다.
예) c:\source1 <- 이 폴더명은 사용자 임의로 정할 수 있다.
2. c:\source1 폴더로 들어가서 마우스 우측 버튼 > SVN Checkout 을 클릭한다.
3. 저장소 URL을 타이핑한다. 예) svn://192.24.7.241/AMLUI/trunk
4. 체크아웃 다 받을때까지 기다린다.
3.3 프로젝트 최초 등록
1. 체크아웃 받은 폴더에, 등록하고자 하는 프로젝트 소스를 복사/붙여넣기 한다.
2. 마우스 우측버튼 > SVN Commit을 누른다.
3. Commit 리스트 전체 소스를 '체크' 표시하고 확인버튼을 누른다. (이해안되면 4.4 설명 참고)
4. SVN 사용 방법 및 관례
일단 아래 설명이 복잡하게 느껴지면 이것만 기억해도 좋다. 수시로 저장소의 최신 소스를 update 받고 수시로 자신이 수정한 파일을 commit 하는 것이 SVN등의 버전 관리 시스템을 가장 잘 사용하는 방법이다.
4.1 출근후 처음 작업하기 전에 전체 Update를 한다.
만약 현재 프로젝트를 여러명이 같이 진행하고 있으면, 출근후 첫 작업하기 전에, 프로젝트 전체 Update를 한번 받아 저장소와 로컬간 전체 동기화를 시킨다.
4.2 파일을 commit 할때, commit 하기 전에 관련 파일을 한번 update 받고 commit 한다.
만약 현재 프로젝트를 여러명이 같이 진행하고 있고, 해당 파일 수정 작업을 오래하고 있으면, 작업된 파일을 commit 하기전에 한번 관련 파일을 update받아 저장소와 로컬간에 소스 동기화를 한 다음, 다시 commit 한다.
4.3 파일을 delete 할때, 로컬에서 파일을 지웠으면 그 지운 내용도 commit을 한다.
쓸모 없는 파일이 발견되어 파일을 delete 하면, 지운 내역도 저장소에 commit을 하여 저장소의 쓸모없는 파일을 지울 수 있다. (CVS등에서는 제공되지 않는 기능)
4.4 파일을 add 할때, commit 버튼을 누른 후 새로 add할 파일의 체크박스를 체크 하고 올린다.
파일을 add할때는, 해당 폴더에서 commit버튼을 누르면 새로 add할 파일 목록이 나온다. 그런데 이때 체크박스에 표시를 하고 등록을 해야 새로운 파일이 저장소에 등록이 된다.
4.5 만약 commit, udpate중 충돌이 발생했을때
1. commit 할때 에러가나면 대부분 마지막으로 update받은 이후에, 누군가 저장소로 새로 파일을 commit 한 상태에서 발생한다. 이말은 commit을 하기전에 마지막으로 update 받은 파일이 저장소의 최신 버전과 일치해야 한다는 것이다.
2. update 받을때 에러가나면 대부분 현재 작업한 파일과 저장소의 마지막으로 변경된 파일이 다를 때 주로 발생한다. 1.과 비슷한 상황이다. 이때는 diff를 이용하여 틀린 부분을 맞춰준다음 다시 commit 한다.
3. 기타 여러가지 이유로 svn 관련 에러가 발생할수 있다. 이럴 경우 마우스 우측버튼 하여 Clean up을 한다. 그래도 안될 경우에도 여러 해결방법이 있는데..
4.6 퇴근할때는 현재까지 작업한 소스를 전체 commit 한다.
소스 동기화를 자주 하는것이야 말로 SVN을 잘 활용하는 방법이다. 마치 사람없는 집은 금방 폐허가 되는 경우와 비슷하다. SVN 사용 관례상 지속적인 소스 동기화를 위해 퇴근할 때 현재까지 작업한 소스를 전체 commit하는 습관을 가진다.
5. SVN 관련 유익한 사이트
http://www.pyrasis.com/main/Subversion-HOWTO
SVN에 대한 전반적인 설명이 매우 잘 되어있다.
http://allofsoftware.net/50
VSS,SVN,CVS 등의 비교 에 대한 설명이 잘 되어있다.
http://blog.naver.com/ccw3435?Redirect=Log&logNo=100043063029
SVN의 일반적인 사용법
[출처] SVN(서브버전) 이란 어디에 쓰는 물건인가요? |작성자 알콜코더
댓글 없음:
댓글 쓰기