Appendix A. WebDAV 와 자동 버전화

A.1.1. WebDAV

RFC 2518 은 몇 가지 개념과 거기에 동반하는 HTTP 1.1 의 확장 메소드를 정의하고 있습니다. 그것은 웹을 좀 더 보편적인 읽고 쓰기 가능한 매체로 만들어주는 것입니다. WebDAV 호환 웹 서버는 일반적인 파일 서버처럼 동작할 수 있고, 클라이언트는 WebDAV의 "공유"를 NFS나 SMB 공유처럼 마운트 할 수 있다는 것이 기본적인 개념입니다.

그러나 RFC 2518 은 DAV라는 말 중에 "V"가 있음에도 불구하고, 어떤 종류의 버전(Version) 관리 모델도 제공하지 않습니다. 기본적인 WebDAV 클라이언트와 서버는 파일이나 디렉토리가 하나의 버전만 존재한다고 가정하고, 그것을 계속해서 덮어씁니다. [1]

기본적인 WebDAV에서 도입된 새로운 개념과 메소드는 다음과 같습니다.

A.1.2. DeltaV 확장

RFC 2518 은 버전관리라는 개념이 없기 때문에, WebDAV에 버전 관리 기능을 추가한 RFC 3253을 쓰는 일이 다른 그룹에 맡겨졌습니다. WebDAV/DeltaV 클라이언트와 서버는 자주 "DeltaV" 클라이언트와 서버로 불립니다. DeltaV는 기본적인 WebDAV의 존재를 포함하고 있기 때문입니다.

DeltaV 는 완전히 새로운 단어를 도입했습니다만, 놀라지 마세요. 생각은 매우 직관적입니다. DeltaV로 도입된 새로운 개념과 메소드는:

A.2.1. Subversion 의 DeltaV에의 매핑

다양한 Subversion 클라이언트의 조작이 DeltaV를 사용하는 방법 의 매우"하이레벨의" 방식을 들어 둡니다. 대부분의 경우, 이러한 설명은 단순화 너무 하고 있습니다. Subversion의 원시 코드를 읽거나 개발자에게 (듣)묻거나 하는 것의 대신에 된다고는생각하지 말아주세요.

A.2.2. 자동 버전화의 서포트

집필 시점에서, 이 세상에게는 아직 매우 몇 안 되는 종류의 DeltaV 클라이언트 밖에 없다고 하는 것이 현실입니다. RFC 3253 은 아직 비교적 새로운 규격입니다. 그러나, 유저는"범용적인"클라이언트에 액세스 한다 (이)가 할 수 있습니다. 그것은, 거의 모든 현대적인 오퍼레이팅(operating) 시스템은, 통합된 기본적인 WebDAV 클라이언트를 실장하고 있기 때문입니다. 이것을 마음에 세워, Subversion 개발자는 만약 Subversion1. 0이 어떠한 제휴 기능을 가지게 된다고 해도, DeltaV의 자동 버전화의 구조를 서포트하는 것이 가장 좋은 선택 (이)라고 생각하고 있습니다.

mod_dav_svn 의 자동 버전화의 구조를 유효하게 하려면 , httpd.conf 파일의 Location블록으로, SVNAutoversioning 명령을 사용해 주세요. 이런 느낌입니다:

Location /repos
  DAV svn
  SVNPath /absolute/path/to/repository
  SVNAutoversioning on
/Location

보통, WebDAV 클라이언트가 저장소(repository)의 장소에 있는 패스에 PUT 를 발행하면(자), mod_dav_svn는 그 요구를 무조건 거부합니다. (그것은 보통은, DeltaV"액티버티"에 있다 "작업 자원"상에 그러한 조작을 허락할 뿐입니다). 그러나SVNAutoversioning 를 유효하게 하면(자), 그 서버는PUT 요구를 횡령해, 내부적으로는 MKACTIVITY, CHECKOUT, PUT, CHECKIN의 일련의 명령으로서 처리합니다. 일반적인 로그 메세지가 자동적으로 생성되어 새로운 파일 시스템 리버전이 만들어집니다.

