최근에 svnadmin dump / load 를 통해 이전 1.2.3 버전에서 1.6.0으로 Subversion 저장소를 업데이트했습니다 . 이전 리포지토리는 모두 동일한 UUID를 사용했습니다 (리포지토리는 템플릿 리포지토리를 복사하여 사용). svnadmin setuuid 를 통해 몇 가지 새로운 저장소의 UUID를 고유하게 변경했습니다. UUID가 다르기 때문에 해당 리포지토리의 기존 작업 복사본을 재배치 할 수 없습니다. 작업 사본을 내보내고 새 저장소에서 체크 아웃하는 방법에 대해 알고 있지만 svnadmin setuuid 가 저장소 에서 수행하는 작업과 같이 작업 사본의 UUID를 내부에서 변경하는 방법이 있는지 궁금합니다 .
답변:
Subversion 1.7 작업 카피 형식 이후의 새로운 답변 . sqlite3명령 줄 유틸리티 가 필요 합니다.
작업 사본의 루트 디렉토리에는 이제 .svn/SQLite 데이터베이스가 있는 단일 폴더가 있습니다. 다음 UUID을 사용하여 작업 사본으로 알려진 현재 저장소를 조회 할 수 있습니다 .
$ sqlite3 .svn/wc.db 'select uuid from REPOSITORY where id=1'
b6dc3e6c-5320-4549-b231-c153d86d7525
결과적으로 다음을 사용하여 변경 UUID을 수행 할 수 있습니다.
$ sqlite3 .svn/wc.db 'update REPOSITORY set uuid="1c0d1ec1-2326-0410-bef5-eb29cddfc032" where id=1'
물론, .svn/wc.db업데이트 쿼리를 호출하기 전에 파일 의 백업을 유지하십시오 . 리포지토리 엔터티에 다른 ID가 있거나 해당 테이블에 여러 줄이있을 가능성은 거의 없지만 예기치 않은 결과가 발생하는지 확인할 수 있습니다.
다음은 SVN 1.6 이하의 트릭을 수행하는 명령입니다.
find . -type f -name entries -exec sed -i 's/old-uuid/new-uuid/g' {} \;
교체 old-uuid및 new-uuid실제 ID가.
Yves Martin의 답변은 SVN 1.8을 사용하여 여러 작업 복사본에서 훌륭하게 작동했지만 결국 작동하지 않는 경우가 발생했습니다.
"where id = 1"없이 Yves의 명령을 실행하면 모든 경우에 우리에게 효과적이었습니다.
$ sqlite3 .svn/wc.db 'update REPOSITORY set uuid="1c0d1ec1-2326-0410-bef5-eb29cddfc032"'왜 이런 일이 발생했는지 조사한 결과, 저장소를 재배치 할 때 여러 UUID가 저장되어 있음을 알았습니다.
재배치 후 REPOSITORY 테이블에 새 항목이 추가되어 기존 항목을 업데이트하지 않고 새 저장소 루트 및 해당 UUID와 함께 증가 된 ID를 저장합니다. 따라서 제대로 작동하지 않은 경우는 이미 이전에 재배치 된 작업 복사본이었습니다. 명령이 작동하는 것처럼 보이지만 현재 사용중인 것이 아닌 초기 UUID 만 변경되었습니다.
다음 명령을 사용하여 작업중인 사본에서 저장된 루트 및 UUID 목록을 확인할 수 있습니다.
$ sqlite3 .svn/wc.db 'select id,uuid,root from REPOSITORY'마지막으로 다음과 같이 Windows 명령 줄 / 배치 파일에 다른 따옴표 세트를 사용해야한다는 점에 주목할 것입니다.
> sqlite3.exe .svn\wc.db "update REPOSITORY set uuid='1c0d1ec1-2326-0410-bef5-eb29cddfc032'"svn 팥 책의 " 리포지토리 UUID 관리 "섹션에 원하는 답이있을 수 있습니다.