공공, 금융, 제조 고객사는 이미 승인된 SVN 서버와 권한 체계를 유지하는 경우가 있습니다.
이 파트에서 다루는 내용
SVN은 아직 현장에서 만날 수 있는 도구입니다
SVN은 오래된 도구이지만 사라진 도구는 아닙니다. 고객사 표준, 폐쇄망, 보안 정책, 기존 배포 자동화, 감사 이력 때문에 SVN을 계속 써야 하는 프로젝트가 있습니다.
실무에서는 내가 선호하는 도구보다 고객사와 운영 환경의 제약이 우선입니다. SVN을 만나면 낡았다고 넘기기보다 현재 운영 기준을 정확히 읽어야 합니다.
외부 GitHub 접근은 막혀도 내부 SVN 서버는 오래 전부터 운영 중일 수 있습니다.
릴리스 태그, 배포 스크립트, 장애 추적 자료가 SVN revision 기준으로 쌓여 있을 수 있습니다.
SVN은 중앙 서버가 진실입니다
Git은 로컬에 전체 이력을 갖지만, SVN은 중앙 저장소가 기준입니다. 개발자는 서버에서 working copy를 checkout하고, 변경을 commit하면 서버 revision이 증가합니다.
로컬 commit이라는 개념이 없기 때문에 SVN commit은 곧 팀 저장소에 반영되는 작업입니다. commit 전 diff와 대상 경로 확인이 특히 중요합니다.
서버에 있는 기준 저장소입니다. revision 번호는 저장소 전체 기준으로 증가합니다.
checkout으로 받은 로컬 작업 폴더입니다. 내부에 SVN 메타데이터가 있어 상태를 추적합니다.
커밋이 생길 때마다 증가하는 서버 기준 번호입니다. 장애 추적과 배포 기록에서 자주 쓰입니다.
trunk, branches, tags는 폴더 약속입니다
SVN의 trunk, branches, tags는 Git처럼 특별한 객체가 아니라 저장소 안의 디렉터리 구조입니다. 팀이 이 구조를 어떻게 쓰기로 했는지가 중요합니다.
대부분 trunk는 주 개발선, branches는 기능·릴리스 분기, tags는 특정 릴리스 스냅샷으로 씁니다. 다만 오래된 프로젝트는 표준 구조가 아닐 수 있으므로 먼저 저장소 구조를 확인해야 합니다.
svn list <repo-url>저장소 최상위 폴더 구조 확인svn list <repo-url>/trunktrunk 아래 실제 프로젝트 구조 확인svn info현재 working copy가 어느 URL과 revision을 바라보는지 확인SVN 프로젝트에 투입되면 checkout 전에 저장소 URL, trunk 경로, 릴리스 태그 경로, 커밋 권한 범위를 먼저 확인하세요.
운영 담당자는 저장소 구조와 복구 기준을 먼저 정합니다
SVN 서버를 운영하는 담당자는 checkout 명령만 안내해서는 부족합니다. 저장소 생성 위치, trunk/branches/tags 표준 폴더, 사용자 권한, 커밋 로그 규칙, 백업과 복구 절차를 함께 정해야 합니다.
SVN은 중앙 저장소가 기준이므로 서버 장애나 권한 오설정의 영향이 큽니다. 신규 저장소를 만들 때는 표준 구조를 먼저 만들고, 실제 팀원이 커밋하기 전에 권한과 백업이 동작하는지 확인합니다.
서버에서 repository를 만들고 팀 표준에 맞게 trunk, branches, tags 폴더를 준비합니다.
읽기 권한, 커밋 권한, 태그 생성 권한을 나눕니다. tags 경로는 일반 개발 커밋을 막는 정책을 두는 편이 안전합니다.
중앙 저장소 장애에 대비해 hotcopy나 서버 백업 절차를 문서화합니다. 백업은 복구 테스트까지 해야 의미가 있습니다.
svnadmin create /srv/svn/project서버에서 새 SVN 저장소 생성svn mkdir file:///srv/svn/project/trunk file:///srv/svn/project/branches file:///srv/svn/project/tags -m "init standard layout"표준 폴더 구조 생성svnadmin hotcopy /srv/svn/project /backup/svn/project저장소 백업 사본 생성svn list <repo-url>팀에 안내하기 전 저장소 구조 확인SVN 운영에서 가장 중요한 기준은 중앙 저장소가 안전하게 남아 있고, 누가 어느 경로에 쓸 수 있는지 명확한 상태를 유지하는 것입니다.