버전 관리 체계의 기초 버전 번호 체계는 일반적으로 "메이저.마이너.패치" 형식을 따릅니다. 예를 들어 4.12.8은 유효한 버전 번호로, 4는 메이저 버전, 12는 마이너 버전, 8은 패치 버전을 의미합니다. 이 체계는 20.5.33과 같이 큰 수를 포함할 수 있습니다.
- 메이저 버전: 핵심 기능이 대규모로 변경될 때만 업데이트
- 마이너 버전: 추가 기능이 소규모로 변경될 때만 업데이트
- 패치 버전: 버그 수정만 있을 때만 업데이트
사용자 정의 규칙을 도입할 수도 있습니다.
버전 관리 도구의 핵심 기능 다중 사용자가 협업하는 개발 프로세스에서 문서, 소스 코드 관리의 핵심은 변경 사항을 기록하는 것입니다. 예를 들어, 다음 내용을 SVN에 관리하는 경우:
# 초기 버전
def calculate_sum(a, b):
return a + b
변경 후:
# 2차 버전
def calculate_sum(a, b):
return a + b + 1
이후 최종 버전:
# 3차 버전
def calculate_sum(a, b, c=0):
return a + b + c
버전 관리 시스템은 모든 변경 사항을 추적하고 특정 버전을 재현할 수 있습니다.
SVN 아키텍처와 핵심 개념 SVN은 중앙 집중식 버전 관리 시스템으로, 저장소(Repository)가 핵심입니다. 저장소는 파일과 디렉터리 구조로 정보를 저장하며, 여러 클라이언트가 연결하여 데이터를 읽고 쓸 수 있습니다.
워크 복사본(Working Copy) SVN 서버에서 저장소를 생성한 후 개발자는 작업 디렉터리로 복사(체크아웃)하여 작업합니다. 수정 후 커밋하면 변경 사항이 저장소에 반영됩니다. 다른 사용자는 업데이트를 통해 최신 변경 사항을 확인할 수 있습니다.
수정 번호(Revision) 매번 커밋 시 저장소는 새로운 수정 번호를 부여합니다. 이 번호는 전역적으로 증가하며, 파일 단위가 아닌 전체 저장소 상태를 나타냅니다. 예를 들어, 수정 번호 5에서 파일 A를 수정하고 커밋하면 저장소의 모든 파일이 수정 번호 6을 갖게 됩니다.
프로젝트 구조 설계 프로젝트 시작 시 저장소에 다음과 같은 구조를 생성합니다:
project_root/
├── mainline # 주요 개발 라인
├── devlines # 개발 브랜치
└── releases # 릴리스 태그
개발 프로세스 단계별 구조
- 기획 단계: mainline/docs/requirements.md 생성
- 설계 단계: mainline/docs/design.md 생성
- 구현 단계: mainline/src/ 디렉터리 생성
- 테스트 단계: devlines/4.12 생성 후 테스트
- 릴리스 단계: releases/4.12.8 생성
실용적 명령어 활용 체크아웃
svn co https://svn.example.com/project/mainline project_local
변경 사항 확인
svn status
- M: 로컬 수정됨
- A: 새 파일 추가됨
- D: 삭제된 파일
- C: 충돌 발생
커밋
svn commit -m "API 엔드포인트 수정: 주소 형식 변경" src/api.py
업데이트
svn update
브랜치 생성
svn cp mainline devlines/4.12
메르지
svn merge -r 105:107 devlines/4.12 mainline
svn commit -m "4.12 브랜치의 버그 수정 반영"
태그 생성
svn cp devlines/4.12 releases/4.12.8
로컬 변경 취소
svn revert src/config.yaml
권한 관리 전략
- 주요 문서는 작성자에게 읽기/쓰기 권한 부여
- 검토자에게 읽기 전용 권한 부여
- 릴리스 전에는 릴리스 태그 디렉터리에 쓰기 권한 제한
- 모든 문서는 최종 검토 후 읽기 전용으로 전환