뭔가 이해하려고합니다. 내 서버에 d : \ svn \ repository를 만들었습니다. 폴더를 커밋했지만 d : \ svn \ repository로 돌아 가면 볼 수 없습니다. 그들 모두 데이터베이스에 있습니까? 내 모든 저장소가 해당 기본 폴더에 들어가고 svn이 해당 폴더를 추적합니까? 두 개의 프로젝트가 있다면 어떻게 될까요?내가 체크인 한 svn 폴더는 서버에서 어디에 있습니까?
감사합니다.
Subversion은 논리 폴더를 서버의 동일한 구조에 저장하지 않고 "데이터베이스"의 델타 파일에있는 모든 것을 추적합니다. 이 데이터베이스는 Subversion에만 적용됩니다. 해당 저장소에 커밋 된 모든 파일이 해당 파일에 저장됩니다. 서버에서 논리 구조를 찾지는 못합니다. 단지 그렇게 작동하지 않습니다. 전혀 데이터베이스를 사용하지 않는 하나 FSFS 2004 년 중반에
에서
는 저장소에 저장 시스템의 제 2 유형은 존재로했다. FSFS 저장소 은 파일에 수정 트리를 저장하므로 저장소 번호가 인 리디렉션은 모두 하위 디렉토리에서 찾을 수 있습니다. 트랜잭션은 별도의 하위 디렉토리에 생성됩니다. 단일 트랜잭션 파일이 생성 및 따라서, 개정 디렉토리에 커밋 원자입니다 보장을 이동하면 완료. 리비전 파일은 이며 영구적이며 변하지 않으므로 저장소와 마찬가지로 "hot"인 동안 리포지토리도 백업 할 수 있습니다.
개정-파일 형식은 다른 개정 나무에있는 파일에 대한 내용 및 델타 파일, 개정의 디렉토리 구조를 나타냅니다. Berkeley DB 데이터베이스와 달리이 스토리지 형식은 다른 운영 체제에서 이식 가능하며 CPU 아키텍처에 대해서는 이 아닙니다. 저널링 또는 공유 메모리 파일 이 사용 중이므로 저장소는 네트워크를 통해 안전하게 액세스 할 수 있으며 파일 시스템이며 읽기 전용 환경에서 검사됩니다. 오버 헤드 데이터베이스가 없기 때문에 전체 저장소 크기가 약간 작다는 것을 의미합니다.
FSFS는 성능이 다르므로 특성도 있습니다. 많은 수의 파일을 가지고 디렉터리에 커밋 할 때 FSFS는 항목을 추가하는 데 O (N) 알고리즘을 사용하고, O (N^2) 알고리즘을 사용하여 디렉터리를 다시 작성합니다. 반면에, FSFS 는 최신 트리를 체크 아웃하는 것은 버클리 DB HEAD 개정에 저장된 fulltexts를 가져 오는 보다 약간 느린 것을 의미한다 이전 버전, 에 대한 델타와 같은 파일의 최신 버전을 기록 . 응답을 을 기다릴 때 극단적 인 경우에하는 수 원인 클라이언트 시간 초과로하는 커밋 마무리 할 때 FSFS는 는 더 이상 지연이 있습니다.
가장 중요한 차이점은 이지만 FSFS는 무언가 잘못되었을 때 이 될 수 없습니다. Berkeley DB 데이터베이스 을 사용하는 프로세스에서 사용 권한 문제가 발생하거나 갑자기 충돌이 발생하면 관리자는 이 복구 할 때까지 데이터베이스를 사용할 수 없습니다. 동일한 시나리오 이 FSFS 저장소를 사용하는 프로세스에서 발생하는 경우 저장소는 에 전혀 영향을 미치지 않습니다. 최악의 경우 일부 트랜잭션 데이터가 남아 있습니다.