[오픈소스컨설팅]Subversion vs git - 참을 수 없는 간단함

최지웅(jchoi at osci.kr)
Subversion vs Git - 엄청난 간략 비교 -
주식회사 오픈소스컨설팅

2
- Internal Use Only -
버전 관리 필요성 기존의 파일 시스템 공유 등으로 문제 발생시 복구 프로젝트 진행 중 과거의 특정 시점으로 돌아가야 하는 경우 여러 사람이 같은 프로젝트에 참여할 경우, 각자가 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화 소스 코드의 변경 사항을 추적 소스 코드에서 누가 수정했는지 추적 대규모 수정 작업을 더욱 안전하게 진행 마이너 버전(branch)로 프로젝트에 영향을 최소화 하면서 새로운 부분을 개발 병합(merge)로 검증이 끝난 후 새로이 개발된 부분을 메인코드에 통합 코드의 특정 부분에 대한 수정 사항 확인(diff)

3
버전 관리 시스템 종류
“Copy – Modify – Merge” vs “Unlock – Modify – Lock ”

4
버전 관리 시스템 사용 용어
용어
설명
중앙 저장소
(Repository)
원본 소스를 저장하고 있는 저장소
작업 디렉토리
(Working Copy)
원본 저장소로부터 체크아웃을 통해 내려 받은 내 로컬 PC에 있는 작업 사본 디렉토리
커밋(Commit)
작업 디렉터리에서 변경, 추가 및 삭제된 파일을 원본 저장소인 서버에 적용하는 것
갱신(Update)
체크아웃을 받은 작업 디렉터리를 원본 저장소의 가장 최신 커밋된 버전까지 업데이트하는 명령어
리비전(Revision)
소스 파일을 수정하여 커밋하게 되면 일정한 규칙에 의해 숫자가 증가하며, 저장소에 저장된 각각의 파일 버전
롤백(Roll Back)
작업 디렉터리에 저장되어 있는 사본을 특정 리비전 또는 특정 시간으로 복원할 수 있도록 하는 명령어 버전 관리 시스템에서 일반적으로 사용되는 용어는 아래와 같음

5
일반적인 버전 관리 프로세스
체크아웃(최초)
(작업 및 테스트)
업데이트
커밋
(작업 및 테스트)
client server
현재 리비전 전송( n )
리포지토리 내의 변경사항을 로컬에
반영
변경사항 저장 및 로그 기록
상태 체크
리비전 n 이후의 변경사항이 있는가?
(충돌 해결)
중앙 리포지토리 내에서 로컬 복사 후 변경한 사본을 커밋하는 방식으로 진행

6
Subversion, Git 간략 비교
구분
Subversion
Git
시초
CVS 문제점1)을 극복하기 위해 CVS 개발자들에 의해 2000년에 새롭게 시작
2005년 4월 BitKeeper 논쟁2) 이후 리눅스를 만든 리누스 토발즈에 의해 시작
리포지토리 모델
클라이언트-서버 모델
분산형(Distributed)
동시성 모델
Merge, Lock
병합(Merge)
라이선스
Apache
GNU GPL 라이선스
지원 플랫폼
윈도우, 유닉스, 리눅스
윈도우, 유닉스, 리눅스
사용언어
C
C, shell scripts, Perl
보안
Numbers
SHA-1 hashes
1)디렉토리, 파일 이름 변경이 불가능하고, 속도가 느리며 커밋 실패시 롤백이 지원되지 않아 소스 관리의 어려움
2)2002년에 리눅스 커널 프로젝트는 상용DVCS 시스템인 bitKepper를 사용하기 시작했다. 2005년에는 리눅스 커널을 개발하는 커뮤니티와 BitKeeper를 개발하는 커머셜 회사간에 관계에 문제가 생기면서, 툴의 무료 사용권이 사라지게 됨. 이 사건으로 BitKeeper 기능을 토대로 새로운 버전관리 툴을 만드는 계기가 됨

7
Subversion 개요 CVS를 개발하던 개발자들이 CVS가 가지고 있던 문제를 해결하고자 완전히 새로운 아키텍처를 적용하여 새롭게 만든 솔루션 커밋 단위가 파일이 아니라 체인지셋
CVS에서라면 여러 개의 파일을 한꺼번에 커밋하더라도 각각의 파일마다 리비전이 다름
Subversion에서는 파일별 리비전이 없고 한번 커밋할 때마다 변경 사항별로 리비전이 하나씩 증가 CVS에 비해 엄청나게 빠른 업데이트/브랜칭/태깅 시간 CVS와 거의 동일한 사용법으로 기존 사용자 유도 파일 이름변경, 이동, 디렉터리 버전 관리도 지원 원자적(atomic) 커밋
CVS에서는 여러 파일을 커밋하다가 어느 한 파일에서 커밋이 실패했을 경우 앞의 파일만 커밋이 적용되고 뒤의 파일들은 그대로 남음
Subversion은 여러 개의 파일을 커밋하더라도 커밋이 실패하면 모두 이전 상태로 회귀 양방향 데이터 전송으로 네트워크 소통량(트래픽) 최소화. 트리별, 파일별 접근 제어 리스트. 저장소 쓰기 접근을 가진 개발자라도 소스 변경 제어가능 저장소/프로젝트별 환경 설정 가능

