작업 사본에 대해 이미 읽어보셨을 것입니다. 이제 Subversion 클라이언트가 작업 사본을 어떻게 생성하고 사용하는지 보여드리겠습니다.

Subversion 작업 사본은 파일 모음을 포함하는 로컬 시스템의 일반 디렉터리 트리입니다. 이 파일들을 원하는 대로 편집할 수 있으며, 소스 코드 파일인 경우 평소처럼 프로그램을 컴파일할 수 있습니다. 작업 사본은 사용자의 개인 작업 영역입니다. Subversion은 명시적으로 지시할 때까지 다른 사람의 변경 사항을 통합하거나 자신의 변경 사항을 다른 사람에게 제공하지 않습니다.

작업 사본의 파일을 변경하고 제대로 작동하는지 확인한 후, Subversion은 프로젝트에서 함께 작업하는 다른 사람들에게 변경 사항을 게시(저장소에 기록하여)할 수 있는 명령을 제공합니다. 다른 사람들이 자신의 변경 사항을 게시하면, Subversion은 해당 변경 사항을 작업 디렉터리에 병합(저장소에서 읽어와)할 수 있는 명령을 제공합니다.

작업 사본에는 Subversion이 이러한 명령을 수행하는 데 도움이 되도록 생성하고 유지 관리하는 몇 가지 추가 파일도 포함되어 있습니다. 특히, 작업 사본에는 작업 사본의 관리 디렉터리라고도 하는 .svn이라는 하위 디렉터리가 포함되어 있습니다. 이 관리 디렉터리의 파일은 Subversion이 게시되지 않은 변경 사항을 포함하는 파일과 다른 사람의 작업에 대해 오래된 파일이 무엇인지 인식하는 데 도움이 됩니다. 1.7 이전에는 Subversion이 작업 사본의 모든 버전 관리 디렉터리에 .svn 관리 하위 디렉터리를 유지 관리했습니다. Subversion 1.7부터는 완전히 다른 접근 방식을 취하여 각 작업 사본에는 이제 해당 작업 사본 루트의 직계 하위인 단 하나의 관리 하위 디렉터리만 있습니다.

일반적인 Subversion 저장소는 여러 프로젝트의 파일(또는 소스 코드)을 보관하는 경우가 많습니다. 일반적으로 각 프로젝트는 저장소의 파일 시스템 트리에 있는 하위 디렉터리입니다. 이러한 구성에서 사용자의 작업 사본은 일반적으로 저장소의 특정 하위 트리에 해당합니다.

예를 들어, 두 개의 소프트웨어 프로젝트를 포함하는 저장소가 있다고 가정해 보겠습니다.

그림 2.6. 저장소의 파일 시스템

다시 말해, 저장소의 루트 디렉터리에는 paint와 calc라는 두 개의 하위 디렉터리가 있습니다.

작업 사본을 얻으려면 저장소의 일부 하위 트리를 체크아웃해야 합니다. (용어 체크아웃은 잠금 또는 리소스 예약과 관련이 있는 것처럼 들릴 수 있지만, 그렇지 않습니다. 단순히 프로젝트의 개인 사본을 생성하는 것입니다.)

button.c를 변경한다고 가정해 보겠습니다. .svn 디렉터리가 파일의 수정 날짜와 원래 내용을 기억하므로 Subversion은 파일이 변경되었음을 알 수 있습니다. 그러나 Subversion은 명시적으로 지시할 때까지 변경 사항을 공개하지 않습니다. 변경 사항을 게시하는 행위는 저장소에 변경 사항을 커밋(또는 체크인)하는 것으로 더 일반적으로 알려져 있습니다.

다른 사람들에게 변경 사항을 게시하려면 Subversion의 commit 명령을 사용할 수 있습니다.

이제 button.c에 대한 변경 사항이 저장소에 커밋되었습니다. 다른 사용자가 /calc의 작업 사본을 체크아웃하면 파일의 최신 버전에서 변경 사항을 볼 수 있습니다.

당신과 동시에 /calc의 작업 사본을 체크아웃한 협업자 샐리가 있다고 가정해 봅시다. 당신이 button.c에 변경 사항을 커밋해도 샐리의 작업 사본은 변경되지 않은 상태로 유지됩니다. Subversion은 사용자의 요청에 따라서만 작업 사본을 수정합니다.

프로젝트를 최신 상태로 만들려면 샐리는 Subversion update 명령을 사용하여 Subversion에 작업 사본을 업데이트하도록 요청할 수 있습니다. 이렇게 하면 그녀가 체크아웃한 이후 커밋된 다른 변경 사항뿐만 아니라 당신의 변경 사항도 그녀의 작업 사본에 통합됩니다.

샐리가 어떤 파일을 업데이트해야 하는지 지정할 필요가 없었다는 점에 유의하십시오. Subversion은 .svn 디렉터리의 정보와 저장소의 추가 정보를 사용하여 어떤 파일을 최신 상태로 업데이트해야 하는지 결정합니다.

Subversion 저장소는 로컬 디스크 또는 다양한 네트워크 프로토콜을 통해 여러 가지 방법으로 액세스할 수 있습니다. 그러나 저장소 위치는 항상 URL입니다. URL 스키마는 액세스 방법을 나타냅니다.

