본문 바로가기
Language & Tool/SVN

02 SVN의 이해

by Orangetasteboy 2023. 7. 8.

SVN 아키텍쳐 구성 요소

Command line app

커맨드라인 클라이언트 프로그램

DOS의 Command나 UNIX나 Linux의 쉘 프롬프트처럼 명령어를 직접 입력하여 서버와 통신

 

 

GUI Client apps

GUI(Graphical User Interface) 클라이언트 프로그램

GUI 환경에서 클라이언트 프로그램의 화면을 통해서 서버와 통신

대표적인 GUI 클라이언트 프로그램으로 TortoiseSVN, 이클립스 등이 있음.

 

 

Apache - mod_dav_svn

Apache HTTP 서버용의 플러그인 모듈

저장소를 네트워크상 다른 사용자가 사용 가능하도록 함.

 

 

svnserve

demon으로 또는 SSH로부터 기동되는 독립 서버 프로그램

네트워크에 있는 저장소를 사용 가능한 방법 제공

 

 

SVN Repository(저장소)

모든 프로젝트의 프로그램 소스들과 소스에 대한 변경 사항이 저장되는 곳

네트워크를 통해 여러 사람이 접근 가능

기본적으로 SVN에서는 Berkeley DB(Default) 또는 파일 시스템(Optional)을 저장소로 사용

 

 

 

 

SVN의 작업 사이클 / 관련 기본 SVN 명령어

1. init

  • 프로젝트 매니저나 리드 개발자가 SVN 서버에 프로젝트 저장소 생성

 

2. import

  • 개발자 한 명이 초기 버전에 대한 소스나 문서, 파일 등을 서버에 업로드
  • 이것은 아무것도 들어 있지 않은 저장소에 맨 처음 소스를 넣는 작업
  • 이클립스에서는 [Team] → [Share Project] 메뉴에 해당

 

3. checkout

  • 모든 개발자는 서버에 저장되어 있는 것을 자신의 로컬 작업 환경에 가져옴.
  • 저장소에서 전체 소스의 최종 리비전을 받아오는 것
  • 저장소를 체크아웃하면 로컬 컴퓨터에 원하는 프로젝트의 사본 생성
  • 사본은 지정된 저장소의 최신 개정판 포함
  • 최신 버전이 아닌 원하는 버전으로 체크아웃 가능

 

4. add/remove

  • 각 개발자는 새로운 소스나 파일 등을 추가하거나 삭제

 

5. update

  • 서버에 저장되어 있는 최근의 소스를 로컬로 가져옴.
  • 변경된 부분만을 가져옴.
  • 체크아웃을 한 이후의 타인에 의한 소스 변경 사항을 확인하는 작업
  • 저장소에 있는 소스 중 로컬과 비교하여 변경된 항목의 최신 버전의 소스를 가져옴.
  • 변경된 항목의 최신 버전은 로컬에 통합
  • 파일을 변경하기 전에 언제나 갱신을 수행하는 것이 최우선 원칙

 

6. conflict

  • 한 파일의 일부 행을 두명 이상의 사용자가 변경했을 때 또는 저장소에 파일을 갱신할 때 충돌 발생
  • 로컬에 체크아웃 이후 수정한 소스를 저장소에 커밋할 때, 저장소의 리비전이 더 높을 경우 충돌 발생
  • 타인에 의해 수정되고 커밋된 상태

 

7. commit (check-in)

  • 로컬에 체크아웃한 소스를 수정, 파일 추가, 삭제한 후 저장소에 저장하여 갱신
  • 커밋을 하면 전체 리비전이 1 증가

 

 

이외의 SVN 명령어

export

  • 체크아웃과는 달리 버전 관리 파일들을 뺀 순수한 소스 파일을 받아올 수 있음.
  • 오픈 소스 프로젝트의 경우 소스를 압축하여 릴리즈할 때 사용

 