매우 많은 operating system가 벌써 통합되었다 WebDAV 능력을 가지고 있으므로, 이 기능의 이용 형태는 매우 훌륭하다 물건이 됩니다: Microsoft Windows 나 Mac OS 를 실행하고 있는 보통 유저가 있는 오피스를 상상해 보세요. 각각의 컴퓨터 (은)는 Subversion의 저장소(repository)를"마운트" 하고 있어, 그것은 보통 네트워크 공유로 보입니다. 그들은 평상시 하고 있도록(듯이) 서버를 사용하겠지요: 서버의 파일을 열어, 편집해, 서버 써 되돌립니다. 그러나, 이 이야기 중(안)에서는, 서버는 모든 것을 자동적으로 버전화합니다. 나중에, 시스템 관리 책임자가 Subversion 클라이언트 (을)를 사용해, 모든 낡은 버전을 검색해, 추출할 수가 있습니다.

이 이야기는, 현실로 할 수 있는 것일까요? 아니, 아직 완전하게는. 제일의 장해는 Subversion1. 0 은 WebDAV의LOCK (이)나UNLOCK 메소드를 서포트하고 있지 않다고 한다 일입니다. 대부분의 operating system의 DAV 클라이언트는 DAV의 형태로 마운트된 네트워크 공유로부터 직접 열린 자원에 대해LOCK 하려고 합니다. 현재, 유저는 DAV 공유로부터 파일을 로컬 디스크에 카피해, 편집해, 그리고 한번 더, 서버에 써 되돌리지 않으면 안됩니다. 이상적인 자동 버전화는 할 수 없습니다만, 그런데도, 작업할 수 있습니다.

A.2.3. mod_dav_lock에 의한 대안

mod_dav Apache 모듈은 복잡한 모듈입니다: 그것은 모든 WebDAV와 DeltaV 메소드를 이해해 해석하는 것이 할 수 있습니다. 그러나, 아직 자원 자신에게 액세스 하려면 연구 최종 단계의 "공급 모듈" 에 의존하고 있습니다.

제일 간단한 경우로서는, 유저는 mod_dav_fs 를 mod_dav의 공급 모듈로서 이용할 수가 있습니다. mod_dav_fs 는 통상의 파일 시스템을 파일이나 디렉토리를 격납하는 장소에 이용 해, 기본적인 WebDAV 메소드만을 이해합니다. DeltaV는 이해 성과 선.

한편 Subversion는 mod_dav_svn 를 mod_dav 의 공급 모듈로서 사용합니다. mod_dav_svn는LOCK를 들여다 보았다 모든 WebDAV 메소드를 이해해, DeltaV 메소드의 상당한 부분을 이해 합니다. 그것은 진짜 파일 시스템에 있다고 하는 것보다도, Subversion 저장소(repository)에 있는 데이터에 액세스 합니다. Subversion 1.0 은 락을 서포트합니다만, 그것은 Subversion가 카피·수정·머지 모델을 사용하고 있는 것으로, 실제로 실장하는 것이 매우 어렵기 때문입니다. [2]

Apache httpd-2. 0 으로, mod_dav 는, 공급 모듈은 그것을 받아들인다 뜻이 있다고 하는 전제 앞으로, 사적인 데이타베이스에 걸치는 락을 기록하는 것에 의해LOCK 메소드를 서포트합니다. 그러나 Apache httpd-2. 1 이후에서는 이 락의 서포트는 독립한 모듈 mod_dav_lock 에 분할 됩니다. 이 모듈은 어떠한 mod_dav 공급 모듈에도 락 데이타베이스의 이용을 인정해 거기에는 mod_dav_svn 도 포함됩니다. mod_dav_svn는 실제로는 락을 이해하지 않음에도 불구하고, 입니다.

아직 혼란합니까?

요컨데, Apache httpd-2. 1(로 그 이후)에서는, mod_dav_lock를 사용해, mod_dav_svn 가 제대로LOCK 요구를 내고 있다고 하는체 을 하는 것이 할 수 있습니다. mod_dav_lock 가 httpd 에 짜넣어 컴파일 되고 있을까 httpd.conf로 로드 되고 있는 것을 확인해 주세요. 그리고Location 에 DAVGenericLockDB 명령을 추가해 주세요. 이하와 같은 느낌입니다:

