우리는 직장에서 SCM에 만족스럽게 SVN을 사용합니다. 현재 우리의 코드와 동일한 SVN 저장소에 바이너리 자산이 있습니다. SVN은 매우 큰 파일을 지원합니다 (메모리 사용을 제대로 유지하기 위해 'streamily'를 전송합니다). 그러나 모든 것을 SLOOWWWWW로 만듭니다. 느린 자산 버전 관리는 괜찮지 만 느린 텍스트 작업은 실제로 받아 들일 수 없습니다.대용량 리포지토리의 응답 성을 유지하기위한 SVN 최적화
현재 자산은/trunk/release (12 개/trunk/projects와 나란히)에 있습니다. 별도의 저장소에 보관해야합니까? 우리가 할 수있는 다른 최적화는 무엇입니까? 우리는 약 1GB의 자산을 보유하고 있습니다.
IMNSHO 각 프로젝트를 자체 저장소에 보관하는 것이 더 바람직합니다. 단지 리비전 번호를 서로 구분하여 보관하는 것이 좋습니다. 프로젝트 foo가 6 개월 만에 변경되지 않았지만 프로젝트 바가 현재 개발 중에 있다면 foo의 현재 개정 번호가 계속 변경되어야하는 이유는 무엇입니까? 아마 두 사람이 서로 단단히 (예 : 공통 라이브러리를 공유하는 것처럼) 예외일지도 모르지만 라이브러리도 자체 프로젝트 여야합니다.
바이너리 자산이 전혀 변경되지 않습니까, 아니면 정적입니까? 그들이 정적이라면, 어쩌면 리포지토리에 그걸 넣고 싶지 않을 수도 있습니다.
당신은 이미 어떤 최적화를 사용했는지 말하지 않았습니다. bsdfs를 사용하는 경우 fsfs로 전환하면 성능이 향상되는지 여부를 확인하십시오. 버전 수가 많으면 서버에서 최신 버전으로 전환하고 저장소를 1.5 형식으로 변환하십시오.
아마도 가장 좋은 대답은 바이너리 파일을 별도의 디렉토리에 저장하고 예비 디렉토리 기능을 사용하여 파일을 관리하는 것입니다. 즉, 필요할 때까지 파일을 체크 아웃하지 마십시오. 그런 다음 모든 작업은 바이너리가 아닌 소스 파일에서 수행됩니다.
또는 동일한 메커니즘을 사용하여 커밋하거나 업데이트 할 수 있습니다. 작업 복사본을 업데이트하는 대신 'update to revision'을 사용하고 HEAD 및 감소 된 깊이를 지정할 수 있으므로 바이너리 디렉토리가 업데이트되지 않습니다 (필요할 때까지).
또한 'svnadmin 팩'을 사용하여 서버 측 성능을 향상시킬 수 있습니다.
SVN revnum은 프로젝트마다 다르며 저장소 별입니다. foo가 새로운 revnum을 얻는다는 생각에서의 실수 - foo에서 아무것도 변경되지 않으면 새로운 revnum을 얻지 못합니다! foo의 현재 revnum은 'HEAD'이거나 프로젝트 foo가 변경된 마지막 revnum입니다. – gbjbaanb