SVN편집자 확인

SVN의 저장소는 중앙 집중식 구조를 가진다. 모든 파일의 변경 이력과 메타데이터가 단일 서버에 위치하는 중앙 저장소가 핵심이다. 이 저장소는 일반적으로 서버의 파일 시스템에 특정 디렉터리 구조로 생성되며, 클라이언트는 네트워크를 통해 이 중앙 저장소에 접속하여 작업한다. 저장소는 Berkeley DB 또는 FSFS와 같은 백엔드 저장소 시스템을 사용하여 데이터를 관리한다.

저장소 내부는 파일과 디렉터리의 변경 이력을 리비전 단위로 기록한다. 각 커밋은 저장소 전체에 대해 순차적으로 증가하는 고유한 리비전 번호를 부여받는다. 이는 개별 파일이 아닌 프로젝트 전체의 상태를 특정 시점의 스냅샷으로 관리하는 방식이다. 따라서 특정 리비전 번호를 지정하면 프로젝트의 모든 파일이 그 시점의 상태로 조회될 수 있다.

저장소의 물리적 구조는 일반적으로 conf, dav, db, hooks, locks 등의 표준 디렉터리로 구성된다. 이 중 db 디렉터리가 실제 버전 관리 데이터를 저장하는 핵심 공간이다. hooks 디렉터리는 커밋 전후와 같은 특정 이벤트 발생 시 실행될 스크립트를 배치하여 자동화된 작업을 구현할 수 있게 한다. conf 디렉터리에는 사용자 접근 제어 및 인증 설정 파일이 위치한다.

이러한 중앙 집중식 저장소 구조는 모든 변경 이력이 한 곳에 모여 있어 관리와 백업이 용이하다는 장점이 있다. 또한 모든 사용자가 항상 최신의 중앙 리비전 번호를 기준으로 작업하게 되어 프로젝트 상태에 대한 통일된 뷰를 제공한다. 그러나 서버에 대한 네트워크 의존성이 필수적이며, 서버 장애 시 전체 작업이 중단될 수 있는 단일 장애점이 될 수 있다는 한계도 가진다.

작업 복사본은 SVN 저장소에서 사용자가 실제로 파일을 편집하고 작업하는 로컬 디렉터리이다. 사용자는 체크아웃 명령을 통해 저장소의 특정 리비전을 자신의 컴퓨터로 가져와 작업 복사본을 생성한다. 이 복사본에는 사용자가 직접 수정할 수 있는 파일들과, SVN이 내부 관리를 위해 사용하는 숨겨진 .svn 디렉터리가 포함된다.

작업 복사본은 저장소의 특정 시점 상태를 반영하지만, 사용자의 로컬 변경 사항은 즉시 저장소에 반영되지 않는다. 대신, 사용자는 커밋 명령을 실행해야만 자신의 변경 이력을 저장소에 기록할 수 있다. 이는 중앙 집중식 버전 관리 시스템의 특징으로, 로컬 작업과 공유 저장소 간의 명확한 구분을 제공한다.

.svn 디렉터리는 작업 복사본의 메타데이터를 저장하는 데 핵심적인 역할을 한다. 여기에는 원본 파일의 상태, 최종으로 가져온 리비전 번호, 그리고 업데이트나 커밋 시 필요한 정보 등이 포함된다. 이 메타데이터 덕분에 SVN 클라이언트는 사용자의 로컬 변경 사항과 저장소의 최신 상태를 비교하고, 충돌 해결이 필요한 상황을 감지할 수 있다.

작업 복사본의 상태는 svn status 같은 명령으로 확인할 수 있으며, 파일이 수정됐는지, 추가됐는지, 삭제됐는지, 혹은 저장소와 동기화 상태인지를 보여준다. 사용자는 작업 복사본에서의 변경을 완료한 후 커밋을 통해 팀원들과 작업 결과를 공유하게 된다.

