[SVN] SVN; Subversion 주요 개념과 흐름(기본 형태 + 브랜치)

제목

[SVN] SVN; Subversion 주요 개념과 흐름(기본 형태 + 브랜치)

관련 게시글

목차

1. SVN이란?

2. SVN구조 및 흐름

1. SVN이란? - Git과 함께 알아보는 주요 개념

SVN(Subversion)은 중앙 집중형 버전 관리 시스템입니다.

SVN은 네트워크를 통해 여러 사용자가 동시에 작업할 수 있도록 합니다.

svn과 git은 유사하지만 차이가 있습니다.

이번 섹션에서 svn의 주요 개념을 알아보면서 git과 어떤 차이가 있는지 살펴보도록 하겠습니다.

1.1 Repository

Repository는 모든 버전의 파일과 디렉터리가 저장되는 중앙 저장소입니다.

각 파일의 변경 이력이 기록되며, 여러 사용자가 접근할 수 있습니다.

 

Git의 로컬 및 원격 Repo를 뜻합니다.

1.2 Working Copy

Working Copy는 Repository에서 (checkout 또는 update을 통해)가져온 파일과 디렉터리의 로컬 사본입니다.

사용자는 Working Copy를 수정하고, 수정된 내용을 Repository에 (commit하여) 변경사항을 저장합니다.

 

Git에서 clone한 로컬 Repo입니다.

1.3 checkout

SVN에서 checkout 명령어를 사용하여 Repository의 데이터를

로컬로 복사합니다.

Working Copy를 생성합니다.

 

git clone 명령어와 유사합니다.

git clone https://github.com/user/repo.git
svn checkout http://svn.example.com/repo/project

1.4 add, commit

add는 git 이나 svn이 특정 파일이나 디렉토리를 추적하도록 하는 명령어입니다.

commit은 로컬 Working Copy에서 작업한 내용을 Repository에 반영하는 작업(명령어)입니다.

commit 하면 history를 남깁니다.

이를 통해, 특정 지점에 무엇이 변경되었는지 확인하거나,

(revert를 사용하여)특정 지점으로 되돌릴 수 있습니다.

git commit  명령어와 유사하지만,

git은 commit 후 push 하여 원격지에 적용합니다.

svn은 push 없이 곧바로 적용됩니다.

git add update.txt
git commit -m "update.txt 생성"
git push origin main

svn add update.txt
svn commit -m "update.txt 생성"

1.5 update

update는 변경된 Repository의 데이터를 로컬로 가져오는 명령어입니다.

서버에 존재하는 Repository 데이터와,

로컬에서 작업한 Working Copy 데이터에 충돌(conflict)이 있다면,

이를 해결(resolve)한 후 적용(commit)해야 합니다.

git pull 과 유사합니다.

git은 pull 명령어를 사용할 때, 다른 원격지로부터 pull할 수 있습니다.

git pull
git pull origin main

svn update

1.6 trunk

trunk는 Repository 에 존재하는 프로젝트의 최상단 디렉토리를 나타냅니다.

일반적으로 프로젝트의 기본 브랜치를 뜻합니다.

git의 main, master 브랜치를 떠올리면 됩니다.

1.7 revert

svn에서 revert는 hitory를 기반으로,

로컬(Working Copy)의 변경사항을 되돌립니다.

git의 revert는 commit을 생성하여 revert 이력을 남깁니다.

git revert <commit-hash>
svn revert <file or directory>

1.8 resolve

svn에서 resolve 명령어를 사용하여 충돌(conflict)을 해결합니다.

git에선 충돌을 해결하고,

git add를 통해 충돌이 해결되었음을 스테이징 영역에 반영합니다.

(git add 와 유사한 것이지, 엄밀히 말하자면 다릅니다)

git add <conflict.txt>
svn resolve --accept working <conflict.txt>

1.9 merge

merge 명령어를 사용하여 브랜치를 병합합니다.

기준이 되는 브랜치로 이동 후 merge합니다.

git과 svn 둘 다 merge의 사용법이 유사합니다.

git switch main
git merge hot-fix

svn checkout trunk
svn merge branches/hot-fix

2. SVN 구조 및 흐름

저는 Git에 익숙해져 있었고,

SVN의 흐름을 글로 이해하기엔 어려움이 있었습니다.

따라서 시각자료를 통해 이해하고자 합니다.

2.1 기본적인 svn

