SVN 마이그레이션--

SVN 마이그레이션--

많은 수의 리포지토리가 있는 SVN 서버를 새 서버로 마이그레이션해야 합니다. 오래된 서버는 문제가 있는 오래된 OS를 기반으로 구축되었기 때문에 재구축을 하기로 결정했습니다.

저는 SVN 사용의 기본 사항만 알고 있으며 덤프/로드 경로로 가야 하는지 아니면 svnsync를 사용하여 새 서버로 마이그레이션할 수 있는지 잘 모르겠습니다.

나는 "읽기 전용" 미러링을 위해 svnsync에 대한 참조를 찾고 있었습니다. 이것은 내가 원하는 것이 아닙니다. 기존 SVN Server A의 모든 데이터를 새로 생성된 SVN Server B로 마이그레이션하려고 합니다.

완료되면 서버 A는 사라지고 모든 SVN 사용자는 서버 B를 사용하게 됩니다.

지금까지 새로운 SVN 서버와 (빈) 저장소를 만들었습니다.

답변1

같은 문제가 있는 다른 사람들을 위해 게시합니다. 문제는 svnsync를 미러링에만 사용할 수 있는지 아니면 마이그레이션에만 사용할 수 있는지로 요약됩니다.

Google 그룹에 Dave Anderson이 참여한 내용을 인용하려면 다음을 따르세요.


이는 마이그레이션을 수행하는 데 사용될 수 있으며 Google Code로 마이그레이션을 수행하는 유일한 방법입니다. Subversion 책의 경고는 다음과 같이 읽어야 합니다. "읽기 전용 미러를 원할 경우 수동으로 아무것도 커밋하지 않도록 하십시오. 그렇지 않으면 svnsync가 더 이상 기본 저장소에서 동기화할 수 없습니다."

그러나 내부적으로 svnsync는 간단한 프로그램입니다. 한 서버에서 개정 스트림을 요청하고 해당 개정을 다른 서버에서 재생합니다. 대상 서버가 분기되지 않는 한(즉, 소스에 없는 커밋이 없는 한) svnsync를 점진적으로 실행하여 동기화를 유지할 수 있습니다. 그러나 한 번만 실행하여 두 저장소를 동기화한 다음 원본 저장소를 삭제하고 동기화된 복사본 사용을 시작할 수도 있습니다.

덤프/로드와 svnsync의 차이점은 svnsync가 전적으로 공개 서버 API를 통해 작동하는 반면 덤프/로드는 저장소 파일에서 직접 작동한다는 점입니다. 두 메커니즘 모두 동일한 데이터를 제공하지만 svnsync를 구현하는 것만으로도 훨씬 간단합니다. 덤프/로드를 구현하려면 추가 개발 시간과 리소스가 필요하지만 별다른 이점은 없습니다. 역사적으로 덤프/로드는 처음에는 구현하기가 더 쉬웠지만 시간이 지나면서 증분 덤프/로드를 수행하는 일반적인 방법에 대한 필요성이 분명해졌고 svnsync가 등장했습니다.

따라서 결론은 그렇습니다. svnsync를 사용하십시오. 문서를 따르면 Google 코드를 "읽기 전용 미러"로 생각하십시오. 동기화가 완료되면 로컬 저장소를 삭제(또는 보관 및 백업)하고 평소처럼 Google 코드 저장소 사용을 시작하세요.

이것이 도움이 되기를 바랍니다. -Dave

관련 정보