SVN의 버전 관리 모델은 CVS의 한계를 극복하고자 설계된 중앙집중식 저장소를 기반으로 한다. 모든 파일의 변경 이력과 메타데이터는 서버에 위치한 단일 저장소에 저장되며, 사용자는 작업 복사본이라는 로컬 사본을 통해 작업한다. 이 모델의 핵심은 원자적 커밋이다. 한 번의 커밋 작업에서 여러 파일과 디렉터리에 대한 변경 사항이 하나의 논리적 단위로 처리되어 저장소에 기록된다. 이는 부분적 커밋으로 인해 발생할 수 있는 저장소 불일치 상태를 방지하며, 각 커밋은 고유한 리비전 번호를 부여받아 프로젝트 전체의 상태를 특정 시점으로 명확히 식별할 수 있게 한다.

버전 관리 대상은 파일의 내용뿐만 아니라 디렉터리 구조와 메타데이터까지 포함한다. SVN은 파일과 디렉터리의 복사, 이동, 삭제, 이름 변경과 같은 트리 구조 변경 작업도 버전 관리가 가능한 작업으로 기록한다. 이는 CVS가 파일 중심으로만 버전을 관리했던 것과 대비되는 중요한 발전이다. 모든 버전은 증분 방식이 아닌 전체 스냅샷 방식으로 저장되지 않으며, 대부분의 최신 버전 관리 시스템과 마찬가지로 변경된 부분만 효율적으로 저장한다.

버전 관리 모델은 분기와 태그 작업을 매우 가볍고 저렴한 비용의 연산으로 만든다. 분기나 태그 생성은 저장소 내에서 파일과 디렉터리에 대한 참조를 복사하는 방식으로 이루어지며, 실제 데이터의 물리적 복사본을 만들지 않는다. 이 카피-온-라이트 방식은 저장 공간을 절약하고, 분기 생성 속도를 빠르게 하여 개발자가 기능 개발이나 실험을 위해 자주 분기를 활용할 수 있도록 장려한다.

체크아웃은 SVN 저장소에서 특정 버전의 파일과 디렉터리를 사용자의 로컬 컴퓨터로 가져오는 작업이다. 이 과정을 통해 생성된 로컬 사본을 작업 복사본이라고 한다. 사용자는 이 작업 복사본에서 파일을 수정, 추가, 삭제할 수 있다. 체크아웃은 일반적으로 프로젝트에 처음 참여할 때 한 번 수행하며, 이후 변경 사항을 동기화할 때는 업데이트 명령을 사용한다.

커밋은 사용자가 작업 복사본에서 수행한 모든 변경 사항을 저장소에 기록하는 작업이다. 커밋을 수행하면 수정된 파일의 내용, 새로 추가된 파일, 삭제된 파일의 정보 등이 저장소에 전송되어 새로운 리비전으로 저장된다. 각 커밋은 고유한 리비전 번호를 부여받으며, 변경 내용에 대한 로그 메시지를 함께 기록해야 한다. 이를 통해 프로젝트의 변경 이력을 추적하고 특정 시점으로 되돌리는 것이 가능해진다.

체크아웃과 커밋은 SVN의 기본적인 작업 흐름을 구성한다. 개발자는 저장소에서 최신 코드를 체크아웃받아 작업을 시작하고, 작업이 완료되면 변경 사항을 커밋하여 팀원들과 공유한다. 이때 커밋은 원자적으로 처리되어 모든 변경 사항이 성공적으로 저장되거나, 아무것도 저장되지 않는 방식으로 데이터의 일관성을 보장한다.

업데이트는 작업 복사본을 저장소의 최신 리비전 상태로 동기화하는 작업이다. 사용자는 이 명령을 통해 다른 팀원들이 커밋한 변경 사항을 자신의 로컬 작업 공간으로 가져올 수 있다. 업데이트 과정에서 SVN은 서버의 변경 내역과 로컬 파일을 비교하여, 충돌이 발생하지 않는 변경 사항은 자동으로 병합한다. 이는 협업 과정에서 모든 구성원이 최신 코드 베이스를 유지하도록 보장하는 핵심 기능이다.

병합은 두 개 이상의 분기나 리비전 간의 차이점을 통합하는 작업이다. SVN은 병합을 위해 3-way 병합 알고리즘을 사용하는데, 이는 원본 파일과 두 개의 수정된 파일을 비교하여 변경 사항을 조화롭게 합친다. 병합은 주로 기능 개발이 완료된 브랜치를 트렁크에 통합하거나, 특정 버그 수정 사항을 여러 분기에 적용하는 등의 시나리오에서 수행된다.