svn은 server에 (소스코드를 포함한)repository가 있습니다.

2.1.1 svn checkout

각 local 계정이 server의 repository를 copy 합니다.

local에서 svn checkout 명령어로 copy한 repository를 working copy라고 합니다.

2.1.2 svn commit

local1의 client가 소스코드를 수정합니다.

commit하면 그 즉시 server에 반영됩니다.

만약 중복(conflict)이 발생하면 commit할 수 없습니다.

conflict를 해결하기 위해 svn update 명령어와 svn resolve 명령어를 사용합니다.

2.1.3 svn update - svn resolve

svn update 명령어를 사용하여 소스코드를 최신화합니다.

충돌이 발생할 수도 있습니다.

충돌이 발생하면,

에디터로 충돌 파일을 수정하고,

svn resolve 명령어를 사용하여 working copy의 충돌을 해결합니다.

2.1.4 svn commit

이후 commit 합니다.

여기까지가 기본적인 svn의 사용법입니다.

 

local에서 개인적인 commit내역을 관리할 수 없고,

commit 시 곧바로 server에 적용된다는 것이 단점이라고 할 수 있습니다.

변경사항을 server에 commit 하기엔 부족하고,

당장 commit 해야만 하는 상황이 생기면 곤란해지기 때문입니다.

또한, 곧바로 server에 적용되기 때문에 신중을 요하게 됩니다.

2.2 Branch를 활용한 SVN

기본적인 SVN은 Branch를 사용하지 않았지만,

Repository하위에 디렉토리를 세분화하는 것으로 branch 를 활용할 수 있습니다.

위에서 언급하지 않은 명령어 중, branch 사용에 특화된 명령어가 있습니다.

trunk를 복사할 svn copy,

(git 사용자라면 익숙하게 들릴)svn merge, svn switch 명령어입니다.

먼저 세분화된 구조를 보겠습니다.

2.2.0 branch를 활용하기 위한 구조

2.2.0.1 trunk

trunk는 소스가 저장되는 (메인-마스터)브랜치입니다.

repository를 trunk와 branches 디렉토리로 나누는 것을 통해,

메인 소스를 건드리지 않고 브랜치 작업을 가능하게 합니다.

2.2.0.2 branches

브랜치를 생성하고자 하면,

branches 디렉토리 하위에 생성합니다.

feature, fix 디렉토리는 브랜치 예시입니다.

원한다면 더 세부화할 수도 있습니다.

2.2.1 브랜치 생성

2.2.1.1 svn checkout

먼저 svn checkout으로 repository-trunk를 local에 copy하고,

2.2.1.2 svn copy

svn copy로 브랜치를 생성합니다.

2.2.1.2 svn switch

이후 svn switch 명령어를 사용하여,

feature branch로 switch 합니다.

2.2.2 브랜치에서 작업 및 병합

2.2.2.1 svn commit1

브랜치에서 작업한 뒤,

변경사항을 적용하기 위해 commit 합니다.

2.2.2.2 svn commit2

feature branch와 trunk 의 history는 따로 관리됩니다.

2.2.2.3 svn checkout - svn merge - svn commit

브랜치 작업을 완료하면,

branch와 trunk를 병합(merge)합니다.

svn checkout 

svn 또한 git과 마찬가지로 병합의 기준이 되는 브랜치로 이동합니다.

svn merge

이제 다른 브랜치와 병합(merge)합니다.

svn commit

병합한 것을 서버에 적용합니다.

2.2.3 브랜치 정리

작업을 마쳤으면 svn delete 명령어를 사용하여 브랜치를 정리합니다.

svn delete 서버주소\repository\branches\feature -m "delete feature branch"

브랜치 삭제는 서버에 곧장 적용되므로 신중을 기합니다.

git과 마찬가지로,

브랜치 삭제 이후에도 svn log과 revision을 활용하여 history를 확인할 수 있습니다.

svn log 서버주소\repository\branches\feature@<revision-number>

 

svn의 branch 작업에 대해 알아봤고,

형상관리는 언제나 주의를 기울여야 한다고 생각합니다.

 

중요한 것은

1. 형상관리도구를 어떻게 활용하는가

2. 클라이언트의 요구사항이 무엇인가

라고 생각합니다.

3. 참고할만한 자료

https://svnbook.red-bean.com/

Version Control with Subversion

https://subversion.apache.org/

Apache Subversion