Location /repos
  DAV svn
  SVNPath /absolute/path/to/repository
  SVNAutoversioning on
  DavGenericLockDB /path/to/store/locks
/Location

이 테크닉은, 조금 위험합니다: 어느 의미, mod_dav_svn 는 WebDAV 클라이언트에 거짓말을 하고 있는 것입니다. LOCK 요구를 받고 넣는 체를 합니다만, 실제로는 어떤 레벨에 대해도 락은 강제당하고 있지 않습니다. 만약 제2의 WebDAV 클라이언트가 같은 자원 에 대해서LOCK 하려고 하면(자), mod_dav_lock는 그것을 알아, 요구를 적절히 거부합니다. 그러나, 보통 Subversion 클라이언트가 보통svn commit를 통해서 하는 파일 변경은, 전혀 막을 수 없습니다!. 만약 이 테크닉을 사용한다면, 유저에게, 다른 사람의 변경을 어림잡아 망칠 기회를 주어 버립니다. 특히, WebDAV 클라이언트는 통상의 svn 클라이언트에 의해 위탁되었다 수정을 틀려 덧쓰기해 버릴지도 모릅니다.

한편, 충분히 주의해 환경을 설정하면, 위험을 줄일 수가 있습니다. 예를 들어, 만약 유저의모든 것 이(svn 클라이언트 (은)는 아니게) 기본적인 WebDAV 클라이언트를 통해서 작업하고 있다면, 이야기는 잘되겠지요.

A.3.1. Win32 웹 폴더

Windows 98, 2000, 이라고 XP는,"웹 폴더"로서 알려져 있는 통합된 WebDAV 클라이언트를 실장하고 있습니다. Windows 98에서는, 그 기능은 명시적으로 인스톨 할 필요가 있습니다. 만약 존재하고 있으면,"웹 폴더" 는 마이 컴퓨터 의 안에, 직접 보일 것입니다. Windows 2000 으로 XP에서는, 단지 마이 네트워크의 곳을 열어, 네트워크 플레이스의 추가의 아이콘을 실행할 뿐입니다. 다이얼로그가 나오면(자), WebDAV 의 URL를 입력합니다. 공유 폴더는 마이 네트워크 플레이스에 표시되게 됩니다.

대부분의 기입 조작은 자동 버전화 된 mod_dav_svn 서버에 잘 액세스 할 수 있습니다만, 몇개의 문제도 있습니다:

• 만약 컴퓨터가 NT도메인의 멤버라고, WebDAV 공유에 접속할 수 없는 것처럼 보입니다. 그것은 반복해 이름과 패스워드를 요구해, 그것은 Apache 서버가 인증을 요구하지 않을 때조차 일어납니다. 어느 사람들은, 웹 폴더는 Microsoft의 SharePoint DAV 서버에 별로 동작하도록(듯이) 설계되었기 때문이라고 생각하고 있습니다. 만약 머신이 NT도메인이 일부에서 없으면, 그 공유는 문제 없게 마운트 할 수 있습니다. 이 수수께끼는 아직도 해결하고 있지 않습니다.

• 파일은 공유로부터 편집을 위해서(때문에) 직접 열 수가 없습니다. 항상 읽어들여 전용이 됩니다. mod_dav_lock의 테크닉은 도움에 되지 않습니다. 웹 폴더는LOCK 메소드를 전혀 이용하지 않기 때문입니다. 그러나, 전에 지적한 것처럼 "카피, 편집, 써 반환" 방법은 잘 움직입니다. 공유상의 파일은 로컬로 편집한 카피로 문제 없게 덧쓰기할 수 있습니다.

A.3.2. Mac OS X

애플의 OS X operating system는 통합된 WebDAV 클라이언트 입니다. 파인더의 Go 메뉴로"서버에 접속" 아이템 (을)를 선택해 주세요. WebDAV의 URL를 입력하면, 보통 파일 서버와 같이 데스크탑상의 디스크로서 보이게 됩니다. [3]