병합 작업 시 충돌이 발생할 수 있다. 충돌은 동일한 파일의 동일한 부분을 서로 다른 사용자가 다르게 수정했을 때 일어난다. SVN은 충돌이 감지되면 자동 병합을 중단하고, 사용자가 직접 충돌을 검토하고 해결하도록 유도한다. 충돌 해결 후에는 해당 파일에 대해 '해결됨'으로 표시하고 변경 사항을 커밋하여 병합을 완료한다.

SVN은 병합 정보를 메타데이터로 기록하여, 동일한 변경 세트의 반복적 병합을 방지하는 병합 추적 기능을 제공한다. 이는 병합 역사를 관리하고 실수로 동일한 변경을 두 번 적용하는 것을 막아준다. 또한, svn mergeinfo 명령을 통해 어떤 변경 사항이 이미 병합되었는지 확인할 수 있어 병합 작업의 정확성을 높인다.

분기는 개발 라인을 독립적으로 복제하여 병렬 작업을 가능하게 하는 기능이다. 주로 새로운 기능 개발이나 실험적인 작업, 주요 릴리스의 유지보수를 위해 사용된다. SVN에서 분기는 저장소 내부의 디렉토리 복사본으로 생성되며, 이는 가벼운 복사본으로 실제 데이터를 중복 저장하지 않아 효율적이다. 분기된 작업은 이후 필요에 따라 트렁크 또는 다른 분기에 다시 병합될 수 있다.

태그는 특정 시점의 프로젝트 상태에 이름을 붙여 고정된 스냅샷을 만드는 기능이다. 주로 소프트웨어의 공식 릴리스 버전(예: v1.0.0)을 표시하는 데 사용된다. SVN에서 태그는 분기와 동일한 기술적 메커니즘(디렉토리 복사)을 사용하여 생성되지만, 일반적으로 태그는 변경되지 않는 참조 지점으로 간주되므로 추가 커밋이 이루어지지 않는다는 점에서 용도가 다르다.

SVN의 분기와 태그 작업은 svn copy 명령어를 사용하여 수행된다. 이 명령은 원격 저장소의 URL 간에 직접 실행될 수 있어, 작업 복사본을 로컬에 먼저 가져올 필요 없이 빠르게 작업을 완료할 수 있다. 이는 중앙 집중식 버전 관리 시스템의 특징을 활용한 것이다.

분기와 태그 관리를 위한 표준적인 저장소 레이아웃을 사용하는 것이 일반적이다. 대표적인 구조는 다음과 같다.

이러한 구조는 프로젝트의 변경 이력을 체계적으로 관리하고, 팀원 간의 협업을 명확하게 하는 데 도움을 준다.

충돌은 둘 이상의 사용자가 동일한 파일의 동일한 부분을 서로 다른 방식으로 수정하고, 그 변경 사항을 저장소에 커밋하려 할 때 발생한다. SVN은 이러한 충돌을 감지하고, 사용자가 직접 해결할 수 있도록 돕는 메커니즘을 제공한다. 충돌이 발생하면 SVN은 해당 파일을 충돌 상태로 표시하며, 자동으로 병합할 수 없는 부분을 특수한 마커와 함께 파일에 남겨둔다.

충돌 해결 과정은 일반적으로 세 단계로 이루어진다. 첫째, 사용자는 svn update 명령을 실행하여 최신 변경 사항을 가져올 때 충돌이 감지된다. 둘째, SVN은 충돌이 발생한 파일에 .mine, .rOLD, .rNEW와 같은 접미사가 붙은 사본을 생성하고, 원본 파일 내부에는 <<<<<<< .mine, =======, >>>>>>> .rNEW와 같은 충돌 마커를 삽입하여 상충하는 변경 내용을 명시적으로 보여준다. 셋째, 사용자는 이러한 마커를 확인하고, 최종적으로 적용할 코드나 내용을 직접 편집하여 결정한 후, svn resolved 명령으로 충돌 해결을 완료하고 파일을 정상 상태로 만든다.