8
Subversion 리포지토리 구조
tags
branches
trunk
Project 1
Root
Project 2
tags
branches
trunk
tags
trunk
Project 1
Repository parent dir
Project 2
tags
trunk
One repository, many projects
One project per repository
branches
branches 여러 가지 방식의 리포지토리 구조를 생성하여 사용하는 것이 가능함

9
Subversion 작업유형
svn checkout
svn update
Create a local copy
svn add
svn move
svn delete
Make changes
svn status -u
See what was changed
in the repository in the meantime
svn update
Update your local copy
svn diff
svn resolved
Resolve conflicts
(Merge your changes)
svn commit
Submit your changes
105
100
106
Subversion
Repository 중앙 리포지토리 내에서 로컬 복사 후 변경한 사본을 커밋하는 방식으로 진행

10
서브버전 아키텍처
Berkley DB
FSFS
Subversion
Repository
Client Interface
Repository Interface
GUI clients
Cmd line
clients
Client
Library
Working Copy Management
Library
Access Protocol
DAV
SVN
Local
Apache
mod_dav
mod_dav_ svn
svnserve
"file" protocol
SSH
sshd
Intranetwork 다양한 클라이언트 인터페이스를 통해 각 리포지토리에 접근하여 작업 가능

11
Git 개요 리눅스 커널 커뮤니티와 BitKeeper를 개발하는 커머셜 회사간에 관계에 문제가 발생하면서 리누스 토발즈에 의해 새롭게 만들어 버전 관리 솔루션 Branching and Merging
새로운 패치, 아이디어를 위해 브랜치를 생성하고 커밋 후 다시 메인 코드로 병합이 가능 Small and fast
모든 동작들을 우선적으로 로컬에서 실시하게 된다. 따라서, 이것은 서버와 연동하기 위해 네트워크를 타지 않아도 되기 때문에 속도면에서 여러 가지로 엄청난 장점 분산형 개발 모델
각각의 작업환경에서 별도로 작업한 소스들은 언제든지 메인서버로 업로드하고 merge가 가능 데이터 안전
모든 파일은 체크썸 검사를 하고, 다운을 받을 때에도 다시 실시를 하여 Git에서 모든 bit까지 보장 스테이징 모드
모든 파일은 스테이징(로컬) 영역에 추가되고 서버의 리포지토리에 커밋되는 두 단계로 구성

12
Git 작업 유형 명령어들을 로컬에서 실시하고 나중에 서버에 올리는 방식을 사용 기존의 svn에서 commit이 1. 소스를 수정하고, 2. 저장소로 업로드 하는 2 단계를 각각의 명령어로 분리하여 중간에 로컬에서 일하다가 저장소에 적용하기 전의 잠재적인 한 번의 단계를 거침 한 번의 명령으로 바로 적용되는 SVN과는 달리 2번의 명령을 실행해야 마침내 서버에 있는 저장소로 업로드 "git commit -a" 의 명령을 통해서 다른 버전관리 프로그램들과 같이 이용하는 것도 가능 기존의 버전 관리 시스템과는 다른 로컬 영역의 저장소의 2단계를 가짐

13
분산형 개발 아키텍처
<통합 관리 워크플로우 모델> 각 팀원의 역할을 분담해서 한 명은 통합을 전담으로 수행 다른 개발자는 각자 부분 개발에 집중을 하는 식으로 역할 분담 팀이 커질수록 복수의 repository를 쉽게 구성 가능 하위 팀들을 묶어주는 통합 관리자, 그리고 전체를 통합하는 관리자로 더 세분화해서 구성하는 것이 가능

14
Git 성능
Operation
상세 테스트
Git
SVN
Commit Files (A)
Add, commit and push 113 modified files (2164+, 2259-)
0.64
2.60
4x
Commit Images (B)
Add, commit and push 1000 1k images
1.53
24.70
16x
Diff Current
Diff 187 changed files (1664+, 4859-) against last commit
0.25
1.09
4x
Diff Recent
Diff against 4 commits back (269 changed/3609+,6898-)
0.25
3.99
16x
Diff Tags
Diff two tags against each other (v1.9.1.0/v1.9.3.0 )
1.17
83.57
71x
Log (50)
Log of the last 50 commits (19k of output)
0.01
0.38
31x
Log (All)
Log of all commits (26,056 commits - 9.4M of output)
0.52
169.20
325x
Log (File)
Log of the history of a single file (array.c - 483 revs)
0.60
82.84
138x
Update
Pull of Commit A scenario (113 files changed, 2164+, 2259-)
0.90
2.82
3x
Blame
Line annotation of a single file (array.c)
1.91
3.04
1x 거의 대부분의 작업에서 서브버전 대비 엄청난 성능차를 보이고 있음

15
요약
전세계 대부분의 오픈소스 프로젝트가 SVN에서 Git 형태로 변경되고 있으며, 국내 일부 개발사(게임사, 커머스 등)에서 상당수 사용하고 있음

16
요약
OPEN SHARE CONTRIBUTE ADOPT REUSE

[오픈소스컨설팅]Subversion vs git - 참을 수 없는 간단함

Recommended

More Related Content

What's hot (20)

Similar to [오픈소스컨설팅]Subversion vs git - 참을 수 없는 간단함 (20)

More from Ji-Woong Choi (20)

[오픈소스컨설팅]Subversion vs git - 참을 수 없는 간단함