대부분 Subversion의 URL은 표준 구문을 사용하며, URL의 일부로 서버 이름과 포트 번호를 지정할 수 있습니다. file:// 액세스 방법은 일반적으로 로컬 액세스에 사용되지만, 네트워크 호스트에 대한 UNC 경로와 함께 사용할 수도 있습니다. 따라서 URL은 file://hostname/path/to/repos 형식을 취합니다. 로컬 머신의 경우 URL의 hostname 부분은 없거나 localhost여야 합니다. 이러한 이유로 로컬 경로는 일반적으로 슬래시 세 개와 함께 file:///path/to/repos로 나타납니다.

또한, Windows 플랫폼에서 file:// 스키마를 사용하는 사용자는 동일한 머신에 있지만 클라이언트의 현재 작업 드라이브와 다른 드라이브에 있는 저장소에 액세스하기 위해 비공식적으로 “표준” 구문을 사용해야 합니다. X가 저장소가 있는 드라이브인 경우 다음 두 URL 경로 구문 중 하나가 작동합니다.

file:///X:/path/to/repos
...
file:///X|/path/to/repos
...
      

Windows에서 경로의 기본(비-URL) 형식은 역슬래시를 사용하더라도 URL은 일반 슬래시를 사용한다는 점에 유의하십시오.

네트워크 공유를 통해 FSFS 저장소에 액세스할 수 있지만, 여러 가지 이유로 권장되지 않습니다.

svn commit 작업은 단일 아토믹 트랜잭션으로 여러 파일 및 디렉터리에 대한 변경 사항을 게시할 수 있습니다. 작업 사본에서는 파일 내용을 변경하고, 파일을 생성, 삭제, 이름 변경 및 복사하며, 디렉터리도 마찬가지로 변경한 다음 전체 변경 세트를 하나의 단위로 커밋할 수 있습니다.

저장소에서 각 커밋은 아토믹 트랜잭션으로 처리됩니다. 즉, 모든 커밋 변경 사항이 발생하거나 아무것도 발생하지 않습니다. Subversion은 프로그램 충돌, 시스템 충돌, 네트워크 문제 및 다른 사용자의 작업에도 불구하고 이러한 아토믹성을 유지합니다.

저장소가 커밋을 수락할 때마다 파일 시스템 트리의 새로운 상태가 생성되는데, 이를 리비전이라고 합니다. 각 리비전에는 이전 리비전 번호보다 하나 큰 고유한 자연수가 할당됩니다. 새로 생성된 저장소의 초기 리비전은 0으로 번호가 매겨지며, 비어 있는 루트 디렉터리만으로 구성됩니다.

저장소를 시각화하는 좋은 방법은 일련의 트리로 생각하는 것입니다. 0부터 시작하여 왼쪽에서 오른쪽으로 뻗어 나가는 리비전 번호 배열을 상상해 보세요. 각 리비전 번호 아래에는 파일 시스템 트리가 매달려 있으며, 각 트리는 각 커밋 후 저장소의 모습을 보여주는 “스냅샷”입니다.

그림 2.7. 저장소

작업 사본이 저장소의 단일 리비전에 항상 일치하는 것은 아니라는 점을 주목하는 것이 중요합니다. 작업 사본은 여러 다른 리비전의 파일을 포함할 수 있습니다. 예를 들어, 가장 최근 리비전이 4인 저장소에서 작업 사본을 체크아웃한다고 가정해 보겠습니다.

calc/Makefile:4
integer.c:4
button.c:4
      

현재 이 작업 디렉터리는 저장소의 리비전 4와 정확히 일치합니다. 그러나 button.c를 변경하고 그 변경 사항을 커밋한다고 가정해 봅시다. 다른 커밋이 발생하지 않았다고 가정하면, 당신의 커밋은 저장소의 리비전 5를 생성할 것이고, 당신의 작업 사본은 이제 다음과 같이 보일 것입니다.

calc/Makefile:4
integer.c:4
button.c:5
      

이 시점에서 샐리가 integer.c에 변경 사항을 커밋하여 리비전 6을 생성했다고 가정해 봅시다. svn update를 사용하여 작업 사본을 최신 상태로 만들면 다음과 같이 보일 것입니다.

calc/Makefile:6
integer.c:6
button.c:6
      

샐리의 integer.c 변경 사항이 당신의 작업 사본에 나타날 것이고, 당신의 변경 사항은 여전히 button.c에 남아 있을 것입니다. 이 예시에서 Makefile의 텍스트는 리비전 4, 5, 6에서 동일하지만, Subversion은 Makefile의 작업 사본을 리비전 6으로 표시하여 여전히 최신 상태임을 나타냅니다. 따라서 작업 사본의 최상위에서 깔끔한 업데이트를 수행한 후에는 일반적으로 저장소의 정확히 하나의 리비전에 해당합니다.

작업 디렉터리의 각 파일에 대해 Subversion은 .svn/ 관리 영역에 두 가지 필수 정보를 기록합니다.

이 정보를 바탕으로 Subversion은 저장소와 통신하여 작업 파일이 다음 네 가지 상태 중 어느 상태에 있는지 알 수 있습니다.