충돌을 해결하는 방법은 주로 수동 편집이지만, SVN 클라이언트 도구들은 이 과정을 보다 쉽게 만들어준다. 많은 GUI 클라이언트와 IDE 통합 도구는 시각적인 병합 도구를 제공하여 양쪽 변경 사항을 나란히 비교하고, 사용자가 클릭만으로 특정 변경을 선택할 수 있도록 한다. 또한 svn merge 명령을 활용하여 특정 리비션 간의 차이를 미리 검토하는 것도 예방적인 접근법이 될 수 있다. 효과적인 충돌 관리를 위해서는 팀원 간의 소통과 잦은 업데이트가 필수적이다.

권한 관리는 SVN 저장소의 특정 디렉토리나 파일에 대한 접근을 제어하는 기능이다. 이를 통해 프로젝트 관리자는 누가 어떤 작업을 할 수 있는지를 세밀하게 설정할 수 있으며, 이는 특히 대규모 팀이나 오픈소스 프로젝트에서 중요한 보안 및 협업 수단이 된다.

SVN의 권한 관리는 주로 서버 측에서 구성된다. Apache HTTP 서버와 연동된 경우, 표준 Apache 인증 및 권한 부여 모듈을 사용하여 사용자와 그룹을 정의하고, authz 파일을 통해 경로 기반의 접근 규칙을 설정한다. 예를 들어, 특정 디렉토리에 대한 읽기 권한은 모든 개발자에게 부여하되, 쓰기 권한은 특정 그룹의 멤버에게만 제한하는 방식이다.

권한은 일반적으로 읽기와 쓰기 두 가지 수준으로 구분된다. 저장소의 루트 경로부터 시작하여 하위 경로별로 다른 규칙을 중첩하여 적용할 수 있어 유연한 정책 구현이 가능하다. 이는 트렁크, 브랜치, 태그와 같은 표준 저장소 구조 각각에 서로 다른 접근 정책을 부여하는 데 유용하게 활용된다.

권한 관리 설정은 svnserve 데몬을 사용할 때도 유사한 방식으로 지원되며, 클라이언트 도구를 통해 접근 시도 시 투명하게 적용된다. 효과적인 권한 관리는 프로젝트의 무결성을 유지하고, 실수나 악의적인 변경을 방지하는 데 기여한다.

SVN의 명령줄 클라이언트는 svn이라는 이름의 실행 파일로 제공된다. 이 도구는 SVN의 모든 핵심 기능을 터미널이나 명령 프롬프트 환경에서 직접 실행할 수 있게 해주며, 서버와의 모든 상호작용을 처리한다. 사용자는 이 클라이언트를 통해 저장소를 체크아웃하거나, 파일 변경 사항을 커밋하고, 다른 개발자의 작업을 업데이트하며, 분기와 태그를 생성하는 등 다양한 버전 관리 작업을 수행할 수 있다.

명령어는 일반적으로 svn <하위명령> [옵션] [인자]의 형태로 구성된다. 주요 하위 명령어로는 저장소 복사본을 생성하는 checkout, 변경 사항을 서버에 반영하는 commit, 최신 변경 사항을 가져오는 update, 두 변경 이력을 합치는 merge, 파일의 상태를 확인하는 status, 변경 이력을 조회하는 log 등이 있다. 이러한 명령어들은 스크립트에 통합하거나 다른 도구와 연동하기에 용이하다.

명령줄 클라이언트는 GUI 클라이언트나 IDE 통합 도구의 기반이 되기도 한다. 많은 GUI 클라이언트들은 내부적으로 이 명령줄 도구를 호출하여 기능을 실행한다. 따라서 명령줄 인터페이스를 익히면 SVN 시스템의 동작 원리를 더 깊이 이해하고, 복잡한 작업을 자동화하거나 서버 문제를 진단하는 데 유용하다. Apache Subversion 프로젝트는 이 명령줄 도구를 공식적으로 배포하고 유지 관리한다.

SVN은 명령줄 인터페이스뿐만 아니라 다양한 그래픽 사용자 인터페이스 클라이언트를 지원하여 사용자 접근성을 높인다. 이러한 GUI 클라이언트는 버전 관리의 복잡한 명령어를 시각적으로 직관적인 작업으로 변환해주며, 특히 초보 사용자나 소프트웨어 개발 과정에서 변경 이력을 시각적으로 확인하고자 하는 사용자들에게 유용하다.

