전 Subversion 저장소 데이터베이스를 변경해야했습니다. 나는 덤프를 만들고 개정을 필터링하고 새 데이터베이스를 만들었습니다.Subversion 클라이언트는 저장소의 변경 사항을 어떻게 처리합니까?
이 새로운 리포지토리는 이전 버전의 작업 복사본 클라이언트와 많은 콘텐츠를 공유하지만 이미 리포를 체크 아웃 한 상태입니다.하지만 리비전이 누락되었습니다.
제거 된 버전은 데이터를 추가하지 않았으며 일부 파일 만 변경했습니다.
기존 클라이언트를 손상시키지 않고 기존 서버 데이터베이스를 새로운 서버로 간단하게 대체 할 수 있습니까? 아니면 모든 고객에게 대신 새 레포 사본을 체크 아웃해야합니까?
더 일반적으로, 서브 버전 클라이언트는 서버 측 구조의 변화를 어떻게 처리합니까? 저는 주로 TortoiseSVN에 관심이 있습니다.
덤프에서 개정 번호가 변경되지 않고 UUID가 유지되는 한 큰 차이가 없어야합니다. Subversion은 작업 카피 파일의 개정 번호와 저장소의 UUID와 URL을 추적합니다. 기록이 변경 되더라도 작업 복사본에는 영향을 미치지 않습니다.
항상 이론과 사실간에 차이가 있습니다. 덤프 및로드 작업을 수행하기 전에 개발자에게 미리 경고 할 것입니다. 나는 그들에게 그들의 코드를 확인하게한다. 그런 다음 덤프 앤로드를 수행 한 다음 개발자에게 깨끗한 체크 아웃을 수행하도록 알려줍니다.
그냥 안전을 위해 깨끗한 체크 아웃을하십시오. 이전 작업 사본에서 svn status을 수행하여 변경되었지만 확약되지 않은 파일을 찾아 새 정리 된 체크 아웃으로 복사 할 수 있습니다. svn status은 저장소를 ping하지 않으므로 안전한 작업입니다.
손상된 체크인 문제가 발생하여 repo에서 삭제해야합니다. 작업이 완료된 후 몇 가지 테스트 체크 인을 실행 했으므로 최신 개정 번호는 다른 개발자가 상자에 넣은 것보다 적어도 같았습니다 (그보다 크지 않은 경우). 우리는이 일을하는 데 어떤 문제도 없었습니다.
내 경험으로 Tortoise SVN 클라이언트 1.7은 .svn 디렉터리를 꾸준히 늘리고 작업 복사본의 맨 위에서 "정리"를 실행할 때만 줄입니다.
또한 필터링 된 개정판의 로그 메시지 (및 기타 세부 사항)를 TSVN에서 이미 본 경우, 특정 캐시를 지우지 않는 한 사용자에게 계속 표시됩니다 (GUI에서 가능함).
뚜렷한 리비전 번호를 포함하여 전체 리비전을 필터링하면 (즉, 다음 리비전에 필터링 된 리비전 번호가 부여되도록) 오래된 작업 복사본을 유지하려고하지 않을 것입니다.
귀하의 질문에 직접 대답하기 위해 고객의 내부에 대해 더 많이 알지 못합니다. 하지만 비슷한 상황 이었으므로 먼저 서버을 테스트 해 보시기 바랍니다.
심지어 더 svnadmin로드 (또는 부하이 svnrdump) 이미이 있어야 역사 누락 우연히 ("델타") . 하지만 서버가 정말 전달 않는다는 것을 많은 증거를 수집하는 것이 좋습니다 :
을하는 필터링 및 좋은 측정을 위해이 파일 위에있는 디렉토리의 영향을받습니다. (디렉토리는 것 같아요, 다른 파일과 하위 디렉토리를 포함 할 필요가 없습니다.)
왜 서버 리포지토리와 클라이언트 리포지토리가 있습니까? 어쩌면 * 리포지토리 * (항상 서버 측) 및 * 작업 복사본 * (항상 클라이언트 측)을 의미할까요? 문제는 클라이언트 저장소와 같은 것이 없다는 것입니다. 아니면'svnsync'를 사용하여 여러 개의 저장소를 동기화하려고합니까? – altern
@altern : 예, 클라이언트 작업 사본을 의미했습니다. 혼란을 가져 미안해 내가 편집했다. – mafu