trunk

  • 프로젝트의 중심 디렉터리로 모든 프로그램 개발 작업은 trunk 디렉터리에서 이루어짐.
  • trunk 디렉터리 아래에는 바로 소스들의 파일과 디렉터리가 들어감.

 

branches

  • trunk 디렉터리에서 프로그램을 개발하다가 큰 프로젝트에서 또 다른 작은 분류로 빼서 따로 개발해야할 경우 발생
  • 이때 branches 디렉터리 안에 또 다른 디렉터리를 두어 그 안에서 개발
  • 브랜치는 대부분 주요 개발 브랜치를 컴파일러 오류나 버그로 방해하지 않고 새로운 기능을 테스트할 경우에 생성

 

tag

  • 태그 디렉터리는 프로그램을 개발하면서 정기적으로 릴리즈할 때 그때그때 발표한 소스를 따로 저장하는 공간
  • 태깅은 기본적으로 개정판 번호(Revision Number)와 상관없이 각 파일에 라벨을 붙이는 것
  • 작업 사본과 저장소 자체에 모두 가능

 

hook

  • 새로운 개정판의 생성이나 버전 관리가 되지 않은 속성의 수정과 같은 저장소 이벤트에 의해 실행되는 프로그램
  • 그 이벤트가 무엇인지, 어떤 목표로 작동하는지, 이벤트를 실행한 사람의 사용자 이름이 무엇인지 알려줌.

 

lock

  • 사용자가 작업 사본 파일을 수정할 독점적 권리(lock, 잠금)를 요구하는 장치

 

merge

  • 병합은 하나의 브랜치에 대한 변경 사항을 다른 브랜치와 합쳐서 트렁크로 반영하는 것을 의미하며, 반대의 경우도 가능
  • 이때의 다른 브랜치 역시 트렁크일 수 있음.

 

 

리비전(Revisions)

소스 변경 관리 절차를 통해 SVN에 의해 생성

 

 

특징

  • 소스 파일 등을 수정하여 커밋하게 되면 일정한 규칙에 의해 숫자 증가
  • 저장소에 저장된 각각의 파일 버전
  • SVN의 경우 파일별로 리비전이 부여되지 않고 변경 발생 단위로 전체 리비전 부여
  • 여러 개의 파일 중 하나만 변하여 커밋을 하더라도 모든 파일의 버전은 올라가며 버전은 프로젝트 단위로 증가
  • 리비전을 보고 프로젝트 진행 상황 파악 가능

 

특정 소스와 관련된 과거 모든 리비전의 내역을 확인하려면 History를 조회

이클립스의 기본 카테고리인 [Team] → [History] 뷰를 통해 조회 가능

 

 

작업 절차중 발생할 수 있는 충돌을 해결하는 방법

  • postpone
    • 즉시 반영 없이, 소스 코드를 계속 수정
    • 수정이 완료된 시점에 다시 시도하는 방식
    • 즉시 충돌 문제를 해결하지 않는 것

 

  • diff
    • 충돌된 상황을 비교
    • 로컬과 저장소의 소스 차이를 비교

 

  • edit
    • 로컬의 파일을 다시 열어 수정

 

  • mine-full
    • 저장소의 리비전 내용을 무시하고, 로컬의 내용으로 커밋

 

  • theirs-full
    • 로컬의 수정 내역을 무시하고, 저장소의 리비전으로 대체하여 업데이트

 

 

SVN 사용 시나리오

1. 개발자 A가 어떤 파일을 저장소(Repository)에 추가(add)한다.

 

2. 추가되었던 파일을 개발자 A가 체크아웃(check out)한다.

 

3. 개발자 A가 인출된 파일을 수정한 다음, 저장소에 커밋하면서 설명(comment)을 붙인다.

 

4. 다음날 개발자 B가 자신의 작업 공간을 업데이트(update)한다. 이때 개발자 A가 추가했던 파일이 전달된다.

 

5. 개발자 B가 추가된 파일의 체인지 로그(change log)를 보면서 개발자 A가 처음 추가한 파일과 이후 변경된 파일의 차이(diff)를 확인한다.

댓글