가장 널리 알려진 SVN GUI 클라이언트로는 TortoiseSVN이 있다. 이 클라이언트는 마이크로소프트 윈도우의 파일 탐색기에 직접 통합되어, 사용자는 파일이나 폴더를 마우스 오른쪽 버튼으로 클릭하는 컨텍스트 메뉴를 통해 대부분의 SVN 작업을 수행할 수 있다. 커밋, 업데이트, 변경 이력(로그) 조회, 분기 및 병합 작업 등을 그래픽 인터페이스로 쉽게 처리할 수 있다는 점이 큰 장점이다.

리눅스 및 macOS 환경에서는 RabbitVCS와 같은 도구가 비슷한 기능을 제공한다. 또한, 이클립스나 인텔리J IDEA와 같은 통합 개발 환경(IDE)에는 SVN 클라이언트 기능이 플러그인 형태로 내장되어 있어, 개발자가 코드 편집 환경에서 직접 버전 관리 작업을 수행할 수 있게 한다. 이러한 다양한 GUI 클라이언트의 존재는 SVN이 다양한 운영 체제와 개발 워크플로우에 광범위하게 적용될 수 있도록 하는 데 기여했다.

많은 통합 개발 환경은 SVN 클라이언트 기능을 내장하거나 플러그인을 통해 지원하여 개발자가 IDE 내에서 직접 버전 관리 작업을 수행할 수 있게 한다. 이를 통해 코드 편집, 빌드, 디버깅과 같은 개발 작업과 버전 관리를 하나의 환경에서 통합적으로 처리할 수 있어 개발 효율성을 높인다.

주요 IDE들의 SVN 통합 방식은 다양하다. 이클립스는 Subclipse나 Subversive와 같은 전용 플러그인을 통해 강력한 SVN 지원을 제공한다. JetBrains 사의 IntelliJ IDEA, PyCharm, WebStorm 등은 기본적으로 내장된 버전 관리 도구를 통해 SVN을 지원한다. Microsoft의 Visual Studio도 VisualSVN이나 AnkhSVN 같은 확장을 설치하여 SVN과의 연동이 가능하다. 이러한 통합은 체크아웃, 커밋, 업데이트, 병합, 변경 이력 조회 등의 핵심 기능을 그래픽 인터페이스로 쉽게 접근할 수 있게 한다.

IDE 통합의 주요 이점은 개발 워크플로우의 간소화에 있다. 개발자는 별도의 명령줄 클라이언트나 GUI 클라이언트를 열지 않고도, 현재 편집 중인 파일의 상태를 실시간으로 확인하고, 변경 사항을 즉시 커밋하거나 저장소의 최신 변경 내역을 가져올 수 있다. 또한, 충돌 해결 도구가 IDE의 코드 편집기와 긴밀하게 연동되어 병합 충돌을 시각적으로 해결하는 데 유용하다.

이러한 통합은 특히 대규모 소프트웨어 개발 프로젝트에서 협업 효율을 높이는 데 기여한다. 팀원들은 익숙한 개발 환경을 벗어나지 않으면서도 프로젝트의 버전 관리 정책을 준수할 수 있으며, 코드 변경과 버전 관리 기록이 자연스럽게 연결된다.

Apache HTTP 서버와의 연동은 SVN 저장소에 네트워크를 통한 접근을 제공하는 가장 일반적인 방법 중 하나이다. 이 구성을 통해 사용자는 표준 HTTP나 HTTPS 프로토콜을 사용하여 저장소에 접근할 수 있으며, 웹 브라우저를 통한 기본적인 저장소 탐색도 가능해진다.

연동의 핵심은 mod_dav와 mod_dav_svn이라는 두 개의 Apache 모듈이다. mod_dav는 WebDAV 및 DeltaV 프로토콜을 구현하여 HTTP를 통해 파일 시스템과 유사한 작업을 가능하게 하는 모듈이다. mod_dav_svn은 SVN 저장소를 mod_dav가 이해할 수 있는 가상 파일 시스템으로 제공하는 서브버전 전용 모듈로, 이 두 모듈이 함께 작동하여 Apache HTTP 서버가 SVN 클라이언트의 요청을 처리할 수 있게 한다.