불행하게도, 이 클라이언트는LOCK 의 서포트가 없기 때문에, mod_dav_svn 의 자동 버전화의 동작을 거부합니다. Mac OS X 는 최초의 HTTP OPTIONS 기능 교환시에 LOCK 의 능력이 없는 것을 알아, Subversion 저장소(repository)를 읽어들여 전용의 공유로서 마운트하는 결정을 합니다. 그 후에서는 기입 조작은 전혀 할 수 없습니다. 읽고 쓰기 가능한 공유 (으)로서 저장소(repository)를 마운트하기 위해서는, 전에 논의한 mod_dav_lock 의 트릭을 사용할필요가 있습니다 . 한번 락이 움직이고 있는 것처럼 보이면, 공유는 매우 잘 행동합니다. 파일은 읽고 쓰기 모드로 직접 열 수가 있습니다. 다만, 보존의 조작은, 실제로는 일시적인 장소에PUT 해, 원래의 파일을DELETE 해, 그 후, 원의 파일명칭 에, 그 일시파일을MOVE 하는 것으로 행합니다. 보존마다, 새로운 Subversion의 리버전을 세 개 할 수 있습니다.

또 하나의 주의: OS X 의 WebDAV 클라이언트는 HTTP 김다이렉트에 대해 필요이상으로 민감합니다. 만약 저장소(repository)를 전혀 마운트할 수 없다 (이)라면,httpd.conf의BrowserMatch 명령을 유효하게 할 필요가 있을지도 모릅니다:

BrowserMatch "^WebDAVFS/1. [012]" redirect-carefully

A.3.3. Unix: Nautilus 2

Nautilus 는 GNOME 데스크탑의 공식적인 파일 관리자/ 브라우저입니다. 홈 페이지는 http://www.gnome.org/projects/nautilus/ 에 있습니다. Nautilus 윈도우로 WebDAV URL를 입력하는 것만으로, DAV 공유가 로컬 파일 시스템과 같이 보입니다.

일반적으로, Nautilus 2 는 mod_dav_svn 의 자동 버전화가 거의 잘 움직입니다만, 이하에는 주의입니다:

• 공유로부터 직접 연 파일은 읽어들여 전용으로 다루어집니다. mod_dav_lock의 트릭은 전혀 효과가 없는 것처럼 보입니다. Nautilus 는LOCK 메소드를 완전히 문제에 하고 있지 않는 것 같습니다. "로컬에 카피, 편집, 써 반환" 의 트릭은 움직이는 것 같습니다만. 불행하게도 Nautilus 는 DELETE 를 사용해 최초로 낡은 파일을 덧쓰기하므로, 그것이, 하나 더의 리버전을 만들어 버립니다.

• 파일을 덧쓰기하거나 작성할 경우에는, Nautilus 는 우선 하늘의 파일을PUT 하고 나서, 제2의PUT로 그것을 덧쓰기합니다. 이것은, 하나가 아니고, 두 Subversion 파일 시스템 리버전을 만들어 버립니다.

• 집합을 삭제할 경우에는, 집합 자신의 대신에, 개별의 아이에 대해서 HTTP DELETE 를 발행합니다. 이것은, 파일의 수만의 새로운 리버전을 만들어 버립니다.

A.3.4. Linux davfs2

Linux davfs2 는 Linux 커넬의 파일 시스템 모듈로, 개발 홈 페이지는 http://dav.sourceforge.net/ 에 있습니다. 인스톨 하면(자), WebDAV 네트워크 공유가 보통 Unix의mount 커멘드로 마운트할 수 있다 같게 됩니다.

소문에 의하면, 이 DAV 클라이언트는 mod_dav_svn의 자동 버전 화가 전혀 동작하지 않다는 것입니다. 서버에 대한 기입의 모두에 대해, 우선LOCK 요구를 냅니다만, 이것은 mod_dav_svn 가 서포트하고 있지 않는 것입니다. 현시점에서는 mod_dav_lock 가 이 문제를 해결하는지 어떤지를 나타내는 자료는 없습니다.