이 구성을 설정하려면 먼저 Apache HTTP 서버에 필요한 모듈들을 로드하고, 가상 호스트 설정이나 주요 설정 파일 내에 SVN 저장소의 위치를 지정하는 Location 지시어를 구성해야 한다. 이 지시어 내에서는 저장소의 물리적 경로, 사용할 인증 방식(예: 기본 인증, LDAP 인증), 그리고 접근 제어 규칙을 정의한다. SSL/TLS를 사용한 HTTPS 연결 설정은 통신 보안을 위해 권장되는 방법이다.

Apache와의 연동은 중앙 집중식 인증 및 권한 관리를 Apache HTTP 서버의 메커니즘에 위임할 수 있다는 장점이 있다. 또한 기존의 방화벽 정책이나 리버스 프록시 설정을 그대로 활용할 수 있어 기업 환경에서의 배포와 유지 관리가 상대적으로 용이하다.

svnserve 데몬은 Apache Subversion 저장소에 접근하기 위한 전용 서버 프로세스이다. Apache HTTP 서버와 같은 복잡한 웹 서버를 사용하지 않고도, Subversion 프로토콜을 직접 처리하는 간단하고 가벼운 서버를 구성할 수 있다. 이 데몬은 독립 실행형 서버로 동작하며, 클라이언트는 svn:// 또는 svn+ssh:// 스키마를 사용하여 서버에 연결한다. 기본적으로 3690번 포트를 사용하며, 설정 파일을 통해 인증, 권한 부여, 네트워크 설정 등을 관리할 수 있다.

svnserve의 주요 구성 요소는 svnserve 실행 파일과 저장소별 conf 디렉터리 내의 설정 파일들이다. 가장 중요한 설정 파일은 svnserve.conf로, 여기서 익명 접근 허용 여부, 인증 데이터베이스 경로, 권한 관리 파일 지정 등을 설정한다. 인증은 일반적으로 passwd 파일을 통해 평문 비밀번호를 관리하거나, SASL을 통한 더 강력한 인증 방식을 사용할 수 있다. 세분화된 접근 제어는 authz 파일을 통해 특정 사용자나 그룹에 대해 저장소 경로별 읽기/쓰기 권한을 부여하는 방식으로 이루어진다.

이 데몬은 주로 내부 네트워크 환경이나 소규모 팀에서 간편하게 버전 관리 시스템을 구축할 때 유용하다. Apache HTTP 서버와 WebDAV 모듈을 연동하는 방식에 비해 설정이 단순하고 오버헤드가 적다는 장점이 있다. 그러나 SSL/TLS를 통한 기본적인 암호화 지원이 없어, 보안이 중요한 환경에서는 svn+ssh:// 터널을 사용하거나 Apache HTTP 서버 기반 구성을 권장한다.

SVN의 저장소 관리는 서버 측에 위치한 중앙 집중식 데이터베이스를 생성, 유지 및 관리하는 작업을 포함한다. 저장소는 모든 파일과 디렉터리의 모든 버전 이력을 저장하는 핵심 구성 요소이다. 관리자는 svnadmin 명령줄 도구를 사용하여 새로운 저장소를 생성하거나, 기존 저장소를 백업 및 복구하며, 저장소의 무결성을 검증하는 작업을 수행한다.

저장소 관리의 중요한 측면 중 하나는 접근 제어 설정이다. Apache HTTP 서버와 연동된 저장소의 경우, authz 파일을 통해 디렉터리별로 사용자나 그룹의 읽기/쓰기 권한을 세밀하게 구성할 수 있다. 또한 svnserve 데몬을 사용할 경우에는 svnserve.conf 파일에서 네트워크 접근 정책과 인증 방식을 설정한다.

저장소의 데이터는 베리전 트랜잭션 방식으로 관리되며, 관리자는 필요에 따라 불필요한 트랜잭션을 정리하거나 저장소를 더 작은 덤프 파일로 내보내고 다시 불러오는 작업을 수행할 수 있다. 이러한 관리 작업은 서비스 중단 없이 핫 백업을 수행할 수 있도록 설계되어 있으며, 대규모 프로젝트의 장기적인 변경 이력을 안정적으로 보관하는 데 필수적이다.

SVN과 Git은 모두 널리 사용되는 버전 관리 시스템이지만, 설계 철학과 작동 방식에서 근본적인 차이를 보인다. 가장 큰 차이는 저장소 구조와 네트워크 의존도에 있다. SVN은 중앙집중식 클라이언트-서버 모델을 채택한다. 개발자는 중앙 서버에 위치한 단일 저장소를 바라보며 작업하며, 체크아웃을 통해 얻는 작업 복사본은 단순히 특정 리비전의 파일 모음이다. 반면 Git은 분산 버전 관리 시스템으로, 각 개발자의 로컬 환경에 전체 저장소 역사를 포함한 완전한 복제본이 존재한다. 이는 네트워크 연결 없이도 대부분의 작업(커밋, 분기 생성, 병합 등)을 로컬에서 수행할 수 있음을 의미한다.

두 시스템의 데이터 모델과 변경 이력 추적 방식도 다르다. SVN은 파일 중심의 변경 이력을 관리하며, 각 커밋은 저장소 전체의 순차적인 스냅샷인 리비전 번호로 식별된다. Git은 컨텐츠 주소 지정 파일 시스템을 기반으로 하며, 스냅샷의 해시 값을 통해 커밋을 고유하게 식별한다. 또한 Git은 변경 내용을 델타가 아닌 전체 파일의 스냅샷으로 저장하는 경향이 있어 분기 생성과 병합이 매우 가볍고 빠르다. SVN에서 분기와 태그는 중앙 저장소 내의 특수한 디렉토리 복사본으로 구현되는 반면, Git에서는 단순히 특정 커밋을 가리키는 포인터일 뿐이다.

워크플로우 측면에서도 차이가 명확하다. SVN의 표준 작업 흐름은 중앙 저장소에서 최신 변경 사항을 업데이트 받아 작업 복사본을 갱신한 후, 변경 내용을 중앙 서버에 직접 커밋하는 것이다. Git에서는 로컬 저장소에서 자유롭게 커밋을 쌓아 올린 후, 원격 저장소와 동기화할 준비가 되었을 때 푸시 명령을 통해 변경 사항을 공유한다. 이는 SVN에 비해 커밋을 더 작은 단위로 자주 할 수 있도록 하며, 히스토리 재작성(리베이스 등)과 같은 유연한 작업을 가능하게 한다. 그러나 이러한 분산 구조는 초보자에게 학습 곡선을 더 가파르게 만들기도 한다.

SVN은 CVS의 한계를 극복하고자 설계된 버전 관리 시스템이다. 가장 큰 차이점은 파일과 디렉토리의 버전 관리 방식에 있다. CVS는 파일의 변경 이력만을 추적하는 반면, SVN은 파일뿐만 아니라 디렉토리, 심볼릭 링크, 메타데이터까지 하나의 개체로 취급하여 버전 관리를 한다. 이로 인해 파일 이동이나 디렉토리 구조 변경과 같은 작업도 정확한 이력으로 기록되고 추적이 가능해졌다.

버전 번호 체계에서도 차이가 나타난다. CVS는 각 파일마다 독립적인 버전 번호를 부여하지만, SVN은 커밋을 기준으로 저장소 전체에 걸쳐 글로벌한 일련번호인 리비전을 부여한다. 이는 특정 시점의 프로젝트 전체 상태를 하나의 리비전 번호로 쉽게 참조할 수 있게 하여, 프로젝트 단위의 버전 관리와 롤백을 훨씬 직관적으로 만든다.

원자적 커밋의 지원 여부도 중요한 차이점이다. CVS에서는 여러 파일에 걸친 변경 사항을 커밋할 때 일부 파일만 성공하고 나머지는 실패하는 부분적 커밋이 발생할 수 있다. 반면 SVN의 커밋 작업은 원자성을 보장하여, 모든 변경 사항이 성공적으로 적용되거나 아니면 아무것도 적용되지 않는다. 이는 저장소의 데이터 무결성을 크게 향상시킨다.

마지막으로, 네트워크 프로토콜과 성능 면에서도 개선이 이루어졌다. CVS가 주로 사용하던 pserver 프로토콜에 비해, SVN은 자체 svnserve 데몬이나 Apache HTTP 서버와의 연동을 통해 더욱 안전하고 효율적인 통신을 지원한다. 또한 바이너리 파일 처리와 같은 작업에서도 CVS보다 향상된 성능을 보인다.